Études sur les langages à typage dynamique vs statique [fermé]

69

Existe-t-il des études sur l'efficacité des langages statiquement et dynamiquement typés?

En particulier:

  • Mesures de la productivité du programmeur
  • Taux de défauts

Comprend également les effets de l’utilisation ou non de tests unitaires.

J'ai vu beaucoup de discussions sur les mérites de chaque côté, mais je me demande si quelqu'un a déjà fait une étude à ce sujet.

productivity comparison type-systems dynamic-typing static-typing Winston Ewert
la source
8
@bigown, il ne me semble pas que les problèmes de productivité et les défauts soient liés à la théorie informatique
Winston Ewert
2
@ Winston: étudier ce genre de problèmes relève du travail des informaticiens et non des programmeurs.
Maniero
9
@bigown, oui, c’est un problème informatique mais ce n’est pas un problème de théorie informatique. La théorie CS traite essentiellement de ce que nous pouvons prouver mathématiquement à propos des programmes et de l'informatique. Les problèmes de productivité des programmeurs ne sont pas des questions de théorie cs. Il y a eu des discussions sur le typage dynamique à la fois ici et sur stackoverflow. Il n'y en a pas eu sur la théorie.
Winston Ewert
8
La question est parfaitement sur le sujet. Cette question traite de l’une des propriétés les plus importantes des outils que nous utilisons pour programmer.
Frank Shearar
4
@ Winston: Les systèmes de dactylographie appartiennent à la théorie CS, mais pas les études pratiques.
David Thornley

Réponses:

42

Quelques suggestions de lecture:

Pas exactement sur le typage statique, mais lié:

Quelques articles ou essais intéressants sur le sujet ou sur l'analyse statique des programmes en général:

Et pour ceux qui se demanderaient de quoi il s'agit:

Cependant, je doute qu'aucun de ceux-ci ne vous donne une réponse directe, car ils ne font pas exactement l'étude que vous recherchez. Ils seront intéressants à lire cependant.

Personnellement, Je considère fermement que le typage statique par rapport au typage dynamique facilite la détection des bogues. Je passe beaucoup trop de types à chercher des fautes de frappe et des erreurs mineures comme celles-ci dans JavaScript ou même le code Ruby. Et pour ce qui est de penser que le typage dynamique vous donne un coup de pouce à la productivité, je pense que cela revient essentiellement à l’outillage. Si les langages à typage statique disposent des outils appropriés pour permettre la recompilation en arrière-plan et fournir une interface REPL, vous bénéficiez des avantages des deux mondes. Scala fournit cela par exemple, ce qui facilite l'apprentissage et le prototypage dans la console interactive, mais vous offre les avantages du typage statique (et d'un système de type plus fort que beaucoup d'autres langages, hormis les langages ML). De même, je ne pense pas que Java ou C ++ me cause une perte de productivité (à cause du typage statique), tant que j'utilise un IDE qui m'aide à avancer. Lorsque je ne retourne au codage qu'avec des configurations simples (éditeur + compilateur / interprète), le logiciel semble plus lourd et les langages dynamiques semblent plus faciles à utiliser. Mais vous continuez à chasser les insectes. J'imagine que les gens diraient que la question de l'outillage est un argument réversible, car si l'outillage était préférable pour les langages dynamiques, la plupart des erreurs et des fautes de frappe seraient signalées au moment du codage, mais cela reflète la faille du système, à mon avis. Malgré tout, je prototype habituellement dans JRuby et coderai plus tard en Java la plupart de mes tâches. comme si les outils étaient meilleurs pour les langages dynamiques, alors la plupart des bogues et des fautes de frappe seraient signalés au moment du codage, mais à mon avis, cela reflète la faille du système. Malgré tout, je prototype habituellement dans JRuby et coderai plus tard en Java la plupart de mes tâches. comme si les outils étaient meilleurs pour les langages dynamiques, alors la plupart des bogues et des fautes de frappe seraient signalés au moment du codage, mais à mon avis, cela reflète la faille du système. Malgré tout, je prototype habituellement dans JRuby et coderai plus tard en Java la plupart de mes tâches.

AVERTISSEMENT: certains de ces liens ne sont pas fiables et d'autres passent par des portails de différentes sociétés informatiques utilisant des accès payants pour les membres. Désolé, j'ai essayé de trouver plusieurs liens pour chacun d'entre eux, mais ce n'est pas aussi bon que je le souhaiterais.

haylem
la source
Cette découverte de bogue - est-ce principalement à cause de noms de variables mal orthographiés, ou de noms de méthodes, ou quelque part entre les deux? (Je déteste la déclaration de variable implicite pour cette raison précisément: dans Smalltalk, vous déclarez toutes vos variables en haut de sorte que vous sachiez immédiatement quand vous avez mal entré un nom de variable. été utilisé dans l'image avant))
Frank Shearar
En ce qui concerne l’outillage, je dois dire que cela dépend de votre langue - Smalltalk dispose d’excellents outils, y compris un navigateur de refactoring que Eclipse n’a pas encore rattrapé (on me dit).
Frank Shearar
@Frank Shearar, depuis que j'ai commencé avec Ruby (venant de Java), je me suis rendu compte que ce que dit @ haylem ne s'applique probablement pas à Smalltalk. Mon mantra ne dit pas non plus que la refactorisation automatique est impossible dans les langs typés dynamiquement. Je suis tout à fait d'accord avec la section "personnellement" de haylem .... ignorant SmallTalk bien sûr :) C'est juste, dans une certaine mesure, car SmallTalk, bien qu'il ne soit pas mort, ne jouit certainement pas de la popularité de Python ou de Ruby (maintenant en octobre 2010). ).
Dan Rosenstark
3
@ haylem, je vous remercie personnellement de m'avoir fait sentir que je ne suis pas la seule personne au monde à travailler dans des langages dynamiques, mais, lorsque vous avez le choix, vous avez souvent choisi des langages à typage statique (même cas, Java contre JRuby ou Sensationnel).
Dan Rosenstark
4
C'est intéressant parce que ma préférence pour le dactylographie dynamique est différente. Je veux dire que les compilations rapides et les interprètes interactifs sont utiles, mais ils ne sont pas la raison pour laquelle j'aime la frappe dynamique. J'aime la dactylographie dynamique car je rencontre de nombreuses situations dans lesquelles les langages de saisie statiques rendent difficile, voire impossible, la description d'un concept particulier.
Winston Ewert
19

Hier encore, j'ai trouvé cette étude: les tests unitaires ne suffisent pas. Vous devez aussi taper statique.

En gros, l'auteur utilisait un outil capable de convertir automatiquement un projet d'un langage de frappe non statique en un langage de frappe statique (python en haskell).

Il a ensuite sélectionné un certain nombre de projets Python Open Source comprenant également un nombre raisonnable d'unités de test et les a automatiquement convertis en haskell.

La traduction en Haskell a révélé une série d'erreurs liées au type des variables: les erreurs n'ont pas été découvertes par les unités de test.

PBrando
la source
4
Vérité inconfortable de la frappe dynamique.
Den
6
"La traduction en Haskell a révélé une série d'erreurs liées au type des variables: les erreurs n'ont pas été découvertes par les unités de test.": Avec un langage dynamiquement typé, vous devez tester manuellement les propriétés de votre code de manière statique les langues tapées sont automatiquement vérifiées par le compilateur. C'est à la fois une perte de temps et une source d'erreurs. +1
Giorgio
4
J'ai répondu à une annonce sur ce lien sur Reddit. Je ne pense pas que les conclusions tirées du document soient raisonnables.
Veedrac
Les deux systèmes de dactylographie ont des avantages / inconvénients et leurs utilisations. C'est comme discuter de porter une mitrailleuse à un combat au corps à corps. C'est une guerre de religion loin d'être terminée. Cela dit, je suis d'accord avec Veedrac. Les langues non statiques ont besoin de plus de scénarios de test pour détecter les erreurs causées par les types. C'est leur nature et leurs inconvénients. Cependant, un programmeur doit écrire un test qui détecte une erreur dans le code en raison d'un état d'entrée inattendu, pas nécessairement un test exhaustif pour le type d'entrée.
André Figueiredo
10
  • Lien vers la discussion de l'article d'ACM intitulé " Une expérience sur les systèmes de types statiques et dynamiques " (2010) de Stephan Hanenberg (cité par Lorin Hochstein dans un précédent article).
  • Conclusion: la productivité pour une qualité similaire était supérieure dans un langage dynamique.
  • Biais potentiels / problèmes de validité: les sujets expérimentaux étaient tous des étudiants. En outre, la variété des tâches de programmation est limitée (les sujets ont été invités à implémenter un scanner et un analyseur syntaxique).
  • Document ACM " Les langages de programmation affectent-ils la productivité? " (2007) de Delorey, Knudson et Chun.
  • Conclusion: JavaScript, Tcl, Perl plus productif que C # C ++ et Java. Python et PHP tombent au milieu.
  • Préjugés / problèmes de validité potentiels: Aucune mesure de la qualité (comme les bugs découverts après la publication). Aucune mesure de fiabilité (les logiciels écrits dans des langages à typage statique sont-ils plus fiables?). Biais d'échantillon - tous les projets ont été ouverts et proviennent de référentiels CVS open source. En outre, aucune distinction entre les langages faiblement typés et fortement typés (c'est-à-dire les pointeurs).
  • Thèse " Étude empirique de la productivité et de la qualité des logiciels " (2008) de Michael F. Siok
  • Conclusion: le choix du langage de programmation n'influence pas de manière significative la productivité ou la qualité. Cependant, cela affecte les coûts de main-d'œuvre et "la qualité au sein du portefeuille global de projets logiciels".
  • Biais / problèmes de validité potentiels: Limité au domaine avionique. Les langages de programmation auraient tous pu être typés de manière statique. Je n'ai pas lu la thèse et je ne peux donc pas en évaluer la rigueur.
    Mon avis. Il existe peu de preuves que les langages à typage dynamique sont plus productifs, mais ce n’est pas concluant. (1) De nombreux facteurs n'étaient pas contrôlés, (2) il y a trop peu d'études, (3) il y a eu peu ou pas de discussion sur ce qui constitue une méthode d'essai appropriée.
ahoffer
la source
6

Voici un point de départ:

Le document conteste la sagesse généralement reçue selon laquelle, toutes choses étant égales par ailleurs, les programmeurs écrivent le même nombre de lignes de code à la fois, quelle que soit la langue. En d'autres termes, le document devrait servir de preuve empirique à l'appui du fait que la productivité mécanique (lignes de code écrites) n'est pas une bonne mesure de la productivité fonctionnelle et doit au moins être normalisée par le langage.

Piet Delport
la source
5
Pour les non-membres de l'IEEE, quel est le résumé de base?
Frank Shearar
1
@Frank Shearar, leur conclusion est que le langage de programmation affecte la productivité. Ils mesurent des lignes de code par programmeur et par langue et par an. Je ne suis pas sûr que ce soit une bonne mesure de la productivité.
Winston Ewert
3
@ Winston: C'est définitivement une métrique imparfaite. Vous constaterez que COBOL est un langage très productif: il faut beaucoup de lignes pour faire quelque chose d’utile, mais elles sont assez faciles à écrire.
David Thornley
Winston, David: Je suis à peu près sûr que les auteurs ne suggèrent pas que la productivité des lignes de code est une mesure de la productivité fonctionnelle . Au lieu de cela, le document conteste la sagesse généralement reçue selon laquelle, toutes choses étant égales par ailleurs, les programmeurs écrivent le même nombre de lignes de code à la fois, quelle que soit la langue. En d'autres termes, le document devrait servir de preuve empirique à l'appui du fait que la productivité mécanique (lignes de code écrites) n'est pas une bonne mesure de la productivité fonctionnelle et doit au moins être normalisée par le langage.
Pi Delport
Je suis d'accord avec ça. Mais cela ne sert pas à répondre à ma question initiale.
Winston Ewert
1

J'ai trouvé un langage statique versus un langage dynamique: une revue de littérature qui répertorie quelques études sur le sujet et donne un bon résumé sur chaque étude.

Voici le résumé:

Parmi les expériences contrôlées, seules trois montrent un effet suffisamment important pour avoir une signification pratique. L'étude Prechelt comparant C, C ++, Java, Perl, Python, Rexx et Tcl; l'étude Endrikat comparant Java et Dart; et l'expérience de Cooley avec VHDL et Verilog. Malheureusement, ils ont tous des problèmes qui font qu’il est difficile de tirer une conclusion vraiment solide.

Dans l'étude de Prechelt, les populations étaient différentes entre les langages dynamiques et les langages typés, et les conditions pour les tâches étaient également différentes. Une étude de suivi a illustré le problème en invitant les lispers à proposer leurs propres solutions au problème, en comparant des personnes comme Darius Bacon à des étudiants de premier cycle au hasard. Un suivi du suivi consiste littéralement à comparer le code de Peter Norvig au code d’étudiants au hasard.

Dans l'étude Endrikat, ils ont spécifiquement choisi une tâche pour laquelle ils pensaient que le typage statique ferait une différence et ils ont tiré leurs sujets d'une population où tout le monde avait suivi des cours en utilisant le langage à typage statique. Ils ne précisent pas si les étudiants avaient ou non une expérience du langage à typage dynamique, mais il semble raisonnable de supposer que la plupart ou tous avaient moins d'expérience dans le langage à typage dynamique.

L’expérience de Cooley a été l’une des rares à attirer des membres d’une population non-étudiante, ce qui est formidable. Mais, comme avec toutes les autres expériences, la tâche était une tâche de jouet triviale. Bien qu'il semble accablant qu'aucun des participants au langage VHDL (langage statique) n'ait été en mesure de terminer la tâche à temps, il est extrêmement inhabituel de vouloir terminer une conception matérielle en une heure et demie ailleurs qu'en dehors d'un projet d'école. Vous pourriez faire valoir qu'une tâche importante peut être décomposée en plusieurs tâches plus petites, mais un contre-argument plausible est qu'il existe des coûts fixes utilisant le VHDL qui peuvent être amortis pour de nombreuses tâches.

Pour ce qui est du reste des expériences, la principale conclusion que j’en tire est que, dans l’ensemble des circonstances décrites dans les études, tout effet, s’il existe, est faible.

Passons maintenant aux études de cas. Les deux études de cas pour la recherche de bogues sont une lecture intéressante, mais elles ne justifient pas vraiment les types. L'un d'eux montre que la transcription de programmes Python en Haskell trouvera un nombre non nul de bogues de gravité inconnue qui pourraient ne pas être détectés lors de tests unitaires orientés couverture de ligne. La paire de papiers Erlang montre qu'il est possible de détecter certains bugs difficiles à détecter à l'aide de tests, dont certains sont graves, à l'aide d'une analyse statique.

En tant qu'utilisateur, je trouve cela pratique lorsque mon compilateur me donne une erreur avant d'exécuter des outils d'analyse statiques distincts, mais il s'agit d'une erreur mineure, peut-être même inférieure à la taille de l'effet des études contrôlées répertoriées ci-dessus.

L’étude de cas 0install (qui comparait différentes langues à Python et a finalement opté pour Ocaml) est une des choses les plus intéressantes que j’ai rencontrées, mais c’est le genre de chose subjective que tout le monde interprétera différemment, ce que vous pouvez voir en regardant .

Cela correspond à l’impression que j’ai (dans mon petit coin du monde, ACL2, Isabelle / HOL et PVS sont les prouveurs les plus couramment utilisés, et il est logique que les gens préfèrent plus d’automatisation lorsqu’ils résolvent des problèmes dans l’industrie). aussi subjectif.

Et puis, il y a les études qui extraient des données de projets existants. Malheureusement, je ne pouvais trouver personne qui fît quoi que ce soit pour déterminer le lien de causalité (par exemple, trouver une variable instrumentale appropriée), alors ils ne mesuraient que les corrélations. Certaines corrélations sont inattendues, mais il n’ya pas assez d’informations pour déterminer pourquoi.

La seule étude d'exploration de données qui présente des données potentiellement intéressantes sans exploration supplémentaire est l'examen de Smallshire sur les bogues Python, mais il n'y a pas suffisamment d'informations sur la méthodologie pour comprendre ce que son étude signifie réellement, et on ne voit pas pourquoi il a laissé entendre données pour d'autres langues sans présenter les données3.

Certaines des omissions notables des études sont des études approfondies utilisant des programmeurs expérimentés, sans parler des études qui ont une population importante de «bons» ou de «mauvais» programmeurs, qui examinent tout ce qui approche un projet important (là où j'ai travaillé, un projet de trois mois considérés comme petits, mais de plusieurs ordres de grandeur plus grands que tout projet utilisé dans une étude contrôlée), en utilisant des langages «modernes» à typage statique, en utilisant un typage progressif / facultatif, en utilisant des IDE classiques modernes (comme VS et Eclipse), en utilisant des IDE modernes radicales (comme LightTable), utiliser les éditeurs de la vieille école (comme Emacs et vim), effectuer la maintenance sur une base de code non triviale, effectuer la maintenance dans un environnement réaliste, effectuer la maintenance sur une base de code déjà connue, etc.

Si vous consultez les commentaires Internet de ces études, la plupart d’entre elles sont diffusées pour justifier un point de vue ou un autre. L’étude Prechelt sur les dynamiques et les statiques, ainsi que les suivis sur Lisp sont les favoris de longue date des défenseurs des langues dynamiques, et l’étude sur l’exploitation de github est récemment devenue à la mode parmi les programmeurs fonctionnels.

Mr.WorshipMe
la source
0

Honnêtement, je ne pense pas que taper statique ou dynamique soit la vraie question.

Je pense qu'il y a deux paramètres qui devraient venir en premier:

  • le niveau d'expertise dans la langue: plus vous êtes expérimenté, plus vous en savez sur les "pièges" et plus vous aurez de chances de les éviter / de les localiser facilement. Ceci est également vrai pour l'application / le programme particulier sur lequel vous travaillez.
  • testing: J'adore le typage statique (j'aime la programmation en C ++: p) mais il y a tellement de choses qu'un compilateur / analyseur statique peut faire pour vous. Il est simplement impossible d'avoir confiance en un programme sans l'avoir testé. Et je suis tout à fait pour les tests flous (le cas échéant), parce que vous ne pouvez pas penser à toutes les combinaisons d'entrées possibles.

Si vous êtes à l'aise dans cette langue, vous écrirez du code et vous pourrez facilement localiser les bogues.

Si vous écrivez du code découplé et testez chaque fonctionnalité de manière approfondie, vous produirez du code bien rodé et vous serez donc productif (car vous ne pouvez pas être considéré comme productif si vous n'évaluez pas la qualité du produit, n'est-ce pas? )

J’estimerais donc que le débat statique / dynamique en matière de productivité est tout à fait théorique, ou du moins, largement dépassé par d’autres considérations.

Matthieu M.
la source
2
S'il s'agit d'une contre-question, où est la question? :) Je conviens que d'autres facteurs sont plus importants que le typage statique vs dynamique. Toutefois, les défenseurs du typage dynamique revendiquent une meilleure productivité et ceux du typage statique, une meilleure qualité de code. Je me demandais si quelqu'un avait des preuves à l'appui de ses affirmations.
Winston Ewert
@ Winston: j'ai enlevé le bit de compteur: p Comme vous l'avez mentionné, il s'agit principalement de revendications. Je pense que la plupart des défenseurs du typage dynamique associent facilité d’utilisation et typage dynamique, la facilité d’utilisation dépendant principalement des outils. Je conviens que la possibilité d'écrire des prototypes jetables rapides et d'expérimenter des commandes courtes à l'aide d'un interpréteur est un gain de productivité, mais même Haskell (peut-être le langage avec le système de types le plus impressionnant du moment) dispose d'un interprète pour une expérimentation rapide: )
Matthieu M.
Mais jusqu'à ce que quelqu'un réalise réellement une étude sur cette question - que ce soit la méthodologie, les outils ont un impact plus important que le langage sur le taux de défauts, la productivité - nous finissons simplement par comparer des anecdotes.
Frank Shearar
0

Voici quelques-uns:

  • Stefan Hanenberg. 2010. Une expérience sur les systèmes de types statiques et dynamiques: des doutes sur l'impact positif des systèmes de types statiques sur le temps de développement. Dans Actes de la conférence internationale ACM sur les langages et applications pour systèmes de programmation orientée objet (OOPSLA '10). ACM, New York, NY, États-Unis d'Amérique, 22-35. DOI = 10.1145 / 1869459.1869462 http://doi.acm.org/10.1145/1869459.1869462

  • Daniel P. Delorey, Charles D. Knutson et Scott Chun, "Les langages de programmation affectent-ils la productivité? Une étude de cas utilisant des données de projets Open Source", p. 8, Premier atelier international sur les nouvelles tendances en matière de recherche-développement sur les logiciels libres (FLOSS) '07: Ateliers ICSE 2007), 2007

  • Daly, M .; Sazawal, V., Foster, J .: Work in Progress: une étude empirique du typage statique en Ruby, atelier sur l'évaluation et l'utilisabilité des langages et des outils de programmation (PLATEAU) à ON-WARD 2009.

  • Lutz Prechelt et Walter F. Tichy. 1998. Une expérience contrôlée pour évaluer les avantages de la vérification du type d'argument de procédure. IEEE Trans. Softw. Eng. 24, 4 (avril 1998), 302-312. DOI = 10.1109 / 32.677186 http://dx.doi.org/10.1109/32.677186

Lorin Hochstein
la source