Qu'est-ce que les gens trouvent de si attirant dans les langages dynamiques ?

Question

Il semble que tout le monde saute dans le train de la dynamique non compilée ces derniers temps. J'ai surtout travaillé dans des langages compilés et typés statiques (C, Java, .Net). L'expérience que j'ai des langages dynamiques concerne des choses comme ASP (Vb script), JavaScript et PHP. L'utilisation de ces technologies m'a laissé un mauvais goût dans la bouche lorsque je pense aux langages dynamiques. Les choses qui auraient normalement été détectées par le compilateur, comme les noms de variables mal orthographiés et l'affectation d'une valeur du mauvais type à une variable, ne se produisent pas avant l'exécution. Et même dans ce cas, il se peut que vous ne remarquiez pas l'erreur, car le programme crée simplement une nouvelle variable et lui attribue une valeur par défaut. Je n'ai jamais vu non plus intellisense fonctionner correctement dans un langage dynamique, puisque, eh bien, les variables n'ont pas de type explicite.

Ce que je veux savoir, c'est ce que les gens trouvent de si attrayant dans les langages dynamiques. Quels sont les principaux avantages en termes de choses que les langages dynamiques permettent de faire et qui ne peuvent pas être faites, ou qui sont difficiles à faire dans les langages compilés. Il me semble que nous avons décidé, il y a longtemps, que des choses comme les pages asp non compilées lançant des exceptions d'exécution étaient une mauvaise idée. Pourquoi y a-t-il une résurgence de ce type de code ? Et pourquoi me semble-t-il, du moins à moi, que Ruby on Rails ne ressemble pas vraiment à quelque chose que vous n'auriez pas pu faire avec ASP il y a 10 ans ?

Answer 1

Je pense que la raison en est que les gens sont habitués à des langages typés statiquement qui ont des systèmes de types très limités et inexpressifs. Il s'agit de langages comme Java, C++, Pascal, etc. Au lieu d'aller dans la direction de systèmes de types plus expressifs et d'une meilleure inférence de types (comme en Haskell, par exemple, et même SQL dans une certaine mesure), certaines personnes préfèrent garder toutes les informations de "type" dans leur tête (et dans leurs tests) et se passer complètement de la vérification statique des types.

Ce que cela vous rapporte au final n'est pas clair. Il existe de nombreuses idées fausses sur le contrôle de la frappe, mais celles que je rencontre le plus souvent sont les deux suivantes.

C'est une erreur : Les langages dynamiques sont moins verbeux. L'idée fausse est que l'information sur le type est égale à l'annotation du type. C'est totalement faux. Nous savons tous que l'annotation de type est ennuyeuse. La machine devrait être capable de comprendre ce genre de choses. Et en fait, elle le fait dans les compilateurs modernes. Voici un QuickSort typage statique en deux lignes de Haskell (de haskell.org ) :

qsort []     = []
qsort (x:xs) = qsort (filter (< x) xs) ++ [x] ++ qsort (filter (>= x) xs)

Et voici un QuickSort typographié dynamiquement en LISP (à partir de swisspig.net ) :

(defun quicksort (lis) (if (null lis) nil
  (let* ((x (car lis)) (r (cdr lis)) (fn (lambda (a) (< a x))))
    (append (quicksort (remove-if-not fn r)) (list x)
      (quicksort (remove-if fn r))))))

L'exemple Haskell falsifie l'hypothèse typée statiquement, donc verbeuse . L'exemple LISP falsifie l'hypothèse verbeux, donc typés statiquement . Il n'y a aucune implication dans un sens ou dans l'autre entre le typage et la verbosité. Vous pouvez sans crainte vous débarrasser de cette idée.

Erreur : les langages à typage statique doivent être compilés, et non interprétés. Encore une fois, c'est faux. De nombreux langages typés statiquement ont des interprètes. Il y a l'interpréteur Scala, les interpréteurs GHCi et Hugs pour Haskell, et bien sûr SQL a été à la fois statiquement typé et interprété depuis que je suis en vie.

Vous savez, peut-être que la foule dynamique veut juste la liberté de ne pas avoir à réfléchir aussi soigneusement à ce qu'elle fait. Le logiciel peut ne pas être correct ou robuste, mais peut-être qu'il n'a pas à l'être.

Personnellement, je pense que ceux qui sont prêts à renoncer à la sécurité de type pour acheter un peu de liberté temporaire, ne méritent ni la liberté ni la sécurité de type.

Answer 2

N'oubliez pas que vous devez écrire une couverture de code 10x dans les tests unitaires pour remplacer ce que fait votre compilateur :D

J'ai été là, j'ai fait ça avec des langages dynamiques, et je n'y vois absolument aucun avantage.

Answer 3

En lisant les réponses d'autres personnes, il semble qu'il y ait plus ou moins trois arguments en faveur des langues dynamiques :

1) Le code est moins verbeux. Je ne trouve pas cela valable. Certains langages dynamiques sont moins verbeux que certains langages statiques. Mais F# est typée statiquement, mais le typage statique n'ajoute pas beaucoup, voire pas du tout, de code. Il est cependant implicitement typé, mais c'est une chose différente.

2) "Mon langage dynamique préféré X possède ma fonctionnalité fonctionnelle préférée Y, donc le dynamique est meilleur". Ne pas confondre fonctionnel et dynamique (je ne comprends pas pourquoi il faut le dire).

3) Dans les langues dynamiques, vous pouvez voir vos résultats immédiatement. Nouvelles : Vous pouvez également le faire avec C# dans Visual Studio (depuis 2005). Il suffit de définir un point d'arrêt, d'exécuter le programme dans le débogueur et de modifier le programme pendant le débogage. Je fais cela tout le temps et cela fonctionne parfaitement.

Pour ma part, je suis un fervent défenseur du typage statique, pour une raison essentielle : la maintenabilité. J'ai un système qui contient quelques 10 000 lignes de JavaScript, et je n'ai pas pu le maintenir. tout Le remaniement que je veux faire prendra une demi-journée car le compilateur (inexistant) ne me dira pas ce que ce renommage de variable a fait de mal. Et c'est du code que j'ai écrit moi-même, IMO bien structuré, aussi. Je ne voudrais pas être chargé d'un système dynamique équivalent que quelqu'un d'autre aurait écrit.

Je suppose que je vais être massivement descendu pour cela, mais je prends le risque.

Answer 4

VBScript est nul, à moins que vous ne le compariez à un autre type de VB. PHP est acceptable, tant que vous gardez à l'esprit qu'il s'agit d'un langage de création de modèles envahissant. Le Javascript moderne est génial. Vraiment. C'est très amusant. Restez juste loin de tout scripts étiqueté "DHTML".

Je n'ai jamais utilisé un langage qui ne permettait pas les erreurs d'exécution. À mon avis, c'est en grande partie un faux-fuyant : les compilateurs ne détectent pas toutes les erreurs de frappe et ne valident pas non plus l'intention. Le typage explicite est excellent lorsque vous avez besoin de types explicites, mais la plupart du temps, vous n'en avez pas besoin. Cherchez les questions ici sur generics ou la question de savoir si l'utilisation de types non signés était un bon choix pour les variables d'index - la plupart du temps, ce genre de choses ne fait que gêner les gens et leur donner des boutons à tourner quand ils ont du temps libre.

Mais, je n'ai pas vraiment répondu à votre question. Pourquoi les langages dynamiques sont-ils attrayants ? Parce qu'au bout d'un moment, écrire du code devient ennuyeux et vous voulez juste implémenter l'algorithme. Vous vous êtes déjà assis et avez tout élaboré au stylo, vous avez schématisé les scénarios de problèmes potentiels et prouvé qu'ils étaient résolubles, et la seule chose qui reste à faire est de coder les vingt lignes de l'implémentation... et les deux cents lignes du boilerplate pour le faire compiler. Vous réalisez alors que le système de types avec lequel vous travaillez ne reflète pas ce que vous faites réellement, mais l'idée ultra-abstraite que quelqu'un d'autre a de ce que vous faites. pourrait et vous avez depuis longtemps abandonné la programmation pour une vie de bricolage si obsessionnelle qu'elle ferait honte même au détective de fiction Adrian Monk.

C'est à ce moment-là que vous allez vous faire plâtrer commencer à s'intéresser sérieusement aux langages dynamiques.

Answer 5

Je suis un programmeur .Net à plein temps, entièrement plongé dans les affres du C# à typage statique. Cependant, j'adore le JavaScript moderne.

D'une manière générale, je pense que les langages dynamiques vous permettent d'exprimer votre intention plus succinctement que les langages à typage statique, car vous passez moins de temps et d'espace à définir les éléments constitutifs de ce que vous essayez d'exprimer, alors que dans de nombreux cas, ils sont évidents.

Je pense qu'il existe également plusieurs classes de langages dynamiques. Je n'ai aucune envie de revenir à l'écriture de pages ASP classiques en VBScript. Pour être utile, je pense qu'un langage dynamique doit prendre en charge une sorte de collection, de liste ou de construction associative à sa base afin que les objets (ou ce qui passe pour des objets) puissent être exprimés et vous permettre de construire des constructions plus complexes. (Peut-être que nous devrions tous coder en LISP ... c'est une blague ...)

Je pense que dans les cercles .Net, les langages dynamiques ont mauvaise réputation parce qu'ils sont associés à VBScript et/ou JavaScript. VBScript est juste un rappel comme un cauchemar pour beaucoup des raisons que Kibbee a indiqué - quelqu'un se souvient de l'application du type dans VBScript en utilisant CLng pour s'assurer que vous avez assez de bits pour un entier de 32 bits. De plus, je pense que JavaScript est toujours considéré comme le langage du navigateur pour les menus déroulants qui sont écrits d'une manière différente pour tous les navigateurs. Dans ce cas, le problème n'est pas le langage, mais les différents modèles d'objets des navigateurs. Ce qui est intéressant, c'est que plus C# mûrit, plus il commence à être dynamique. J'adore les expressions Lambda, les objets anonymes et l'inférence de type. Il ressemble de plus en plus à JavaScript.