Est-ce que les langages typés de dynamiques méritent toutes les critiques? [fermé]

Question

J'ai lu quelques articles sur Internet sur la programmation choix de la langue dans l'entreprise. Récemment, de nombreuses langues typées dynamiques ont été très populaires, à savoir Ruby, Python, PHP et Erlang. Mais de nombreuses entreprises restent encore avec les langages typées statiques comme C, C ++, C # et Java.

Et oui, l'un des avantages des langues typées statiques est que les erreurs de programmation sont prises plus tôt, au moment de la compilation, plutôt qu'au moment de l'exécution. Mais il y a aussi des avantages avec les langages typés de dynamique. ( plus sur Wikipedia )

La principale raison pour laquelle les entreprises ne commencent pas à utiliser les langues comme Erlang, Ruby et Python, semblent être le fait qu'ils sont tapés dynamiques. Cela semble aussi être la principale raison pour laquelle les gens sur StackOverflow décident contre Erlang. Voir Pourquoi avez-vous décidé "contre" Erlang.

Cependant, il semble y avoir une forte critique contre typage dynamique dans les entreprises, mais je ne suis pas vraiment pourquoi il est forte.

Vraiment, pourquoi est-il tant de critiques contre le typage dynamique dans les entreprises? Est-il vraiment d'incidence sur le coût des projets que beaucoup, ou quoi? Mais peut-être que je me trompe.

Answer 1

Oui, je crois qu'ils le font.

Il y a quelques raisons qui doivent être pris en considération dans le choix d'une langue pour un nouveau projet:

• Vitesse d'exécution. Par rapport à C / C ++ / Fortran, Perl et Python sont lents il est drôle.
• Vitesse d'initialisation. Par rapport à ce qui précède langues rapides, Java tombe et crie que la machine virtuelle Java conserve le chargement et le chargement et le ... while(1) ....
• Prototype-capacité. va faire et exhaustivement par la déclaration / travail de définition requis pour C ++ ou Java augmente le COL, qui est le que connu métrique qui est en corrélation fiable avec bugcounts. Il faut aussi beaucoup de temps. Elle exige aussi un peu plus de réflexion sur les types et les connexions.
• fiddlability interne. Dynamiquement déconner avec vos internes est grande jusqu'à ce que vous commencez à déboguer votre code automodifiant . (Python, Lisp, Perl)
• vérification Justesse. Un compilateur peut fournir un rapide une fois de plus passer semi-correct de votre code en C ++, et cela peut être vraiment agréable.
• Détails d'analyse statique. C et Java ont assez bonne analyse statique. Perl est pas complètement statique analysable à un niveau théorique (Peut-être Python aussi). Je suis raisonnablement sûr que Lisp est pas non plus.
• plates-formes étranges ne prennent que C, en général.
• chaîne de soutien. Si vous pouvez avoir un contrat que vous obtenir vos bogues regardé et a travaillé sur, que de énorme .

Si vous pouvez supposer que l'organisation que vous travaillez a un principe de « l'avenir » (Il est un terme comptable pour cela), et pas simplement décider au hasard de ne pas travailler sur le logiciel, vous avez une bien meilleure cas pour l'utilisation du logiciel. Comme il n'y a pas d'affaires majeur vente (portant implication de prendre la responsabilité de le maintenir) Python / Perl / $ dynamic_language, il réduit considérablement le risque.

Dans mon expérience, mainteneurs open source ont souvent un problème avec la responsabilité de prendre pleinement et de libérer des mises à jour des corrections de bugs. « Il est gratuit, vous travaillez là-dessus! » pas une réponse qui est acceptable pour la plupart des entreprises (pas leurs de compentencies de base, entre autres).

Bien sûr, je ne parle pas du webapp / monde de démarrage, ce qui a tendance à jouer par des règles de haute récompense / risque élevé et être très ouvert à rester sur le bord mousser de la technologie.

Answer 2

Vous donnez beaucoup trop de crédit technique aux décideurs d'entreprise. Il y a un vieux dicton: « Personne n'a été tiré pour l'achat d'IBM. » Si vous allez un itinéraire différent, les choses deviennent rocheux (ils le font toujours), personne ne veut risquer d'être blâmé. Bâton aux normes et blâmer quelqu'un d'autre.

Il y a beaucoup de jeunes entreprises qui finissent par devenir les entreprises de demain et utilisera ces langues.

Et ne faut pas oublier les lignes buggillion de code écrit en VBA!

Answer 3

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

les entreprises faire soins sur:

• les coûts d'entretien à long terme : peut-on raisonnablement attendre des choses de continuer à travailler bien dans 10 ans? Il est en fait une bonne chose si l'évolution du langage est conservatrice et rétrocompatible (comme Java). Le typage statique est ici utile car il attrape un type important de bugs au moment de la compilation avant qu'ils entrent dans vos systèmes de production .....
• disponibilité Talent - vous serez en mesure de trouver des développeurs pour maintenir votre nouveau système brillant? si les feuilles de développeur d'origine, tout le monde va comprendre le code? Cela place un obstacle élevé sur l'introduction d'une « nouvelle » langue (surtout si elle crée également de nouvelles exigences pour le déploiement, les systèmes de construction, le soutien opérationnel, etc.). Cela donne un avantage massif aux langues qui sont largement utilisés (C, C ++, C # et Java)
• Les charges d'intégration : il est facile de se connecter / intégrer à d'autres technologies que vous avez déjà en place ou sont susceptibles d'acquérir? Si vous avez déjà une pile de systèmes J2EE existants, alors vous devez intégrer avec eux. Une nouvelle solution Java EE est susceptible d'être beaucoup plus pratique pour ce que par exemple Python.
• Predicatbility / faible risque : est la plate-forme éprouvée / langue, 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 gestionnaire de convaincre son patron de lui donner un gros budget pour la main-d'œuvre pour construire un nouveau système que pour lui pour revenir plus tard et dire qu'il n'a pas travaillé .....
• Enterprise Support / support - sont les grandes organisations internationales engagé à soutenir la langue et la plate-forme? Vont-ils signer un contrat pour me soutenir pour que j'ai quelqu'un d'appeler sur si les choses tournent mal?
• neutralité du vendeur / l'indépendance de la plate-forme - vais-je obtenir enfermé dans un seul fournisseur? Ou dois-je un large éventail d'options futures fournisseurs / chemins de transition disponibles? Vous ne voulez pas être coincé dans une impasse architecturale, incapable de progresser alors que vos concurrents manger votre déjeuner. Si vous faites votre travail correctement comme architecte d'entreprise, vous devez penser au moins 5-10 ans d'avance sur ce genre de choses.

Personnellement, je pense que si vous voulez utiliser les langages dynamiques dans l'entreprise, votre meilleure chance de loin est d'utiliser quelque chose qui piggy-dos à un écosystème d'entreprise existant. Les plus notables sont les nouveaux langages JVM dynamique: par exemple JRuby, Groovy, Clojure. En ce qui concerne la gestion informatique concernés, ce sont des choix de langue dynamique « sûrs », car ils fonctionnent à l'intérieur et jouent bien avec le reste de l'écosystème Java d'entreprise.

Answer 4

  

La principale raison pour laquelle les entreprises ne commencent à utiliser les langues comme Erlang, Ruby et Python, semblent être le fait qu'ils sont tapés dynamiques.

Je pense que cela ne leur excuse principale. La vraie raison est que les entreprises ne les prennent pas vraiment au sérieux et que le sentiment qu'ils sont peut-être un peu trop amateur. Java et .NET sont « grands noms commerciaux », ont un bon marketing commercial, le soutien à la clientèle commerciale, et sont donc largement pris très au sérieux.

Il est regrettable qu'il n'y ait pratiquement pas de langage statiquement typé qui est loin d'être aussi populaire que les grands noms commerciaux. Pourquoi les environnements open-source / programmation sans logiciel presque toujours dynamiquement typés? Cela pourrait indiquer qu'une statiquement typé est en fait pas si facile à faire, et que le typage dynamique est un « hack de l'homme paresseux ». Si tel est le cas, les entreprises qui décident de langues contre dynamiquement typées pourraient en fait avoir un point.

Answer 5

• typé langues Dynamiquement ont tendance à être plus lent que leurs cousins ??typés statiquement.
• Les erreurs sont plus difficiles à attraper et peuvent être plus difficiles à déboguer
• Le compilateur / interpréteur a tendance à être beaucoup moins pointilleux sur ce que vous pouvez et ne pouvez pas faire. à savoir, vous attrapez à peu près que des erreurs de syntaxe à l'étape de compilation
• Si vous n'êtes pas très prudent avec la conception d'un langage typé dynamiquement, vous vous retrouvez avec Javascript, qui est la langue des odeurs de code

EDIT: Je dois mentionner que mon langage de programmation principal en ce moment est Python, qui est typé dynamiquement. Personnellement, j'aime la liberté qui vient avec ne pas avoir à pré-déclarer des variables, mais parfois, il me être agréable à préciser (par exemple) quel type de paramètres fonction prend à des erreurs de capture au début plutôt que tard.

Answer 6

Les langages typés dynamiquement sont perçus (par certains programmeurs / patrons) au code produit qui ne fonctionne pas aussi bien. Le fait qu'un programme compile dynamiquement typé vous dit très peu de choses sur son exactitude. Le fait qu'une compilation langage typé statiquement vous dit beaucoup plus. (Par contre, il y a encore un long chemin entre Compile et fait la bonne chose, alors cela pourrait être moins significative alors il semble)

Les langages typés dynamiquement sont perçus comme les langages de script. Vous écririez jamais une application dans bash ou un fichier de commandes. Toutes les langues dynamiquement tapées ont tendance à être intégrable dans cette catégorie (injustement).

Les langages typés dynamiquement sont plus lents puis langues statiquement typés. (Mais nous verrons à quel point le travail sur les changements JIT qui)

Answer 7

Note: Ceci est la plupart du temps subjectif et basé sur mes expériences et impressions

.

Les langages typés dynamiquement sont très différentes des langues statiquement typés. Ces différences probablement devenir plus important dans les logiciels d'entreprise lourd que dans la plupart des autres applications.

statiquement typé langues ont tendance à être très prescriptive. Une méthode ne prendra entrée qui correspond exactement à sa signature. Les niveaux d'accès ont tendance à être très important et les interfaces sont définies explicitement, avec bavard, mais des restrictions sans ambiguïté en place pour appliquer ces définitions.

typé langues Dynamiquement d'autre part sont très pragmatiques. Les conversions de type se produisent souvent implicitement, les fonctions peuvent même jouer le long si vous fournissez le mauvais type d'entrée tant qu'elle se comporte suffisamment similaires. Dans les langues comme Python, les niveaux d'accès même seront basés sur un contrat plutôt que des restrictions techniques (à savoir qu'il est seulement private parce que vous avez dit de ne pas l'utiliser et il a un drôle de nom).

De nombreux programmeurs préfèrent les langages dynamiques parce qu'ils (sans doute) permettent le prototypage rapide. Le code se termine souvent plus courte (si seulement en raison de l'absence de déclarations de type) et si vous voulez violer le protocole approprié parce que vous avez besoin d'une solution ou si vous voulez rapide et sale à quelque chose de test, qui est facilement possible.

Maintenant, la raison pour que les entreprises « de enterprisey » préfèrent souvent des langages typés est exactement statiquement qu'ils sont plus restrictives et plus explicite au sujet de ces restrictions. Bien que dans la pratique même du code statiquement typé peut être rompu par des idiots avec un compilateur, de nombreux problèmes seront beaucoup plus visibles beaucoup plus tôt dans le processus (à savoir avant l'exécution). Cela signifie que même si le code de base est grande, monolithique et complexe, de nombreuses erreurs peuvent être pris facilement, sans avoir à exécuter le code ou l'envoyer au département d'assurance qualité.

La raison de cette prestation ne l'emporte pas sur les inconvénients pour beaucoup de programmeurs en dehors de cet environnement est que ce sont des erreurs qui souvent être facilement repéré par une inspection approfondie du code ou même en essayant de l'exécuter. Surtout lorsque l'on suit une méthodologie axée sur les tests, ces erreurs deviennent souvent trivial pour attraper et facile à fixer. En outre, avec beaucoup de ces entreprises ayant un cycle de libération beaucoup plus courte, la productivité est souvent plus importante que la rigidité et beaucoup (de base) Le test est effectué par les développeurs eux-mêmes.

L'autre raison que les sociétés de enterprisey n'est le code existant ne pas utiliser beaucoup Les langages typés dynamiquement. Aussi idiot que cela puisse paraître nous nerds, les grandes entreprises vont souvent tenir à des solutions qui fonctionnent, même si elles sont bien au-delà de leur durée de conservation. Voilà pourquoi tant de grandes entreprises appliquent Internet Explorer 6 et sont si lents à mettre à niveau leurs systèmes d'exploitation. Ceci est également la raison pour laquelle ils souvent écrire un nouveau code dans les langues « anciens » (par exemple des anciennes versions de Java): il est beaucoup plus facile d'ajouter quelques lignes de code à une pièce de Unliving de logiciels que d'obtenir l'approbation d'une réécriture complète dans une nouvelle langue.

tl; dr. langues statiques se sentent plus comme la bureaucratie, afin que les gestionnaires de enterprisey comme les mieux

Answer 8

Non, je ne pense pas que les langues dynamiquement tapées méritent toutes les critiques. (Ou si vous préférez, ils méritent autant la critique que les langues statiquement typés.)

Dans mon expérience (et je fais aucune tentative d'essayer de généraliser cette déclaration), les programmeurs qui critiquent les langages dynamiques ont pas utilisés. La conversation va généralement « mais avec le typage statique des prises de compilateur tant d'erreurs! » et je dis « bien, qui est tout simplement pas un problème, dans mon expérience ». (En général, de l'autre d'un programmeur Java, Delphi ou arrière-plan similaire;. Je ne sais pas de programmeurs Haskell ou ML)

La seule chose qui m'a vraiment Gripes est quand quelqu'un prétend que la technique Foo ne peuvent pas peut faire (ou peut-être très difficile à faire) dans un langage typé dynamiquement ... quand cette technique a été inventé en, par et pour un langage typé dynamiquement. IDEs? Smalltalk. refactoring automatique? Smalltalk. Les appelants-de /? De-implementors Smalltalk.

Answer 9

Les entreprises sont tout simplement pas adopter de nouvelles langues et des outils assez rapidement et il y a de bonnes raisons pour cela. Mais, quand l'un des outils traditionnels tels que C # mettre en œuvre certaines de ces caractéristiques, alors ils se filet dans les entreprises traditionnelles ....