Les langages statiques et typés dynamiquement peuvent-ils être considérés comme des outils différents pour différents types de travaux?

9

Oui, des questions similaires ont été posées mais toujours dans le but de découvrir «laquelle est la meilleure».

Je pose la question parce que je suis devenu développeur principalement en JavaScript et que je n'ai pas vraiment d'expérience dans l'écriture dans des langages typés statiquement.

Malgré cela, je vois vraiment de la valeur dans l'apprentissage de C pour gérer des opérations exigeantes à des niveaux de code inférieurs (ce qui, je suppose, a beaucoup à voir avec statique vs dynamique au niveau du compilateur), mais ce que j'essaie de comprendre est de savoir s'il existe des contextes de projet spécifiques (peut-être certains types d'opérations dynamiques à forte intensité de données?) impliquant des choses autres que les performances où il est beaucoup plus logique d'utiliser Java ou C # par rapport à quelque chose comme Python.

dynamic-typing static-typing

— Erik Reppen
source

5

La réponse est oui". Chaque type de langue - en fait chaque langue - a ses forces et ses faiblesses et convient donc mieux à certaines tâches qu'à d'autres.

— ChrisF

il est intéressant que vous utilisiez C comme exemple, car c'est en quelque sorte le langage le plus faiblement typé que vous puissiez imaginer et vous l'appelez toujours statiquement typé. C n'est pas rapide à cause du système de type, les vérifications de type ont lieu au moment de la compilation. C est rapide car il y a peu ou pas de mesures de sécurité et de contrôles pour vous empêcher de vous tirer une balle dans le pied. et parce qu'il compile en binaires natifs.

— sara

10

Oui définitivement.
La frappe dynamique présente des avantages certains dans les cas où vous souhaitez pouvoir tout traiter comme un seul type. La sérialisation / désérialisation est l'un des exemples classiques. C'est pourquoi tant de programmation Web se fait dans des langages de script à typage dynamique: ils sont bien adaptés à une tâche qui implique beaucoup de conversion de toutes sortes de données vers et depuis des chaînes.

Pour la programmation d'applications, en revanche, les langages statiques fonctionnent beaucoup mieux car essayer de tout traiter comme un seul type n'est pas souvent une exigence. Vous voulez souvent avoir des structures de données efficaces avec des données représentées comme elles-mêmes et ne pas être converties très fréquemment en d'autres types. Cela rend les fonctionnalités de la frappe dynamique un inconvénient plutôt qu'un avantage, c'est pourquoi les applications sont presque exclusivement écrites dans des langages typés statiquement.

— Mason Wheeler
source

3

@Erik: Je ne suis même pas sûr de l'avoir dit. Les choses changent pendant le développement. Les exigences peuvent changer ou vous constatez que vous n'implémentez pas correctement une exigence et que le code doit être mis à jour. Pouvoir changer une chose et utiliser les erreurs de compilation qui en résultent pour vous montrer où trouver tout ce qui doit être changé fournit un énorme coup de pouce à la commodité et à la vitesse de développement que vous perdez dans les langues où cette technique n'est pas disponible. C'est l'une des raisons pour lesquelles vous ne voyez tout simplement pas d'applications complexes développées dans des langages dynamiques.

— Mason Wheeler

9

@Mason Wheeler: Très bonne réponse. + 1 J'ajouterais que la vérification de type statique aide également à trouver les bogues plus tôt en demandant au compilateur de vérifier l'exactitude du type. Par exemple, j'ai débogué un programme Ruby de 200 lignes hier et il y avait deux bogues liés au type que je ne pouvais détecter qu'en exécutant le programme. Je ne veux pas penser à ce qui se passe dans un projet de 100 000 lignes. Le typage dynamique vous donne donc plus de flexibilité, ce qui est bien dans les contextes que vous avez décrits, au prix que vous ne pouvez pas trouver certains bogues au moment de la compilation. Le typage statique n'est donc pas seulement lié à l'efficacité, mais aussi à l'exactitude.

— Giorgio

1

@MasonWheeler Deux ans et beaucoup plus de C # et de Java que je ne le pensais plus tard, je serais maintenant en désaccord avec quelques points. Les applications Web complexes sont entièrement réalisées avec des langages dynamiques. La compilation par rapport à l'exécution n'a aucun sens lorsque vous pouvez apporter des modifications immédiatement visibles. Et j'ai développé l'opinion que tous les types d'agitation ont beaucoup plus de sens dans un langage procédural que dans un langage censé être piloté par la POO où les données ne devraient pas changer constamment de mains en premier lieu.

— Erik Reppen

1

@Erik: * wince * Tout d'abord, juger la frappe statique comme un concept par Java, c'est comme juger les voitures comme un concept par le Pinto. Et deuxièmement, tout ce qui peut être "visible immédiatement" n'est pas, par définition, un programme très complexe, car même avec du matériel moderne, les programmes complexes prennent beaucoup de temps pour préparer le code, qu'il s'agisse d'un compilateur ou d'un interprète ( ou un compilateur JIT) faisant la préparation. Même les applications Web les plus impressionnantes ont tendance à être des programmes très simples soutenus par des bases de données très complexes, ce qui est tout autre chose.

— Mason Wheeler

1

La capacité de faire des abstractions complexes est orthogonale à un système de type statique vs dynamique, et également orthogonale à la vitesse. Il existe des systèmes de type statique qui permettent des abstractions incroyablement puissantes (bien que parfois obscures). Avoir des modifications qui apparaissent instantanément est également indépendant du système de type: vous pouvez certainement créer des interprètes pour les langues typées statiquement.

— Rufflewind

4

La façon dont je le vois est, si vous pouvez travailler naturellement dans une langue typée statiquement, alors la frappe statique est la voie à suivre. En général, le but d'un système de type est de vous empêcher d'effectuer des opérations avec une sémantique non définie - comme (string) "hello" + (bool) true. Avoir le niveau de sécurité supplémentaire vous empêchant d'effectuer ces opérations peut être un bon moyen d'éviter les bogues dans votre code, même sans tests unitaires approfondis. Autrement dit, la sécurité de type fournit un autre niveau de confiance dans l'exactitude sémantique de votre code.

Mais les systèmes de type sont très difficiles à obtenir correctement. Je ne crois pas qu'il existe un système de type parfait dans la nature au moment de la rédaction de cet article. (Par «système de type parfait», j'entends un système de type strict, qui ne nécessite pas d'annotations de code détaillé, qui ne génère aucune erreur de type faux positif et dont les erreurs de type sont faciles à comprendre pour le programmeur.) De plus, il peut difficile de comprendre les très bons systèmes de types qui existent. Lorsque j'apprenais Haskell, je ne peux pas vous dire le nombre d'erreurs de type obscur que j'ai eues en essayant d'écrire ce qui me semblait (comme) du code correct. Habituellement, le code n'était pas réellement correct (ce qui est un point en faveur du système de type), mais cela a pris beaucoup de tempsde travail pour comprendre les messages d'erreur du compilateur, afin que je puisse corriger les problèmes sous-jacents. Dans les langues OO, vous pouvez éventuellement vous surprenez à penser « cet argument devrait être contravariante avec le type d'entrée, pas covariant! », Ou (plus probablement) de revenir à typecasts pour échapper aux limites du système de type. Les systèmes de saisie peuvent devenir beaucoup plus délicats que vous ne le pensez.

Pour ce que ça vaut, je comprends que la difficulté de trouver de bons systèmes de type fait partie de ce qui a motivé Gilad Bracha à inclure le support du système de type enfichable dans Newspeak.

— Aidan Cully
source

Tests unitaires WRT, je suis entièrement d'accord. Vous voyez toujours des gens dire "si vous avez de bons tests unitaires, ils peuvent vérifier l'exactitude du type pour vous." Cela m'a toujours rappelé comment Paul Graham (qui croit fermement que la frappe dynamique est toujours une bonne chose) dit qu'un langage vous obligeant à faire manuellement le travail du compilateur car c'est un langage imparfait. Sorta vous fait vous arrêter et réfléchir ...

— Mason Wheeler

Je pense que bon nombre des préoccupations concernant les «dangers» des langages typés dynamiquement ne tiennent pas compte de la façon dont nous écrivons ces choses. Une grande partie de Python et JS peut être écrite de style console. Compilation de vis vs exécution, je peux l'essayer dès maintenant et voir ce qui se passe. Je pense cependant que vous êtes sur un très bon point. Rien ne me rend plus fou dans le développement Web côté client que lorsque tous les prétendus bons fournisseurs de navigateurs donnent une passe déroutante sur du code horrible tandis qu'IE6 ou 7 fait l'inattendu, qui est de se débrouiller quand il est censé le faire plutôt que juste, eh bien ... sucer de façon plus typique.

— Erik Reppen

Les types de discordance @ mason-wheeler sont des erreurs trivalentes, et ce n'est pas que les langages dynamiques ne vérifient pas les types, c'est juste au moment de l'exécution. D'après mon expérience, la plupart des langages statiques ont le même niveau de couverture des tests unitaires, ils ne perdent aucun test lorsque le compilateur vérifie les types à l'avance, et les langages dynamiques n'ont pas à ajouter des tests spécifiques pour vérifier les types , le système d'exécution vérifie vos types, si votre test unitaire couvre votre méthode, il les intercepterait.

— jbtule

4

Ce sont des outils différents, mais ce n'est pas par la performance. C'est une question de complexité .

Les langages dynamiques visent généralement une flexibilité maximale, ce qui entraîne un manque de validation et une sorte de garantie. Ensuite, il est très puissant dans les programmes à petite échelle, mais il devient presque impossible de maintenir des programmes à grande échelle (complexité).

Les langages statiques visent généralement une validation maximale. Leur premier objectif est généralement de détecter les erreurs (ou les bugs) le plus tôt possible. De nombreuses garanties sont faites pour la validation. Il est ensuite plus difficile à apprendre et à démarrer, mais à mesure que les programmes augmentent, ils offrent une meilleure validation des programmes à un coût bien moindre (efforts de codage).

Par conséquent, les langages dynamiques conviennent généralement aux petits programmes (je veux dire très petits) tels que les pages Web dynamiques, le navigateur Web DSL (pas pour les applications de navigateur!) Ou les scripts shell. Les langages statiques conviennent mieux aux programmations système ou à tout autre élément.

Les descriptions ci-dessus concernent des langages très purement dynamiques ou statiques. La plupart des langues réelles se situent entre elles et présentent diverses caractéristiques.

Voir ici pour plus de détails: https://softwareengineering.stackexchange.com/a/105417/17428

— Eonil
source

1

"Les langages dynamiques conviennent généralement aux petits programmes (je veux dire très petits)": D'après mon expérience, vous pouvez également utiliser des langages dynamiques pour des applications de taille moyenne (et, bien sûr, il y a des gens qui les utilisent avec succès pour de grandes applications). Je suis d'accord que plus la base de code est grande, plus vous pouvez profiter des contrôles statiques fournis par les langages statiques.

— Giorgio

2

@Giorgio Eh bien, c'est peut-être parce que je suis accro aux trucs de validation statique. C'est si doux pour moi, et je ne peux littéralement pas vivre sans eux, même à petite échelle: p

— Eonil

Je vois les avantages des langages statiques (et j'ai voté pour votre réponse). Récemment, j'utilise Python et Common Lisp et j'avoue qu'en pratique, vous obtenez de bons résultats si vous utilisez une conception propre et, surtout en Python, si vous écrivez suffisamment de tests. Ces langages peuvent être très efficaces pour construire un prototype qui peut ensuite facilement être transformé en votre code de production. Mais, oui, pour les projets plus complexes, j'aimerais avoir autant d'aide que possible, donc je préfère un langage statique.

— Giorgio

1

Je programme actuellement dans des langages de type statique (C # et F #), mais j'apprécie la programmation dans des langages dynamiques (Smalltalk, Ruby). Il y a beaucoup d'avantages et d'inconvénients que les gens associent à un type par rapport à un autre et qui concernent davantage la langue que lorsque vous appliquez des types. Par exemple, les langages dynamiques ont généralement une syntaxe plus propre et plus concise, mais F # et OCaml avec leur système d'inférence de type ont une syntaxe aussi propre que n'importe quel langage dynamique. Et avec la frappe statique, vous avez de véritables refactorings automatiques et la saisie semi-automatique, mais Smalltalk, avec tout son code source dans une base de données et chaque méthode compilée séparément, a été la première langue à avoir vraiment de sérieux refactorings automatisés, et cela a très bien fonctionné. En fin de compte, les langages dynamiques et statiques modernes d'aujourd'hui sont sûrs pour les types, qui est l'aspect le plus important de votre système de type

— jbtule
source

J'ai parfois soupçonné que le typage statique n'est qu'une petite partie de l'équation de ce qui rend un langage plus ou moins flexible. Je pense que ce que je commence également à réaliser, c'est que beaucoup de développeurs préfèrent un ensemble de rails confortable pour les guider plutôt que d'avoir la liberté de faire des choses ridiculement dangereuses comme la surcharge des opérateurs. VS me donne parfois envie de donner des coups de pied à des chiots, mais j'ai certainement été curieux à propos de F # et ce que vous en avez dit me rend encore plus curieux. Je suppose que c'est quelque chose de plus que la seule chose C # où vous pouvez implicitement convertir en un type plus inclusif.

— Erik Reppen

@erik, Oh oui plus que de taper implicitement et var: F # Type inference

— jbtule

-1

C'est 2015 maintenant, qui ajoute quelques extraits intéressants à la conversation:

Des parties importantes du monde du backend d' entreprise envisagent ou commencent à utiliser Python (dynamique) au lieu de Java (statique strict)
Le monde du frontend d' entreprise voit des choses comme AngularJS v2, basé sur TypeScipt: une extension typée de Javascript.

Ainsi, les gars du backend sont fatigués de la veste droite inutile de la frappe stricte, tandis que les gars du frontend sont fatigués du chaos de la frappe dynamique.

Assez ironique: je me demande s'ils vont se rencontrer au milieu, ou se précipiter les uns les autres avec le boom sonore d'un délai qui passe ...? ;)

— Cornel Masson
source

À moins que vous ne fournissiez la moindre preuve, je dirais que dans le pire des cas, le monde du back-end est en transition vers Go, mais dieu interdit tout ce qui est scripty dynamique. Le mythe selon lequel un langage de programmation statique a toujours beaucoup de cérémonie a longtemps été démystifié avec des systèmes d'inférence plus puissants et des implémentations REPL solides

— Den

Il y a beaucoup de back-ends typés dynamiquement utilisés à grande échelle. Django en particulier est très populaire dans le journalisme et dirige les backends du NYT, du Guardian et du Washington Post. Walmart fonctionne sur Node. Le seul mythe est l'idée que vous ne pouvez pas écrire pour l'échelle sans types statiques. Et après avoir réfléchi à quelques désastres de base de code Java que j'ai rencontrés, je pense que les gens qui sont à l'aise de le faire sont mieux lotis, qu'ils travaillent avec de la statique ou de la dynamique.

— Erik Reppen

En effet, je préfère avoir une équipe Python qualifiée sur mon projet de grande entreprise, au lieu d'un pauvre Java.Juste pour clarifier ma position: j'ai posté la réponse ci-dessus comme une évaluation de

— Cornel Masson

En effet, je préfère avoir une équipe Python qualifiée sur mon projet de grande entreprise, plutôt qu'une pauvre Java. Juste pour clarifier: j'ai posté la réponse ci-dessus comme une observation sur les tendances que je vois dans ma clientèle, mon réseau industriel et mes recherches générales. Le backend traditionnellement strict embrasse moins de rigueur, le frontend traditionnellement plus lâche, plus. Ce n'est même pas une opinion sur ce qui est "juste" (le cas échéant) - je ne sais pas pourquoi j'ai été rétrogradé. Peut-être que l'ironie est perdue ...

— Cornel Masson