Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Affichage des résultats du sondage: Quels sont les langages de programmation que vous détestez le plus en 2019 ? Pourquoi ?

Votants
288. Vous ne pouvez pas participer à ce sondage.
  • Assembleur

    19 6,60%
  • C

    17 5,90%
  • C#

    26 9,03%
  • C++

    34 11,81%
  • Cobol

    29 10,07%
  • Dart

    4 1,39%
  • Delphi

    11 3,82%
  • Fortran

    7 2,43%
  • Go

    20 6,94%
  • Haskell

    3 1,04%
  • Java

    55 19,10%
  • JavaScript

    151 52,43%
  • Kotlin

    9 3,13%
  • Lisp

    8 2,78%
  • MATLAB

    14 4,86%
  • Objective-c

    21 7,29%
  • Pascal

    3 1,04%
  • Perl

    9 3,13%
  • PHP

    44 15,28%
  • Python

    35 12,15%
  • R

    12 4,17%
  • Ruby

    11 3,82%
  • Rust

    4 1,39%
  • Scala

    11 3,82%
  • Swift

    9 3,13%
  • TypeScript

    20 6,94%
  • VBA

    82 28,47%
  • WLangage (WinDev)

    66 22,92%
  • Autres, merci de préciser

    3 1,04%
  • Sans avis

    9 3,13%
Sondage à choix multiple
  1. #261
    Expert confirmé
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    avril 2016
    Messages
    1 008
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : avril 2016
    Messages : 1 008
    Points : 4 323
    Points
    4 323
    Par défaut
    Citation Envoyé par OButterlin Voir le message
    Maintenant, le débat sur "langage typé" ou "non typé"... bof... je ne vois pas trop où est le problème du langage non typé... j'aime bien javascript pour faire ce pourquoi il a été conçu, il suffit d'apprendre ses spécificités (et ceci est vrai pour toutes les technos).
    L'un des principaux avantages du typage statique est que c'est une sorte de documentation dont on sait qu'elle est à jour. Cela permet à un nouvel arrivant de comprendre plus facilement le code qui a été pondu par ses prédécesseurs. Qu'est-ce que cette fichue fonction prend en entrée et quelles opérations peut-on faire sur ce paramètre ? Avec le typage statique, on voit tout de suite le type et, avec un simple raccourcis clavier dans l'IDE, on peut sauter directement à la définition du type en question. Par contre, avec du code qui abuse du duck typing et qui n'ajoute pas non plus de contrôles de type au runtime, il faut chercher récursivement dans le code appelant. L'abus du duck typing est une manière parmi d'autres de concevoir des programmes qui sont de gros blobs que seul l'auteur comprend vite au lieu d'avoir un code bien découpé proprement en sous-parties qu'on peut analyser de manière relativement indépendante les unes des autres.

    Même dans des environnements avec des langages dynamiquement typés, de plus en plus de développeurs finissent par comprendre que le typage statique peut être utilisé comme un atout pour la maintenabilité du code. C'est pour ça que le typage statique optionnel est apparu en Python et que le langage TypeScript est apparu pour ajouter du typage statique par dessus JavaScript.

    Citation Envoyé par OButterlin Voir le message
    comme si la valeur d'un programme se mesurait au nombre de lignes de code, moins il y en a, meilleur il est... alors que bien souvent, c'est le contraire
    Cela me rappelle que tu étais dubitatif sur l'intérêt de la concision apportée par Lombok en Java. Je cite un de tes messages de février :
    Citation Envoyé par OButterlin Voir le message
    Personnellement, ça me prend 15 secondes pour faire générer les getter/setter, la méthode toString, le(s) constructeur(s), les méthodes hashCode/equals avec Eclipse alors je me demande : où est l'intérêt ?
    Pour moi, si on peut générer tout ça avec des raccourcis dans Eclipse, c'est un signe qu'il s'agit de gros pâtés de textes qui ajoutent très peu d'informations, malgré la verbosité du code. Quand je lis du code, au lieu de faire défiler la barre verticale pour sauter la lecture du bruit, je préfère lire du code plus concis.

  2. #262
    Membre expert
    Homme Profil pro
    Développeur informatique
    Inscrit en
    avril 2017
    Messages
    818
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : avril 2017
    Messages : 818
    Points : 3 547
    Points
    3 547
    Par défaut
    Citation Envoyé par OButterlin Voir le message
    Alors ce genre de commentaire ne démontre qu'une seule chose c'est ta totale méconnaissance du C++ ou du code machine, ou une aptitude à exagérer outrageusement les choses...
    ... mais pour quelqu'un qui connaît bien java, quel serait l'intérêt de passer à kotlin ?
    Non, pas du tout. Ca démontre juste que tu sembles essayer de décrédibiliser tout ce qui te ferait sortir de ta zone de confort ou que tu ne comprends pas. On dirait un dev qui ne connait que le typage dynamique et qui nierait l'intérêt du typage statique sous prétexte que "ça n'arrive pas si tu sais coder" ou que "c'est vérifié par les tests unitaires".

  3. #263
    Membre extrêmement actif
    Avatar de Sodium
    Femme Profil pro
    Développeuse web
    Inscrit en
    avril 2014
    Messages
    1 759
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeuse web

    Informations forums :
    Inscription : avril 2014
    Messages : 1 759
    Points : 1 740
    Points
    1 740
    Billets dans le blog
    1
    Par défaut
    Quel est l'intérêt du typage dynamique ? Si le type d'une variable change au cours de son existence, c'est que le code est mauvais.

  4. #264
    Membre régulier
    Homme Profil pro
    Directeur technique
    Inscrit en
    septembre 2016
    Messages
    28
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : France, Hautes Pyrénées (Midi Pyrénées)

    Informations professionnelles :
    Activité : Directeur technique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : septembre 2016
    Messages : 28
    Points : 89
    Points
    89
    Par défaut
    Citation Envoyé par Sodium Voir le message
    Quel est l'intérêt du typage dynamique ? Si le type d'une variable change au cours de son existence, c'est que le code est mauvais.
    Disons que tu travailles au programme voiture. Tu as une fonction Alerter qui utilise la méthode klaxon d'un instance de classe Voiture. Ton collègue qui travaille au programme camion peut utiliser ta fonction Alerter puisque sa classe Camion possède également une méthode klaxon.
    La différence avec du statique, il n'a pas à te demander de modifier quoi que ce soit. Le besoin peut évoluer (de voiture vers n'importe quoi qui klaxonne) ou des besoins nouveaux se greffer au premier besoin implémenté (comme ici avec le camion), on n'a pas à modifier la signature de la fonction Alerter.
    Ceci dit, cette facilité se paie par un code plus lâche et plus opaque. Je suis pas fan. Mais ton client va adorer ça de pouvoir changer ses spécifications toutes les 72 heures.

  5. #265
    Membre extrêmement actif
    Avatar de Sodium
    Femme Profil pro
    Développeuse web
    Inscrit en
    avril 2014
    Messages
    1 759
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeuse web

    Informations forums :
    Inscription : avril 2014
    Messages : 1 759
    Points : 1 740
    Points
    1 740
    Billets dans le blog
    1
    Par défaut
    Je n'ai pas tout compris car ce n'est pas clair et semble mal pensé mais a priori les interfaces répondent à ton problème.

  6. #266
    Modérateur
    Avatar de Marco46
    Homme Profil pro
    Développeur informatique
    Inscrit en
    août 2005
    Messages
    4 264
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : août 2005
    Messages : 4 264
    Points : 17 634
    Points
    17 634
    Par défaut
    Citation Envoyé par Sodium Voir le message
    Quel est l'intérêt du typage dynamique ? Si le type d'une variable change au cours de son existence, c'est que le code est mauvais.
    Toi le pro de la POO tu n'utilises jamais de polymorphisme ?
    "Toute personne croyant qu'une croissance exponentielle peut durer indéfiniment dans un monde fini est soit un fou, soit un économiste."
    Kenneth E. Boulding

    "Les richesses naturelles sont inépuisables, car, sans cela, nous ne les obtiendrions pas gratuitement. Ne pouvant être ni multipliées ni épuisées, elles ne sont pas l’objet des sciences économiques."
    Jean-Baptiste Say, Traité d'économie politique, 1803.

    "/home/earth is 102% full ... please delete anyone you can."
    Inconnu

  7. #267
    Expert confirmé
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    avril 2016
    Messages
    1 008
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : avril 2016
    Messages : 1 008
    Points : 4 323
    Points
    4 323
    Par défaut
    Citation Envoyé par Sodium Voir le message
    Quel est l'intérêt du typage dynamique ?
    Le duck typing est intéressant dans des cas où le code a un haut niveau d'abstraction, typiquement quand on fait de la métaprogrammation (du code qui lit du code et qui retourne du code). Par exemple, dans les dialectes du Lisp, quand on écrit des macros, on peut prendre en entée des arbres d'éléments quelconques (qui représentent des arbres syntaxiques des codes en entrée) et on peut retourner un arbre (qui correspond à l'arbre syntaxique du code généré).

    À part ça, dans les langages uniquement statiquement typés, le typage peut avoir tendance à empêcher certaines abstractions. Mais il faut voir au cas par cas, car certains langages statiquement typés ont un typage plus puissant que d'autres. Par exemple, Haskell, avec ses typeclasses et higher order types, offre une plus grande puissance d'abstraction que les interfaces de Java.

    En Python, dans les bouts de code où le typage statique de Python n'est pas assez puissant pour gérer certaines abstractions, on passe au duck typing.

    Un autre intérêt pour un langage de permettre de faire du duck typing est que ce dernier est plus abordable par les développeurs débutants que les différentes formes de typage statique. Or, plus un langage attire de monde, plus l'écosystème autour de ce langage se développe.

  8. #268
    Membre régulier
    Homme Profil pro
    Directeur technique
    Inscrit en
    septembre 2016
    Messages
    28
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : France, Hautes Pyrénées (Midi Pyrénées)

    Informations professionnelles :
    Activité : Directeur technique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : septembre 2016
    Messages : 28
    Points : 89
    Points
    89
    Par défaut
    Citation Envoyé par Sodium Voir le message
    Je n'ai pas tout compris car ce n'est pas clair et semble mal pensé mais a priori les interfaces répondent à ton problème.
    Une interface c'est aussi une contrainte de type. La contrainte de type peut être bien posée au départ ... ou pas ! Lorsqu'on change les contraintes de types en cours de route sur de gros programmes, on n'est plus sûr que ça compile. Il faut refactorer un minimum. Alors qu'en langage dynamique on n'est jamais bloqué. Pas de compilation, ton programme a beau générer des erreurs à l'exécution localement à certaines fonctions, il peut toujours être lancé. Dans le cas de prototypages ou pour faire des démonstrations de concepts, ça peut être intéressant.
    Pas mal de startups ont commencé en dynamique avec disons Ruby et Rails pour vendre un concept, pour ensuite réécrire le code en compilé, une fois les investisseurs trouvés.

  9. #269
    Membre extrêmement actif
    Avatar de Sodium
    Femme Profil pro
    Développeuse web
    Inscrit en
    avril 2014
    Messages
    1 759
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeuse web

    Informations forums :
    Inscription : avril 2014
    Messages : 1 759
    Points : 1 740
    Points
    1 740
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par Marco46 Voir le message
    Toi le pro de la POO tu n'utilises jamais de polymorphisme ?
    J'utilise autant que possible la composition mais si le problème est le typage des paramètres et retours typés, dans quel cas les interfaces ne font-elles pas le job ?

    Citation Envoyé par cloudit.fr Voir le message
    Une interface c'est aussi une contrainte de type. La contrainte de type peut être bien posée au départ ... ou pas ! Lorsqu'on change les contraintes de types en cours de route sur de gros programmes, on n'est plus sûr que ça compile. Il faut refactorer un minimum. Alors qu'en langage dynamique on n'est jamais bloqué. Pas de compilation, ton programme a beau générer des erreurs à l'exécution localement à certaines fonctions, il peut toujours être lancé. Dans le cas de prototypages ou pour faire des démonstrations de concepts, ça peut être intéressant.
    Donc l'avantage du typage dynamique est de pouvoir coder salement en se disant qu'on réécrira tout au propre tout en sachant qu'on ne le fera jamais ?

  10. #270
    Membre régulier
    Homme Profil pro
    Directeur technique
    Inscrit en
    septembre 2016
    Messages
    28
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : France, Hautes Pyrénées (Midi Pyrénées)

    Informations professionnelles :
    Activité : Directeur technique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : septembre 2016
    Messages : 28
    Points : 89
    Points
    89
    Par défaut
    Citation Envoyé par Sodium Voir le message
    Donc l'avantage du typage dynamique est de pouvoir coder salement en se disant qu'on réécrira tout au propre tout en sachant qu'on ne le fera jamais ?
    En Belgique peut-être mais en France on ne code jamais salement. On a une éthique de travail, une intégrité. On ne se roule dans la boue que si on y est obligé.

  11. #271
    Expert éminent sénior
    Avatar de Sve@r
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    février 2006
    Messages
    7 682
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Oise (Picardie)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : février 2006
    Messages : 7 682
    Points : 21 851
    Points
    21 851
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par Sodium Voir le message
    Quel est l'intérêt du typage dynamique ? Si le type d'une variable change au cours de son existence, c'est que le code est mauvais.
    Avis peut-être un peu réducteur non ? Le typage dynamique peut s'appliquer sans qu'une variable change durant son existence. Si par exemple je définis la fonction somme de cette façon def somme(a, b): return a+b je suis bien content de pouvoir appeler somme(2, 3) ou bien somme(2.5, 3L) (bon ok j'avoue c'est un exemple Python2 qui n'a plus cours en Python3) ou bien somme(2+3j, 4+7j) ou bien somme(fractions.Fraction(1, 2), fraction.Fractions(7, 4)) ou bien même somme("Hello", "World !!!").
    Faire pareil en C...
    Mon Tutoriel sur la programmation «Shell»
    Sinon il y en a pleins d'autres. N'oubliez pas non plus les différentes faq disponibles sur ce site

  12. #272
    gl
    gl est déconnecté
    Rédacteur

    Homme Profil pro
    Inscrit en
    juin 2002
    Messages
    2 164
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41
    Localisation : France, Isère (Rhône Alpes)

    Informations forums :
    Inscription : juin 2002
    Messages : 2 164
    Points : 4 475
    Points
    4 475
    Par défaut
    Citation Envoyé par Sve@r Voir le message
    Si par exemple je définis la fonction somme de cette façon def somme(a, b): return a+b je suis bien content de pouvoir appeler somme(2, 3) ou bien somme(2.5, 3L) (bon ok j'avoue c'est un exemple Python2 qui n'a plus cours en Python3) ou bien somme(2+3j, 4+7j) ou bien somme(fractions.Fraction(1, 2), fraction.Fractions(7, 4)) ou bien même somme("Hello", "World !!!").
    L'exemple me semble douteux pour parler de l'intérêt du typage dynamique. Ici, c'est un polymorphisme (en l’occurrence une forme de surcharge) qui est mise en avant.
    Ça peut certes être vu comme du dynamisme dans le typage. Et, dans le cas des langages à typage dynamique, c'est assez proche et utilise a priori les mêmes mécanismes sous-jacent (dis plus simplement, c'est le typage dynamique qui permet cette surcharge). Mais ça reste différent de l'essence du typage dynamique qui est de faire porter le type non par la variable elle-même mais par la valeur et donc de permettre de changer le type d'une variable au fil des affectations de celle-ci.

    Remarque de ma part qui ne signifie absolument pas que le typage dynamique n'a pas d'intérêt.
    Même si je suis plus à l'aise - probablement en partie par habitude - avec le typage statique et que j'y vois de nombreux avantages - notamment les vérifications effectués par le compilateur qui épargne de nombreux tests, fussent-ils automatiques -, je suis bien content d'avoir un peu de dynamisme parfois. Que ce soit, le plus généralement, pour gagner en expressivité - ce qui de prime abord peut sembler paradoxal - et simplicité ou pour de basses considérations d'espace mémoire à la façon des unions en C (mais là c'est lié au fait que j'utilise justement un langage à typage statique proposant, via des polymorphismes, des constructions un peu plus dynamiques, en l’occurrence du C++ avec des variant, et que j'ai parfois des contraintes mémoires fortes, même si c'est de moins en moins vrai).

  13. #273
    Expert confirmé
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    avril 2016
    Messages
    1 008
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : avril 2016
    Messages : 1 008
    Points : 4 323
    Points
    4 323
    Par défaut
    D'ailleurs, une caractéristique intéressante des templates du C++ est que c'est du compile-time duck typing (Bjarne Stroustrup lui-même utilise ce terme).

    Pour reprendre l'exemple de la somme de Sve@r, on peut alors écrire :
    Code C++ : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    #include <chrono>
    #include <iostream>
    #include <string>
    #include <utility>
     
    using namespace std::chrono_literals;
     
    template<class T, class U>
    auto somme(T&& a, U&& b) {
    	return std::forward<T>(a) + std::forward<U>(b);
    }
     
    int main() {
    	std::cout << somme(40, 2) << '\n';
    	std::cout << somme(std::string("foo"), std::string("bar")) << '\n';
    	std::cout << somme(10h, 12min).count() << '\n';
    	return 0;
    }
    ce qui affiche :
    Dans le code source de somme, on a seulement besoin de dire que T et U sont des types. On n'a pas besoin de spécifier explicitement dans la signature qu'on peut additionner un T et un U et on n'a pas besoin de déclarer le type de retour.
    Dans l'exemple somme(10h, 12min), le compilateur essaie d'instancier une fonction avec un premier paramètre de type std::chrono::hours et un deuxième paramètre de type std::chrono::minutes, y arrive et comprend que le type de retour est std::chrono::minutes.

    En Rust, par contre, pour définir somme et l'utiliser, le code serait ainsi :
    Code Rust : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    use std::ops::Add;
    use std::time::{Duration, Instant};
     
    fn somme<T: Add<U, Output=V>, U, V>(a: T, b: U) -> V {
    	a + b
    }
     
    fn main() {
    	println!("{}", somme(40, 2));
    	println!("{:?}", somme(Duration::from_secs(10), Duration::from_secs(2)));
    	let now = Instant::now();
    	println!("{:?}", somme(now, Duration::from_secs(17)).duration_since(now));
    }
    ce qui affiche :
    En Rust, les templates ne sont pas du compile-time duck typing comme en C++, donc on est obligé de préciser que T implémente le trait Add<U, Output=V> pour dire qu'on peut additionner un T et un U et que le type de retour est V.

    Dans l'exemple somme(now, Duration::from_secs(17)), on additionne un std::time::Instant et un std::time::Duration, ce qui retourne un std::time::Instant.

    Du coup, pour la programmation générique, si on compare C++ et Rust, les deux sont statiquement typés, mais les templates du C++ ne sont pas aussi typés que ceux du Rust, ce qui a ses avantages et ses inconvénients.

  14. #274
    Expert éminent sénior
    Avatar de Sve@r
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    février 2006
    Messages
    7 682
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Oise (Picardie)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : février 2006
    Messages : 7 682
    Points : 21 851
    Points
    21 851
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par gl Voir le message
    L'exemple me semble douteux pour parler de l'intérêt du typage dynamique.
    Ben je fais ce que je peux pour trouver des exemples innovants et parlants

    Citation Envoyé par gl Voir le message
    Mais ça reste différent de l'essence du typage dynamique qui est de faire porter le type non par la variable elle-même mais par la valeur et donc de permettre de changer le type d'une variable au fil des affectations de celle-ci.
    Et si une variable change d'affectation à différents moments de mon code est-ce que cela rend mon code mauvais (c'est pas à toi que je m'adresse, c'est juste un rappel de ma précédente intervention, mais tu peux donner aussi ton avis) ? Je peux très bien avoir "partie A qui utilise toto, puis partieA résolue puis partieB qui a besoin d'une variable => ok, utilisons toto qui est déjà là et qui glande que dalle !!!".
    Et en plus on peut même le faire en C en encapsulant partieA et partieB dans des blocs distincts...
    Mon Tutoriel sur la programmation «Shell»
    Sinon il y en a pleins d'autres. N'oubliez pas non plus les différentes faq disponibles sur ce site

  15. #275
    gl
    gl est déconnecté
    Rédacteur

    Homme Profil pro
    Inscrit en
    juin 2002
    Messages
    2 164
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41
    Localisation : France, Isère (Rhône Alpes)

    Informations forums :
    Inscription : juin 2002
    Messages : 2 164
    Points : 4 475
    Points
    4 475
    Par défaut
    Citation Envoyé par Pyramidev Voir le message
    D'ailleurs, une caractéristique intéressante des templates du C++ est que c'est du compile-time duck typing (Bjarne Stroustrup lui-même utilise ce terme).
    On parle aussi de polymorphisme paramétrique et parfois de sous-typage structurel (ce qu'est in fine le duck typing).
    Mais j'avoue trouver particulièrement intéressante et pertinent cette appellation de compile-time duck typing

    Citation Envoyé par Pyramidev Voir le message
    Du coup, pour la programmation générique, si on compare C++ et Rust, les deux sont statiquement typés, mais les templates du C++ ne sont pas aussi typés que ceux du Rust, ce qui a ses avantages et ses inconvénients.
    En toute rigueur, en jouant avec les spécialisations et le SFINAE, il était déjà possible de contraindre en partie les templates, mais c'était pénible à faire et limité.
    Mais, entre ce qui arrive en C++20 (notamment les concepts) et quelques évolutions récentes autour des templates et du compile-time, il va être (est ?) possible de contraindre les templates lorsque c'est nécessaire sans perdre la capacité à être très générique lorsqu'on le souhaite. Et donc d'avoir le meilleur des deux mondes selon les besoins.

    Citation Envoyé par Sve@r Voir le message
    Et si une variable change d'affectation à différents moments de mon code est-ce que cela rend mon code mauvais (c'est pas à toi que je m'adresse, c'est juste un rappel de ma précédente intervention, mais tu peux donner aussi ton avis) ? Je peux très bien avoir "partie A qui utilise toto, puis partieA résolue puis partieB qui a besoin d'une variable => ok, utilisons toto qui est déjà là et qui glande que dalle !!!".
    Dans l'absolu, je ne sais pas dire, ça va fortement dépendre du contexte et de tes motivations (mais l'argument "j'ai une variable qui ne sert plus, réutilisons là" est très faible et probablement pas une bonne raison de le faire).

    Un cas typique où j'envisagerais l'utilisation de ce dynamisme c'est une variable dont l'importance n'est pas tant son type mais son rôle et dont la valeur va changer au cours du temps. Généralement, on va plutôt s'orienter vers du sous-typage (i.e. héritage, interface, ...), mais il y a des cas où ce n'est pas possible soit pour des raisons purement techniques (p.ex. des types tierces préexistant n'ayant pas de base commune et que je ne peux pas modifier) ou vraiment conceptuel (l'héritage qui crée un lien plus fort que ce que l'on cherche vraiment à modéliser, ce qui reviendrait à faire un sous-typage qui ne respecte pas le principe de Liskov). C'est, à mon sens, vraiment dans ces cas que le typage dynamique et le sous-typage structurel (dont le duck-typing) sont intéressants.

  16. #276
    Membre extrêmement actif
    Avatar de Sodium
    Femme Profil pro
    Développeuse web
    Inscrit en
    avril 2014
    Messages
    1 759
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeuse web

    Informations forums :
    Inscription : avril 2014
    Messages : 1 759
    Points : 1 740
    Points
    1 740
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par Sve@r Voir le message
    Ben je fais ce que je peux pour trouver des exemples innovants et parlants
    C'est un exemple de mauvaise programmation tout court, on ne mélange pas des pommes et des poires (sauf en JavaScript évidemment) et si le langage t'empêche de le faire c'est une excellente chose.

  17. #277
    Expert confirmé
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    avril 2016
    Messages
    1 008
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : avril 2016
    Messages : 1 008
    Points : 4 323
    Points
    4 323
    Par défaut
    Citation Envoyé par gl Voir le message
    En toute rigueur, en jouant avec les spécialisations et le SFINAE, il était déjà possible de contraindre en partie les templates, mais c'était pénible à faire et limité.
    Mais, entre ce qui arrive en C++20 (notamment les concepts) et quelques évolutions récentes autour des templates et du compile-time, il va être (est ?) possible de contraindre les templates lorsque c'est nécessaire sans perdre la capacité à être très générique lorsqu'on le souhaite. Et donc d'avoir le meilleur des deux mondes selon les besoins.
    On peut mettre des contraintes, mais il n'y a pas de moyen simple de vérifier que ces contraintes sont exhaustives. Par exemple, si on veut qu'un certain template fonctionne avec des types non copiables et qu'on appelle par mégarde le constructeur de copie, il faut attendre d'instancier le template avec un type non copiable pour se rendre compte de l'étourderie.

    Une solution consiste à instancier explicitement le template avec des types qui ont les prérequis minimaux, mais alors le code devient très vite très lourd. Dans l'exemple fictif du template somme de tout à l'heure, cela donne :
    Code C++ : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    #include <chrono>
    #include <iostream>
    #include <string>
    #include <utility>
     
    using namespace std::chrono_literals;
     
    // I don't know why, but the explicit template instantiation does not compile
    // with GCC 9.2.0 if I don't write "-> decltype(a + b)".
     
    template<class T, class U>
    auto somme(T&& a, U&& b) -> decltype(a + b) {
    	return std::forward<T>(a) + std::forward<U>(b);
    }
     
    struct TestSommeStructRhs {
    	TestSommeStructRhs() = delete;
    	TestSommeStructRhs(TestSommeStructRhs const&) = delete;
    	TestSommeStructRhs(TestSommeStructRhs&&) = delete;
    	~TestSommeStructRhs() = delete;
    	void operator=(TestSommeStructRhs const&) = delete;
    	void operator=(TestSommeStructRhs&&) = delete;
    	void operator&() = delete;
    };
     
    struct TestSommeStructLhs {
    	TestSommeStructLhs() = delete;
    	TestSommeStructLhs(TestSommeStructLhs const&) = delete;
    	TestSommeStructLhs(TestSommeStructLhs&&) = delete;
    	~TestSommeStructLhs() = delete;
    	void operator=(TestSommeStructLhs const&) = delete;
    	void operator=(TestSommeStructLhs&&) = delete;
    	void operator&() = delete;
    	int operator+(TestSommeStructRhs&) {return 42;};
    };
     
    // Explicit instantiation of somme with types with minimal requirements
    template int somme(TestSommeStructLhs&, TestSommeStructRhs&);
     
    int main() {
    	std::cout << somme(40, 2) << '\n';
    	std::cout << somme(std::string("foo"), std::string("bar")) << '\n';
    	std::cout << somme(10h, 12min).count() << '\n';
    	return 0;
    }
    En Rust, par contre, le compilateur oblige à n'utiliser que des opérations qui ont été autorisées par les contraintes. Et c'est en cela que les templates du Rust resteront plus fortement typés que ceux du C++, même quand il y aura les concepts du C++20.

    Citation Envoyé par Sodium Voir le message
    Si le type d'une variable change au cours de son existence, c'est que le code est mauvais.
    Pas forcément. Je vais prendre un exemple en Rust où le shadowing ressemble à une variable dont le type "change au cours de son existence" :
    Code Rust : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    struct EmployeeId;
     
    struct Employee { name: String }
     
    fn find_employee(_employee_id: EmployeeId) -> Option<Employee> {
    	Some(Employee { name: String::from("John Smith") })
    }
     
    fn get_employee_name_to_display(employee_id: EmployeeId) -> String {
    	let employee = find_employee(employee_id);
    	match employee {
    		Some(employee) => employee.name,
    		None => String::from("n/a")
    	}
    }
     
    fn main() {
    	let employee_id = EmployeeId {};
    	println!("{}", get_employee_name_to_display(employee_id));
    }
    Dans le code de get_employee_name_to_display, la première variable employee a le type Option<Employee>. Par contre, dans la ligne Some(employee) => employee.name, j'ai redéclaré une variable employee qui a le type Employee, ce qui me permet d'accéder à l'attribut name.
    Sans le shadowing, j'aurais dû changer le nom d'une des deux variables, mais le code n'aurait pas forcément été plus clair.

  18. #278
    Membre éprouvé
    Homme Profil pro
    chomeur
    Inscrit en
    avril 2015
    Messages
    530
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 74
    Localisation : France, Seine Maritime (Haute Normandie)

    Informations professionnelles :
    Activité : chomeur
    Secteur : Distribution

    Informations forums :
    Inscription : avril 2015
    Messages : 530
    Points : 1 043
    Points
    1 043
    Par défaut
    En Belgique peut-être mais en France on ne code jamais salement. On a une éthique de travail, une intégrité. On ne se roule dans la boue que si on y est obligé
    c'est une réponse très très très médiocre.


    On a une éthique de travail
    MDR
    Plus vite encore plus vite toujours plus vite.

  19. #279
    Membre expert
    Profil pro
    Inscrit en
    décembre 2003
    Messages
    1 480
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : décembre 2003
    Messages : 1 480
    Points : 3 405
    Points
    3 405
    Par défaut
    Quelqu'un saurait-il m'expliquer l'intérêt de ce (ces) sondage ? Où évidemment JavaScript arrive largement en tête avec plus de la moitié des votants, et probablement les 3/4 voir 9/10 des débats.

    Les 52% font-ils du Javascript ? Au travail ? Vos supérieurs, employeurs ne savent-ils pas que l'on ne fait bien que ce que l'on aime bien ? Si vous n'aimez pas, ne le faites pas, non ?

    Vous savez qu'il existe des lois contre le harcèlement au travail
    https://www.service-public.fr/partic...osdroits/F2354

    Le plaisir au travail, c'est plus de productivité, des gens souriants, moins de turn-over, moins d'arrêts-maladie, des projets qui aboutissent, des sites qui marchent, etc...

    Rendez-vous service, à vous, à vos collègues, à vos boss : Eclatez-vous !


  20. #280
    Expert éminent sénior
    Avatar de Sve@r
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    février 2006
    Messages
    7 682
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Oise (Picardie)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : février 2006
    Messages : 7 682
    Points : 21 851
    Points
    21 851
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par Sodium Voir le message
    on ne mélange pas des pommes et des poires
    Métaphore inadéquate dans mon exemple. Je ne mélange pas des pommes et des poires, je mélange des nombres de différents ensembles (complexes, rationnels, irrationnels, etc). C'est autorisé en mathématiques (où tous ces ensembles sont intégralement inclus les uns dans les autres => les naturels inclus dans les relatifs inclus dans les décimaux inclus dans les rationnels inclus dans les irrationnels inclus dans les complexes), je suis content qu'un langage me l'autorise aussi et ce, quelle que soit ma façon de représenter ces nombres.
    Et pour l'addition des chaines, là non plus ce n'est pas un mélange de pommes et de poires (je n'additionne pas des chaines à autre chose mais des chaines entre elles). C'est donc juste l'utilisation d'un même symbole pris dans un autre contexte. Là aussi c'est autorisé en mathématiques (par exemple la division de polynomes).
    Alors pourquoi refuser à un langage ce qui est autorisé en science ?

    PS: et au marché, quand les pommes et les poires sont au même prix, le marchand autorise à les mélanger

    Citation Envoyé par fredoche Voir le message
    Quelqu'un saurait-il m'expliquer l'intérêt de ce (ces) sondage ? Où évidemment JavaScript arrive largement en tête avec plus de la moitié des votants, et probablement les 3/4 voir 9/10 des débats.
    Pour que chacun sache qu'il n'est pas seul à penser ce qu'il pense...

    Citation Envoyé par fredoche Voir le message
    Au travail ? Vos supérieurs, employeurs ne savent-ils pas que l'on ne fait bien que ce que l'on aime bien ? Si vous n'aimez pas, ne le faites pas, non ?
    Oui mais là je crois que tu te heurtes à l'histoire. Le javascript est historiquement le premier langage permettant la techno web coté client. Si ton employeur veut un service web, il va s'orienter inévitablement vers javascript. Certes aujourd'hui d'autres technos ont émergé mais elles se heurtent à l'inertie du changement...
    Mon Tutoriel sur la programmation «Shell»
    Sinon il y en a pleins d'autres. N'oubliez pas non plus les différentes faq disponibles sur ce site

Discussions similaires

  1. Quels sont les langages de programmation que vous voulez apprendre en 2019 ?
    Par Michael Guilloux dans le forum Langages de programmation
    Réponses: 52
    Dernier message: 20/10/2019, 03h05
  2. Réponses: 140
    Dernier message: 06/12/2018, 16h54
  3. Quels sont les langages de programmation que vous détestez le plus, et pourquoi ?
    Par Siguillaume dans le forum Langages de programmation
    Réponses: 214
    Dernier message: 31/08/2017, 11h38
  4. Sondage : quels sont les langages de programmation que vous maîtrisez ?
    Par Michael Guilloux dans le forum Débats sur le développement - Le Best Of
    Réponses: 81
    Dernier message: 27/03/2017, 10h33

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo