Les langages typés dynamiques méritent-ils toutes les critiques? [fermé]

J'ai lu quelques articles sur Internet sur le choix du langage de programmation dans l'entreprise. Récemment, de nombreux langages typés dynamiques ont été populaires, à savoir Ruby, Python, PHP et Erlang. Mais de nombreuses entreprises conservent encore des langages à typage statique tels que C, C ++, C # et Java.

Et oui, l'un des avantages des langages à typage statique est que les erreurs de programmation sont détectées plus tôt, au moment de la compilation, plutôt qu'au moment de l'exécution. Mais il existe également des avantages avec les langages typés dynamiques. ( plus sur Wikipedia )

La raison principale pour laquelle les entreprises ne commencent pas à utiliser des langages comme Erlang, Ruby et Python semble être le fait qu’elles sont typées de manière dynamique. Cela semble également être la raison principale pour laquelle les utilisateurs de StackOverflow se sont opposés à Erlang. Voir Pourquoi avez-vous décidé "contre" Erlang .

Cependant, il semble que le typage dynamique dans les entreprises suscite de vives critiques, mais je ne comprends pas vraiment pourquoi il est si fort.

Pourquoi vraiment y a-t-il tant de critiques à l’encontre du typage dynamique dans les entreprises? Cela affecte-t-il vraiment le coût des projets ou quoi? Mais peut-être que je me trompe.

Oui, je crois qu'ils font.

Il y a quelques raisons qui doivent être prises en compte dans le choix d'une langue pour un nouveau projet:

• Vitesse d'exécution. Comparé à C / C ++ / Fortran, Perl et Python sont si lents que c’est drôle.
• Vitesse d'initialisation. Comparé aux langages rapides ci-dessus, Java tombe et pleure car la JVM ne cesse de charger et de charger while(1)....
• Prototype-capacité. Exécuter de manière exhaustive le travail de déclaration / définition requis pour C ++ ou Java augmente le niveau de la LOC, qui est la seule mesure connue qui soit corrélée de manière fiable avec les comptes de bogues. Cela prend aussi beaucoup de temps. Cela nécessite également un peu plus de réflexion sur les types et les connexions.
• Fiddlability interne. Il est bon de bricoler dynamiquement avec vos internes jusqu'à ce que vous commenciez à déboguer votre code à modification automatique . (Python, Lisp, Perl)
• Vérification de la correction. Un compilateur peut fournir un passage rapide d'une demi-correction de votre code en C ++, et cela peut être très agréable.
• Détails de l'analyse statique. C et Java ont une très bonne analyse statique. Perl n’est pas complètement analysable statiquement au niveau théorique (peut-être aussi en Python). Je suis raisonnablement sûr que Lisp n'est pas non plus.
• Les plateformes étranges ne prennent que C, en général.
• Chaîne de soutien. Si vous pouvez avoir un contrat sur lequel vous allez examiner et corriger vos bugs, c'est énorme .

Si vous pouvez présumer que l’organisation avec laquelle vous travaillez a un principe d’avenir (il existe un terme comptable), et ne décide pas simplement de ne pas travailler avec le logiciel, alors vous avez un bien meilleur cas pour en utilisant le logiciel. Puisqu'il n'y a pas de vente majeure (impliquant de prendre la responsabilité de la maintenir) Python / Perl / $ dynamic_language, cela réduit considérablement les risques.

D'après mon expérience, les responsables open source ont souvent du mal à assumer pleinement la responsabilité des corrections de bogues et à publier les mises à jour. "C'est gratuit, VOUS y travaillez!" n’est pas une réponse acceptable pour la plupart des entreprises (pas leurs compétences principales, entre autres).

Bien sûr, je ne parle pas du monde des webapp / startups, qui a tendance à jouer avec des règles de risque / récompense élevées et à rester très ouvert pour rester à la pointe de la technologie.

Vous accordez trop de crédit technique aux décideurs d'entreprise. Un vieil adage dit: "Personne n’a été congédié pour avoir acheté IBM." Si vous prenez un itinéraire différent et que les choses se gâtent (comme toujours), personne ne veut risquer d'être blâmé. Respectez les normes et blâmez quelqu'un d'autre.

Beaucoup d'entreprises plus jeunes deviendront éventuellement les entreprises de demain et utiliseront ces langues.

Et n'oublions pas les milliards de lignes de code écrites en VBA!

La raison pour laquelle les entreprises utilisent C, C ++, C # et Java ne l’est pas parce qu’elles sont typées statiquement (du moins pas directement). Les décideurs d'entreprise ne font pas ce genre de choix sur la base d'une comparaison objective des systèmes de types, je vous assure.

Les entreprises font attention sur:

• Frais d'entretien à long terme : pouvez-vous raisonnablement vous attendre à ce que les choses continuent à bien fonctionner dans 10 ans? C'est en fait une bonne chose si l'évolution du langage est conservatrice et rétrocompatible (comme avec Java). Le typage statique est utile ici car il détecte un type majeur de bogues au moment de la compilation avant d’être intégrés dans vos systèmes de production .....
• Disponibilité des talents - serez-vous capable de trouver des développeurs pour maintenir votre nouveau système? Et si le développeur d'origine part, tout le monde comprendra-t-il le code? Cela constitue un obstacle important à l’introduction de tout «nouveau» langage (surtout s’il crée également de nouvelles exigences en matière de déploiement, de construction de systèmes, de support opérationnel, etc.). Cela donne un avantage énorme aux langages largement utilisés (C, C ++, C # et Java)
• Coûts d'intégration : est-il facile de se connecter / intégrer avec d'autres technologies que vous avez déjà ou que vous êtes susceptible d'acquérir? Si vous avez déjà une pile de systèmes J2EE hérités, vous devez les intégrer. Une nouvelle solution Java EE sera probablement beaucoup plus pratique pour cela que, par exemple, Python.
• Prédiction / faible risque : la plate-forme / langue est-elle éprouvée et puis-je être sûr que cela fonctionnera? Ceci est généralement plus important que la simple productivité. Il est beaucoup plus facile pour un responsable de persuader son supérieur de lui donner un gros budget pour la construction d’un nouveau système que pour lui de revenir plus tard et de dire que cela n’a pas fonctionné .....
• Soutien / soutien aux entreprises - Les grandes organisations internationales sont-elles déterminées à soutenir le langage et la plate-forme? Signeront-ils un contrat pour me soutenir afin que je puisse avoir quelqu'un à qui faire appel en cas de problème?
• Neutralité du fournisseur / indépendance de la plate-forme - vais-je rester bloqué chez un seul fournisseur? Ou ai-je un large éventail de futures options de fournisseurs / chemins de transition disponibles? Vous ne voulez pas être coincé dans une impasse architecturale, incapable de progresser pendant que vos concurrents mangent votre déjeuner. Si vous faites votre travail correctement en tant qu’architecte d’entreprise, vous devez penser à au moins 5 à 10 ans à l’avenir.

Personnellement, je pense que si vous souhaitez utiliser des langages dynamiques dans l'entreprise, votre meilleure chance est de loin d'utiliser quelque chose qui se greffe sur un écosystème d'entreprise existant. Les plus remarquables sont les nouveaux langages dynamiques de JVM: par exemple, JRuby, Groovy, Clojure. En ce qui concerne la gestion informatique, il s’agit de choix de langage dynamique «sûrs», car ils fonctionnent bien avec le reste de l’écosystème d’entreprise Java.

La raison principale pour laquelle les entreprises ne commencent pas à utiliser des langages comme Erlang, Ruby et Python semble être le fait qu’elles sont typées de manière dynamique.

Je pense que ce n'est que leur principale excuse. La vraie raison est que les entreprises ne les prennent pas vraiment au sérieux et ont le sentiment d'être peut-être un peu trop amateurs. Java et .NET sont des «noms de grandes entreprises», ont un bon marketing commercial, un support client commercial, et sont donc pris très au sérieux.

Il est regrettable qu’il n’existe pratiquement aucun langage à typage statique aussi populaire que les grandes entreprises. Pourquoi les environnements de programmation open-source / logiciels libres sont-ils presque toujours typés de manière dynamique? Cela pourrait indiquer qu’un langage à typage statique n’est en fait pas si facile à créer et que le typage dynamique est un «hack man's hack». Si tel est le cas, les entreprises qui décident de ne pas utiliser des langages à typage dynamique pourraient avoir un intérêt.

• Les langues à typage dynamique ont tendance à être plus lentes que leurs cousins ​​à typage statique.
• Les erreurs sont plus difficiles à détecter et peuvent être plus difficiles à déboguer
• Le compilateur / interprète a tendance à être beaucoup moins fastidieux quant à ce que vous pouvez et ne pouvez pas faire. c'est-à-dire que vous ne détectez pratiquement que les erreurs de syntaxe au stade de la compilation
• Si vous n'êtes pas très prudent avec la conception d'un langage typé dynamiquement, vous vous retrouvez avec Javascript, qui est le langage de code-odeurs

EDIT: Je dois mentionner que mon principal langage de programmation actuellement est Python, qui est typé de manière dynamique. Personnellement, j'aime la liberté qui découle du fait de ne pas avoir à pré-déclarer les variables, mais il serait parfois utile de spécifier (par exemple) le type de paramètres qu'une fonction prend pour détecter les erreurs plus tôt que tard.

Les langages typés dynamiquement sont perçus (par certains programmeurs / responsables) pour produire un code qui ne fonctionne pas aussi bien. Le fait qu'un programme à typage dynamique compile vous en dit très peu sur son exactitude. Le fait qu'un langage à typage statique compile en dit beaucoup plus. (D'un autre côté, il y a encore beaucoup de chemin à faire entre compiler et faire la bonne chose, donc cela pourrait être moins significatif alors il semble)

Les langages à typage dynamique sont perçus comme des langages de script. Vous n'écririez jamais une application en bash ou dans un fichier de commandes. Tous les langages à typage dynamique ont tendance à être inclus dans cette catégorie (injustement).

Les langues à typage dynamique sont plus lentes que les langues à typage statique. (Mais nous verrons à quel point le travail sur les changements JIT fonctionne bien)

Remarque: ceci est principalement subjectif et basé sur mes expériences et impressions.

Les langues à typage dynamique sont très différentes des langues à typage statique. Ces différences deviennent probablement plus importantes dans les logiciels d'entreprise lourds que dans la plupart des autres applications.

Les langues à typage statique ont tendance à être très normatives. Une méthode ne prendra que des entrées qui correspondent exactement à sa signature. Les niveaux d'accès tendent à être très importants et les interfaces sont définies explicitement, avec des restrictions explicites mais sans ambiguïté en place pour appliquer ces définitions.

Les langages à typage dynamique, d’autre part, sont très pragmatiques. Les conversions de types se produisent souvent de manière implicite, les fonctions peuvent même jouer si vous fournissez le mauvais type d'entrée, à condition que le comportement soit suffisamment similaire. Dans des langages comme Python, même les niveaux d’accès seront basés sur des contrats plutôt que sur des restrictions techniques (c’est-à-dire queprivate parce qu’on vous dit de ne pas l’utiliser et qu’il porte un nom amusant).

Beaucoup de programmeurs préfèrent les langages dynamiques car ils permettent (sans doute) le prototypage rapide. Le code finit souvent par être plus court (ne serait-ce qu'en raison de l'absence de déclaration de type) et si vous voulez violer le protocole approprié parce que vous avez besoin d'une solution rapide et sale ou que vous voulez tester quelque chose, c'est facilement possible.

Or, la raison pour laquelle les entreprises «entreprises» préfèrent souvent les langages statiquement typés est précisément parce qu’elles sont plus restrictives et plus explicites à propos de ces restrictions. Même si dans la pratique même un code typé statiquement peut être cassé par des idiots avec un compilateur, de nombreux problèmes seront beaucoup plus visibles bien plus tôt dans le processus (c'est-à-dire avant l'exécution). Cela signifie que même si la base de code est volumineuse, monolithique et complexe, de nombreuses erreurs peuvent être facilement détectées, sans avoir à exécuter le code ni à l'envoyer au service d'assurance qualité.

La raison pour laquelle les avantages ne compensent pas les inconvénients pour de nombreux programmeurs extérieurs à cet environnement est que ce sont des erreurs qui seront souvent facilement détectées par une inspection minutieuse du code ou même par une tentative d'exécution. En particulier lorsque vous suivez une méthodologie basée sur des tests, ces erreurs deviennent souvent faciles à identifier et faciles à corriger. En outre, compte tenu du cycle de publication beaucoup plus court de ces entreprises, la productivité est souvent plus importante que la rigidité et de nombreux tests (de base) sont effectués par les développeurs eux-mêmes.

L'autre raison pour laquelle les entreprises n'utilisent pas beaucoup de langages à typage dynamique est le code hérité. Aussi stupide que cela puisse paraître à notre avis, les grandes entreprises vont souvent s'en tenir aux solutions qui fonctionnent, même si elles ont déjà dépassé leur durée de vie. C'est pourquoi tant de grandes entreprises appliquent Internet Explorer 6 et mettent tellement de temps à mettre à niveau leurs systèmes d'exploitation. C’est aussi la raison pour laquelle ils écrivent souvent du nouveau code dans de "vieux" langages (par exemple, les anciennes versions de Java): il est beaucoup plus facile d’ajouter quelques lignes de code à un logiciel inexploité que de faire approuver une réécriture complète dans un nouveau logiciel. la langue.

tl; dr: les langages statiques ressemblent davantage à de la bureaucratie, donc les gestionnaires d'entreprise les aiment mieux.

Non, je ne pense pas que les langues à typage dynamique méritent toutes les critiques. (Ou si vous préférez, ils méritent autant de critiques que les langages statiques).

D'après mon expérience (et je ne tente pas de généraliser cette affirmation), les programmeurs qui critiquent les langages dynamiques ne les ont pas utilisés. La conversation se passe généralement "mais avec une saisie statique, le compilateur intercepte tant d’erreurs!" et je dis "bien, ce n'est pas un problème, d'après mon expérience". (Habituellement, les autres programmeurs sont issus de Java, de Delphi ou d'un contexte similaire; je ne connais aucun programmeur Haskell ou ML.)

La seule chose qui m'a vraiment ronchonne est quand revendications quelqu'un que la technique Foo ne peut peut - être fait (ou peut - être très difficile à faire) dans un langage typé dynamiquement ... quand cette technique a été inventée en, par et pour un typage dynamique la langue. Des IDE? Smalltalk. Refactoring automatique? Smalltalk. Appelants-de / réalisateurs-de? Smalltalk.

Les entreprises n'adoptent tout simplement pas assez rapidement les nouveaux langages et outils, et il y a de bonnes raisons pour cela. Mais, lorsque l'un des outils grand public, tel que C #, implémente certaines de ces fonctionnalités, ils se retrouvent alors dans les entreprises classiques ....