Quel est le gain de productivité supposé du typage dynamique? [fermé]


82

J'ai souvent entendu dire que les langages à typage dynamique sont plus productifs que les langages à typage statique. Quelles sont les raisons de cette réclamation? Ne s'agit-il pas simplement de travailler avec des concepts modernes tels que la convention sur la configuration, l'utilisation de la programmation fonctionnelle, des modèles de programmation avancés et l'utilisation d'abstractions cohérentes? Certes, l'encombrement est moindre car les déclarations de type souvent redondantes (par exemple en Java) ne sont pas nécessaires, mais vous pouvez également omettre la plupart des déclarations de type dans les langages à typage statique qui utilisent l'inférence de type, sans perdre les autres avantages du typage statique. Et tout cela est disponible pour les langages modernes typés statiquement comme Scala.

Alors, qu'y a-t-il à dire pour la productivité avec la frappe dynamique qui constitue réellement un avantage du modèle type lui-même?

Précision: je suis plus intéressé par les projets de grande / moyenne taille que par les piratages rapides. :-)


10
Vous attendriez-vous à ce que le "duo statique" soit plus rapide ou plus productif que le "duo dynamique"?
Steve314

Que veux-tu dire par duo? Quoi qu'il en soit: je peux penser à deux raisons pour lesquelles le typage statique est plus productif que le typage dynamique: davantage de compilateurs vérifient les erreurs, achèvement du code, plus d'informations sur l'intention du programmeur dans le code. C'est pourquoi je parle de l'inverse.
Hans-Peter Störr

11
C'était une blague avec un point. Le "duo dynamique" est Batman et Robin. Ils ne craindraient presque pas autant la terreur criminelle de Gotham City s'ils s'appelaient "le duo statique". Puisque les développeurs sont des personnes, les choses superficielles peuvent faire la différence, peu importe la signification des termes.
Steve314

Ma première question est de savoir si je sais ce que je fais ou non. Si je le fais, je peux concevoir les choses à l'avance et le typage statique a du sens. Si je ne le fais pas, alors je vais devoir changer beaucoup de choses à la volée et la frappe dynamique sera plus facile. Common Lisp est le meilleur langage que j'ai trouvé quand je ne sais pas ce que je fais. (Avertissement: je n'ai fait qu'effleurer Haskell et je n'ai donc aucune idée du typage statique inféré.)
David Thornley

2
Je suis totalement d'accord avec John Skeet msmvps.com/blogs/jon_skeet/archive/2009/11/17/…
utilisateur

Réponses:


99

Je pense en fait que c'est un appel assez proche. Le typage dynamique et le typage statique ont leurs avantages.

Raisons pour lesquelles la frappe dynamique est plus productive:

  • C'est plus concis - beaucoup de code passe-partout peut être éliminé si tout est dynamiquement typé - déclarations de type, logique de transtypage, etc. maintenir (puisque vous n'avez pas besoin de parcourir de nombreuses pages de code pour comprendre ce qui se passe)
  • Des techniques plus faciles à "pirater" telles que la frappe de canard et la correction de singe peuvent vous donner des résultats très rapidement (bien que cela puisse vous dérouter plus tard ...)
  • Plus interactive - le typage dynamique est sans doute plus approprié pour la programmation interactive, de type REPL, pour le prototypage rapide, le débogage en temps réel d'instances de programmes en cours d'exécution ou même le codage en direct.
  • Les cas de test peuvent intercepter les erreurs d'exécution . En supposant que vous utilisiez TDD ou, à tout le moins, que vous disposiez d'une bonne suite de tests, cela devrait permettre de détecter tout problème de frappe dans votre code.
  • Meilleur polymorphisme - les langages dynamiques sont potentiellement plus susceptibles d'encourager la création de fonctions polymorphes et d'abstractions, ce qui peut augmenter la productivité et la réutilisation de code. Clojure, par exemple, utilise beaucoup le polymorphisme dynamique dans ses nombreuses abstractions .
  • Les prototypes - les modèles de données / objets basés sur des prototypes sont à mon avis plus puissants et flexibles que les hiérarchies d'héritage à typage statique. Les langages dynamiques sont plus susceptibles d'autoriser ou d'encourager une approche basée sur un prototype, le Javascript étant un bon exemple.

Raisons pour le typage statique étant plus productif:

  • Une meilleure conception : être forcé de penser dès le départ aux types de valeurs de votre logiciel peut vous pousser à adopter des solutions plus propres et plus logiques. (Je dis can - il est toujours possible de concevoir un très mauvais code ...)
  • Meilleure vérification au moment de la compilation - le typage statique peut permettre de détecter plus d’erreurs au moment de la compilation. C'est un énorme avantage et constitue sans doute la meilleure chose à propos des langages statiquement typés.
  • Saisie automatique - le typage statique peut également fournir davantage d'informations à l'EDI, de sorte que la saisie automatique du code ou de la recherche de documentation est plus efficace.
  • Décourage les hacks - vous devez conserver la discipline de type dans votre code, ce qui est susceptible d'être un avantage pour la maintenabilité à long terme.
  • Inférence de type - dans certaines langues (par exemple, Scala), cela peut vous apporter un grand nombre des avantages de concision des langages dynamiques qui maintiendront toujours la discipline de type.

Ma conclusion moyenne (après plusieurs années d’expérience des deux côtés de la clôture) est que le typage dynamique peut être plus productif à court terme, mais qu’il devient finalement difficile à maintenir à moins d’avoir de très bonnes suites de tests et une discipline de test.

D'autre part, je préfère en fait les approches typées de manière statique, car je pense que les avantages de la correction et le support des outils vous offrent une meilleure productivité à long terme.


14
+1, réponse très détaillée. La valeur du point "Meilleure vérification du temps de compilation" ne peut pas être assez soulignée.
NoChance

8
Outre l’inférence de type, il existe également une surcharge à la Haskell, des modèles C ++, des génériques et peut-être d’autres fonctionnalités du langage, qui offrent certains des avantages du typage Duck dans un cadre de typage statique, à condition que l’objet fournisse l’interface nécessaire "charlatans comme un canard"), vous pouvez l'utiliser, presque indépendamment du type nominal d'objets. Le "presque" est parce que certaines approches nécessitent une sorte de déclaration "de type charlatan, comme le type de canard", par exemple - la déclaration "class" en Haskell.
Steve314

45
Je suis tout à fait en désaccord avec votre affirmation selon laquelle "un code plus court ... est plus rapide à lire et à maintenir." Il y a une étape intermédiaire, la compréhension du code. J'ai dû gérer le code d'autres personnes dans Delphi et JavaScript, et le code Delphi est beaucoup plus facile à comprendre car il est plus détaillé. Et surtout parce que le code Delphi a des déclarations de type, contrairement à JavaScript. Lorsque vous traitez avec quelque chose de plus complexe que les primitives, les déclarations de type facilitent la tâche pour voir quelles sont vos variables et ce qu'elles peuvent faire, ce qui est une connaissance essentielle pour le travail de maintenance.
Mason Wheeler

21
Je ne suis pas d'accord avec la plupart des raisons données ici. Prenez Haskell, qui possède probablement le système de types le plus strict. Il a une REPL (en fait au moins deux), il possède un polymorphisme très puissant en effectuant une correspondance de motif sur les constructeurs et il est aussi concis que possible, bien plus que Javascript ou Python. Je suppose donc que certaines des raisons que vous mentionnez sont accidentelles plutôt que inhérentes à des langages faiblement typés.
Andrea

15
Je ne mettrais pas trop de confiance dans les "cas tests". Vous ne pouvez pas les comparer avec un bon système de types. Un système de types fournit la preuve que votre fonction sera déjà appelée avec au moins des paramètres de type corrects, tandis que les cas de test ne peuvent fournir que des preuves empiriques. Pourtant, même ces preuves sont recueillies dans un cadre artificiel.
Ingo

56

Avec les langages dynamiques, vous pouvez écrire du code de merde plus rapidement qu'avec un langage tapé.

Une fois que vous avez rapidement créé votre énorme pile d'éléments dynamiques, vous pouvez passer à un autre projet en toute sécurité sans vous soucier de la maintenance à long terme.

C'est un gain de productivité :)

Je plaisante, mais après avoir été impliqué dans un projet utilisant un «langage dynamique», j'ai été effrayé par la quantité de tests, documentations et conventions inutiles que vous devez gérer si vous voulez avoir un produit fonctionnel.
Et avec la joie de nombreuses erreurs d’exécution qui auraient pu être détectées lors de la compilation.
Oh, j'ai également oublié de parler de tous ces hacks et vaudous que la méta-programmation vous permet d'introduire dans votre code!

Le gain de productivité pourrait donc être un mythe pour les projets de taille moyenne à grande tout au long de leur vie.


11
Oui, mon expérience est la même. Un script Perl de 100 lignes est acceptable, et sans ces outils, nous aurions été perdus. Mais un projet de 100 000 lignes en perl sera probablement un cauchemar.
Ingo

3
... et puis vous avez JavaScript (non seulement dynamique mais aussi faiblement typé).
Den

16

Ce problème a aussi une vue théorique: un système de types statiques est essentiellement un prouveur de théorèmes spécialisé qui n’accepte le programme que s’il peut en prouver la correction de type. Tous les systèmes de types statiques rejettent certains programmes valides car aucun système de types statiques décidable n'est assez puissant pour prouver tous les programmes possibles corrects.

On pourrait soutenir que les programmes qui ne sont pas prouvables par un vérificateur de type statique sont des hacks et / ou un mauvais style, mais si vous possédez déjà un programme valide et que le vérificateur de type ne l'accepte pas, cela nuit certainement à votre productivité à court terme.

Dans certains cas, vous remarquerez peut-être que le vérificateur de types fait obstacle à des conteneurs génériques et à des co- / contravariances dans les arguments et les types de retour.


18
Inversement, si vous avez entré par erreur un programme incorrect , le compilateur vous en avertit immédiatement et met en surbrillance la mauvaise ligne. cela améliore votre productivité par rapport à la constatation d'un test infructueux et au débogage pour rechercher l'erreur.
MarkJ

5
Les conteneurs génériques et les co- / contravariances explicites sont censés "vous gêner" si vous le faites mal. Quel est l'avantage de la compilation de code qui échouera au moment de l'exécution?
M.Stramm

Généralement, le travail est considéré comme terminé à 0% jusqu'à ce qu'il exécute tous les tests avec succès. Ce n’est qu’alors que vos progrès pourront être considérés plus que rien. Dans cet esprit, je ne pense pas qu'il soit utile de mesurer votre productivité par rapport à quelque chose qui n'est pas encore terminé.
Pijusn

-1 Ne répond pas à la question ("gains de productivité", vous vous souvenez?). De plus, vous ne voulez probablement même pas écrire ces "programmes valides que le système de types rejette". Ce n'est pas parce que vous le pouvez que vous devriez. Et pourquoi auriez-vous même un "programme valide" que le vérificateur de type refuse? Quoi, avez-vous codé un programme Javascript et avez-vous soudainement essayé de le faire compiler en Java?
Andres F.

Les programmes valides que le système de types rejette peuvent aider à raccourcir votre code, ce qui entraîne moins d'erreurs que le système de types ne peut pas résoudre (moins de code = moins d'erreurs). Le compilateur / IDE mettant en surbrillance la ligne peut être créé dans des langages dynamiques avec des valeurs de test (par exemple, le développement piloté par REPL) afin que vous puissiez voir les valeurs intermédiaires et détecter les erreurs que votre système de texte ne peut pas, ainsi que les erreurs de type. Vous pouvez également utiliser l'inférence de type statique pour vous donner des avertissements de type.
aoeu256

15

Un avantage que j'ai trouvé avec la plupart des langages dynamiques est qu'ils facilitent l'écriture de code plus générique. Il est beaucoup plus facile d'écrire à un niveau d'abstraction plus élevé lorsque vous n'avez pas à vous battre avec le système de caractères pour le faire.

Vous n'avez pas à y penser autant - écrire du code qui fait quelque chose de non trivial avec n'importe quel objet en Java est difficile et nécessite probablement une réflexion qui est typée de manière dynamique; avec quelque chose comme JavaScript, écrire une fonction qui fait quelque chose d'intéressant pour tous les objets est une seconde nature. Un exemple parfait serait une fonction que j'ai récemment écrite qui prend un objet et remplace toutes ses méthodes par des méthodes qui font la même chose mais déclenchent également un événement. Je ne sais pas comment aborder de telles choses en Java. Cependant, je ne suis pas sûr de savoir à quel point cela est dû aux systèmes de types et à d’autres différences de langage.

Cependant, j'ai récemment commencé à utiliser Haskell. Haskell me permet d’écrire du code abstrait générique aussi facilement que n’importe quel langage dynamiquement typé que j’ai utilisé. Mon exemple Java / JavaScript ci-dessus n'a aucun sens en Haskell car il n'a pas d'objets, de méthodes, d'événements ou même de nombreuses mutations, mais il est très facile d'écrire d'autres types de code générique.

En fait, Haskell peut écrire du code générique que les langages à typage dynamique ne peuvent pas; un exemple parfait est la readfonction qui est fondamentalement l'opposé de toString. Vous pouvez obtenir un type Intou un Doubletype quelconque (dans la mesure où il appartient à une classe de type). Vous pouvez même avoir polymorphes constantes , donc maxBoundpeut être le maximum Int, Double, Char... etc., Tout dépend de quel type il est censé être.

Ma théorie actuelle est que le gain de productivité lié à l’utilisation d’un langage dynamique est toujours comparé à des langages tels que Java avec des systèmes de types moins capables, plus détaillés et moins flexibles.

Cependant, même le système de typage de Haskell a quelques problèmes gênants que vous n'auriez pas dans un langage typé dynamiquement. Le plus gros problème qui me dérange, c'est la façon dont les chiffres sont traités. par exemple, vous devez modifier le système de types à utiliser length(d'une liste) en tant que double, ce avec quoi vous n'auriez aucun problème sans un système de types. Une autre chose gênante que j'ai rencontrée est de travailler avec Word8(un type non signé) et les fonctions attendues Int.

Donc, en fin de compte, ne pas avoir de système de types facilite l'écriture de code générique sans trop réfléchir et évite également les pièges gênants des systèmes de types. Vous n'avez jamais à combattre le système de typage dans un langage dynamique, mais vous ne pouvez pas vous en fier non plus.


1
Oui, pour une raison quelconque, les systèmes de numérotation sont difficiles à obtenir. En scala c'est aussi un gâchis. Je pense que les systèmes de types dynamiques gagnent haut la main sur les systèmes de types statiques simples pour ce qui est de la facilité d'utilisation, mais ils perdent des systèmes plus avancés (comme Scala, Haskell, ML, etc., qui utilisent tous des variantes de system-F ).
Edgar Klerks le

3
Votre réponse est bien intentionnée, mais comporte des erreurs. Premièrement, il n’est pas vrai que les langages dynamiques "n’ont pas de système de type", ce qui explique pourquoi ils "facilitent la rédaction de code générique". Cela ne facilite pas les choses, comme le montre votre propre contre-exemple avec Haskell (vous réfutez votre propre affirmation!). "Vous n'avez jamais à combattre le système de types" est faux: vous le combattez chaque fois que vous devez corriger un bogue causé par un nombre insuffisant de vérifications typographiques statiques. Enfin, contraindre explicitement le Intretour d'une liste est trivial; exemple:, 1.0 + fromIntegral (length myList)c'est-à-dire simplement utiliser fromIntegral.
Andres F.

2
Enfin, "write code fast"! = "Être plus productif". Votre code doit fonctionner! Si vous écrivez un logiciel bogué que vous devrez ensuite consacrer au débogage et à la correction, vous ne serez pas productif.
Andres F.

"sans trop penser" drapeau rouge pour ce que la plupart des gens veulent dire quand ils parlent de langages à typage dynamique comme étant "plus productifs"
Ataraxia

Si les systèmes de types ont réellement amélioré la productivité, où se trouvent toutes les applications utiles dans Haskell ou Idris? Je pense que des choses comme la facilité avec laquelle il est facile de comprendre l'erreur de type, la "patchability" (possibilité de modifier votre application de manière imprévisible) et la vérification à 90% des erreurs de doctests et d'inférence de type peuvent être plus importantes.
aoeu256

7

Q: J'ai souvent entendu l'affirmation selon laquelle les langages à typage dynamique sont plus productifs que les langages à typage statique. Quelles sont les raisons de cette réclamation? "

Cela a des raisons historiques. Si vous remontez quelques décennies en arrière, les langages dynamiques étaient indiscutablement beaucoup plus productifs que les langages statiques (tout en étant beaucoup plus lents). Perl est clairement beaucoup plus productif que C si vous connaissez les deux et si la tâche à accomplir le permet. Mais au fil du temps, les langues se sont beaucoup empruntées et de nouvelles langues réduisent les écarts (en productivité et en performance).

Voici quelques points à considérer:

Ramassage des ordures : le ramassage des ordures augmente considérablement la productivité. Je crois que Java était le premier langage statique grand public avec GC. Auparavant, statique signifiait essentiellement la gestion manuelle de la mémoire. (Remarque: ici et dans la suite, je ne considère que les langues ordinaires. Il existe de nombreuses langues expérimentales et de niche qui fourniront des contre-exemples à chaque argument que je ferai.)

Sécurité de la mémoire : il s’agit d’une amélioration de la productivité qui vous évite de vous tirer une balle dans le pied. Avant les langages statiques "gérés" tels que Java, statique désignait généralement un accès direct à la mémoire. Le débogage fait également partie de la productivité, et un accès à la mémoire non sécurisé peut conduire à des bogues vraiment obscurs.

Systèmes de type encombrants. Avant l'introduction de types paramétrés (tels que les modèles ou les génériques) dans les langages statiques, les limitations des systèmes de types statiques étaient souvent un fardeau. Par exemple, en Java, vous deviez explicitement downcast chaque fois que vous sélectionniez un élément d'une collection. Donc, vous avez la surcharge syntaxique d'un casting et aucune sécurité de type. Compte tenu de l'omniprésence des collections dans la programmation, il s'agissait d'un inconvénient majeur.
Le fait de devoir déclarer le type de tout implique beaucoup de typage redondant, mais avec l'inférence de type moderne, cela peut être considérablement réduit.

Grande bibliothèque standard. Python a été annoncé comme "piles incluses" en raison de la grande bibliothèque standard. Ceci en comparaison avec C qui a une bibliothèque standard très minimaliste. Mais avec des plates-formes telles que Java et .net, une vaste bibliothèque standard devient standard et de nouveaux langages tels que Scala et F # en héritent "gratuitement".

Structures de données de première classe. Les langages dynamiques comme Perl et Python ont des structures de données de première classe intégrées, telles que des listes et des cartes, avec des raccourcis syntaxiques pratiques pour les opérations courantes. Comparé à cela, C n’a pas de collections intégrées à l’exception des tableaux de taille fixe.

Les fermetures et la syntaxe lambda - les langages dynamiques l'ont généralement depuis le début, mais les langages statiques l'ont adopté, plus récemment Java.

REPL la possibilité de tester rapidement les extraits de code de manière interactive est un avantage énorme. Toutefois, bien que les outils de l'EDI, comme la fenêtre "immédiate" de Visual Studio, les langages statiques puissent émuler cela dans une certaine mesure.

Outils avancés - en plus des points ci-dessus, où les langages statiques se rapprochent de la commodité des langages dynamiques, les éditeurs modernes tirent parti de l'analyse statique de manière à ce que les langages dynamiques peinent à correspondre. Par exemple, les éditeurs peuvent fournir des refactorisations automatiques sécurisées, ce qui est strictement impossible dans un langage dynamique.

En bout de ligne: historiquement, c'était vrai, mais aujourd'hui, la réponse est moins claire.


Q: Alors, qu'y a-t-il à dire pour la productivité avec le typage dynamique qui constitue réellement un avantage du modèle type lui-même?

Il est un peu difficile de séparer le modèle de frappe dynamique des langages dynamiques, mais à titre d'exemple, C # a adopté des fonctionnalités plus dynamiques au fil du temps, même s'il s'agit d'un langage statique. C'est vraiment une preuve d'avantage du modèle de type dynamique. Exemples:

Reflection La réflexion est fondamentalement une fonction de frappe dynamique. Vous inspectez les types d'objet au moment de l'exécution, au moment de la compilation. Lors de son introduction, il était plutôt mal vu, mais en C #, l’utilisation de la réflexion devient de plus en plus omniprésente, par exemple ASP.Net MVC utilise beaucoup la réflexion.

Attributs Les attributs sont un exemple de saisie dynamique. Vous pouvez ajouter des attributs arbitraires à une classe lors de la compilation, puis inspecter au moment de l'exécution (par réflexion) et manipuler des objets en fonction. Quelque chose comme MEP est fondamentalement un framework d'extension basé sur un modèle de type dynamique.

Linq to SQL, EF mv. Les différents transformateurs Linq inspectent les requêtes en tant qu’objets d’exécution et génèrent SQL à la volée. Cela ne devient pas plus dynamique que d'inspecter le code au moment de l'exécution. CodeDom est le revers de la médaille, où le code peut être généré à l'exécution

Roslyn Roslyn implémente fondamentalement eval, ce qui était autrefois considéré comme la caractéristique déterminante d'un langage réellement dynamique.

Dynamique Le dynamictype-est la fonctionnalité la plus explicitement dynamique de C # et a pour objectif de rendre l'interaction avec des objets externes et des langages plus simples et plus productifs. Mais il est également utilisé dans Asp.net MVC pour plus de commodité.

L'avantage de toutes les caractéristiques ci-dessus montre que le modèle dynamique présente des avantages certains, même dans un langage statique avec des types paramétrés, des types structurels et des inférences de types.


Je n'aime vraiment pas cette réponse, car presque tous les points n'abordent pas la question fondamentale: "Quel est le gain de productivité supposé du dactylographie dynamique ?" pas des langages dynamiques .
Nounou

@nanny pourriez-vous préciser votre différence perçue entre les langages dynamiques typés et les langages dynamiques? (c'est une de ces choses floues). Pourriez-vous donner un exemple de langage typé dynamique qui n'est pas un langage dynamique, avec des définitions claires pour chacun?

@nanny: La question concerne en réalité les "langages à typage dynamique", et pas seulement le "typage dynamique".
JacquesB

@ MichaelTel Désolé je n'ai pas été clair. Le typage dynamique est un aspect de tous les langages dynamiques. Cette réponse parle des autres aspects auxquels, historiquement, les langages dynamiques ont tendance à venir, sans pour autant aborder la partie de frappe dynamique.
Nounou

1
@ Nanny: En gros, je réponds à ceci: "J'ai souvent entendu l'affirmation selon laquelle les langages à typage dynamique sont plus productifs que les langages à typage statique. Quelles sont les raisons de cette affirmation?" - Je pense que les raisons de cette affirmation sont historiques et liées non seulement au typage dynamique, mais également à d'autres fonctionnalités d'amélioration de la productivité des langages dynamiques.
JacquesB

6

L’ensemble des fonctionnalités du langage moderne est si vaste que la dactylographie statique ou dynamique n’a pas beaucoup de poids.

La règle est la suivante: plus vos fonctionnalités linguistiques sont bonnes, plus votre code est court. C'est assez simple. Java montre à quel point le typage statique peut très mal tourner, ce qui donne à ses adversaires beaucoup à se nourrir. Les fonctionnalités de langage mal conçues ont généralement un coût, et le typage statique en Java est d’une part obligatoire (sinon la plupart des gens ne l’utiliseraient probablement même pas) et d’autre part, mal exécuté.
C'est pourquoi, en comparaison, la plupart des langages dynamiques brillent, même si je dirais que PHP ne vous rend pas la vie meilleure dans le grand total (du moins jusqu'à récemment), en raison de nombreuses autres bizarreries sans rapport avec les systèmes de types.

D'autre part, vous avez beaucoup de langages avec des systèmes de types expressifs qui ne vous gênent pas et qui ne sont même pas obligatoires. Et certains d'entre eux permettent même d'incorporer du code non typé, chaque fois que vous devez échapper au système de types.

Personnellement, j'utilise haXe, un langage avec inférence de types, sous-typage nominal et structurel, code non typé optionnel, types de fonction de première classe, types de données algébriques et macros lexicales (pas tout à fait mûr mais extrêmement puissant), tout en évitant la syntaxe arcane. Après avoir utilisé haXe pendant environ 3 ans maintenant, je suis arrivé à une conclusion simple:

La programmation devient beaucoup plus facile lorsque votre langue ne vous enferme pas dans des choix religieux concernant des paradigmes, mais tente simplement d’être un bon outil. Un certain nombre de langages statiques et dynamiques et de langages mixtes réussissent. Certains sont faciles à apprendre, les plus difficiles à maîtriser.
Leur puissance provient de la manière dont leurs caractéristiques individuelles peuvent être composées pour créer facilement des solutions simples à des problèmes complexes. Cela exclut une certaine orthogonalité qui ne peut être atteinte que par un équilibre délicat d'inclusion ou d'omission de toutes les caractéristiques linguistiques explorées jusqu'à présent. Si vous essayez d'ajouter du texte statique à Ruby, vous le paralyserez, si vous essayez de l'éloigner de Haskell, vous écrasez-le. Contrairement à cela: si vous l'enleviez à C, les gens le remarqueraient à peine et si vous l'enleviez à Java, certains pourraient vous remercier.

D'après mon expérience personnelle, je peux vous dire ceci: j'aime Ruby. Cela a élargi mes horizons et ma façon de concevoir les systèmes. IMHO, il devrait être utilisé pour enseigner aux gens la programmation en premier lieu. C'est discret, puissant, concis, amusant. Je comprends pourquoi quelqu'un venant d'une langue orthodoxe va en profiter.
Cependant, à long terme, le typage statique permet de reporter le travail à l’analyseur statique et, avec l’inférence de type, c’est gratuit. Il en résulte un code plus facile à gérer et souvent plus rapide.

Mais encore une fois, le typage statique seul ne peut rien faire. C'est une question de combinaison. Je pense que quelque part entre F #, Scala, Nemerle, OCaml ou haXe, vous pouvez trouver votre propre optimum. Mais cela dépend en définitive de vous, car le langage devrait vous permettre d’intégrer vos pensées sans effort, au lieu de vous obliger à les plier. Et après tout, rien ne rapporte plus de gain de productivité que si la programmation est amusante.


"La règle est la suivante: plus vos fonctionnalités linguistiques sont bonnes, plus votre code est court." Cela peut être dû à une opinion à un certain niveau, mais je ne pense pas que cette affirmation soit exacte. Un code plus court n'offre pas trop d'avantages en soi, autrement qu'il implique moins de dactylographie au moment de l'écriture et peut-être moins d'espace disque (ce qui est un facteur non important dans les langages compilés). Je pense que la qualité d’un bon langage est de transmettre le plus d’informations possibles de la manière la plus concise possible. Le typage dynamique n’est pas très auto-documenté et entraîne une perte de maintenabilité. Imar
Ataraxia

Vous pouvez compléter le code typé dynamique avec des informations telles que les valeurs par défaut / arguments de mot clé, les types obtenus à partir d'inférence de type, l'inférence de type dynamique à partir d'un compilateur JIT, ou simplement la journalisation de toutes les fonctions [passez en revue chaque fonction ou classe d'un programme en cours et remplacez-les par un version de la fonction qui enregistre ses arguments / résultats). Ensuite, vous pouvez voir le journal des exécutions précédentes d'une fonction. Une autre idée consiste à rejeter du code qui ne contient pas non plus d'annotations de type, de contrats d'exécution ou d'exemples de tests de session REPL, mais donne au développeur la possibilité de choisir l'un des trois.
aoeu256

3

Personnellement, la seule raison pour laquelle le typage dynamique aiderait serait si vous êtes un dactylographe très lent ou si vous créez des fonctions / méthodes / whatevers géants avec lesquels il est difficile de naviguer. Vous devez également entrer dans le problème des tests unitaires. Les types dynamiques nécessitent (sauf si vous aimez écrire du code erroné) des tests unitaires vigoureux (pour vous assurer que vos types dynamiques ne explosent pas de manière inattendue (la variable est principalement du canard, mais peut-être accidentellement parfois)). La statique va essayer beaucoup plus dur pour empêcher cela (Et oui, vous pouvez argumenter en faveur de tests unitaires rigoureux)


0

Je pense d’abord que vous devez définir la "productivité". Que signifie "productivité" et inclut-il?

Si «plus productif» signifie que vous voulez écrire moins de lignes de code pour implémenter la même fonctionnalité, alors oui, les langages de programmation à typage dynamique sont plus «productifs» que les langages à typage statique.

Toutefois, si vous prenez également en compte le temps consacré au débogage et à la correction des bogues, les langages de frappe dynamique risquent de ne pas être aussi productifs, car les langages de frappe dynamique ont tendance à pousser la vérification des erreurs vers l'exécution au lieu des langages de frappe statique peut effectuer des vérifications d’erreur au moment de la compilation. Comme il est communément admis que plus un bogue est détecté tardivement, plus il est coûteux de le réparer. Par conséquent, le code de frappe dynamique peut donner une productivité généralement égale, voire inférieure, à celle du code de frappe statique.


En général, il n'est pas vrai que vous puissiez écrire une fonctionnalité en moins de lignes en utilisant un langage dynamique. Quelles langues comparez-vous, de toute façon?
Andres F.

@AndresF. Oh, j'utilise principalement Python et C ++.
yaobin

1
Ok, mais vous ne pouvez pas généraliser dynamique vs statique lorsque vous comparez réellement Python et C ++. C ++ n'est pas un exemple particulièrement représentatif d'un langage avec typage statique. Il existe des langages statiques extrêmement concis, qui vous permettent plus ou moins d'écrire des programmes aussi brefs qu'avec Python. Donc, en général, votre assertion est fausse.
Andres F.

Oui, mais que se passe-t-il si vous modifiez votre programme alors qu'il est toujours en cours d'exécution? Tous les problèmes d'exécution se produiront simplement et vous pourrez les résoudre immédiatement. En Lisp, chaque fois que vous obtenez une erreur, vous pouvez simplement corriger votre programme, puis continuer à l'exécuter ... Oui, pour les chemins plus complexes, les annotations de type seraient bonnes [peut-être que vous pouvez utiliser une frappe progressive comme mypy & lisp], Cela peut également être une bonne idée d'éviter les chemins complexes dans n'importe quelle langue.
aoeu256

-1

Le gros avantage de la frappe dynamique est la productivité.

En plus du typage dynamique (paramètres par défaut, dictionnaires en tant que types intégrés, etc.), Python, Ruby, etc. ont de nombreux autres avantages pour la productivité. L’effet cumulatif sur la productivité du programmeur est impressionnant.

Les pénalités en termes de rapidité (ou d’absence de ressources!) Et de consommation de ressources ne sont pas aussi graves que prévu et, dans la plupart des cas, sont plus que compensées par la rapidité et la flexibilité du développement.

Il y a un (très vieux!) Du papier sur le sujet ici. Il s’agit de l’une des rares études bien menées sur la productivité des programmeurs et bon nombre des conclusions sont toujours valables.

Ce qui serait (probablement) différent si l’étude devait être menée aujourd’hui: -

  1. Les machines virtuelles Java ont été améliorées au delà de la reconnaissance.
  2. Les IDE modernes auraient amélioré la productivité des codeurs C ++ et Java, mais n'auraient eu que très peu d'impact sur les langages de script.
  3. C # serait inclus et probablement dans le même parc que Java mais légèrement mieux.

Le message est donc que si les performances ne sont pas un problème vraiment sérieux, les langages dynamiques augmenteront votre productivité.


2
Mon manque de clarté, c’est ce que fait exactement le typage dynamique pour augmenter votre productivité. Le papier est intéressant, mais il s'agit d'un très petit programme, et je ne sais pas comment cela se répercute sur les milliers de lignes de code de la plupart des programmes.
Hans-Peter Störr

5
Cette étude utilise uniquement C, C ++ et Java comme exemples de langages statiques, puis tente d'appliquer les conclusions trouvées aux langages de programmation traditionnels en général. Les trois langues partagent la même syntaxe de base, avec les mêmes imperfections inhérentes, réduisant la productivité, rendant la comparaison invalide. Ce n'est pas que les langages statiques soient improductifs, c'est que la famille C est improductive. S'ils avaient inclus un dialecte pascal dans leurs tests, ils auraient probablement abouti à des conclusions différentes.
Mason Wheeler

@mason - il existe très peu d'études objectives dans ce domaine. C'est l'une des rares études réelles avec des chiffres réels, etc. Le programme "échantillon" n'est pas anodin! Il combine des éléments de traitement de dictionnaire, des algorithmes complexes et de gros volumes de données. Le pourcentage élevé de tentatives infructueuses et d’échecs a confirmé la nature non triviale de la tâche.
James Anderson

2
-1 Vous ne parlez pas beaucoup de ce qui rend les langages typés dynamiques plus productifs. Les paramètres et dictionnaires par défaut peuvent être trouvés dans des langages statiques tels que Scala.
Jonas

1
@JamesAnderson Pire encore, le document auquel vous avez lié ne corrobore même pas votre argument. Il compare les "langages de script" (souvent dynamiques) aux " langages conventionnels " (souvent statiques). Maintenant, dites-moi, que sont exactement les langues "conventionnelles"? Pensez-vous que c'est la même chose que l'ensemble des langues avec le typage statique? Pire encore, le papier n’est pas si vieux. En l'an 2000, il existait déjà beaucoup de langages génériques dotés d'un typage statique, qui étaient sans doute plus productifs que les langages dynamiques.
Andres F.
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.