Différences architecturales entre les langages dynamiques et statiques

22

Existe-t-il des différences architecturales majeures lors de la conception d'applications qui seront construites sur des langages statiques (tels que C # ou Java) et des langages dynamiques (tels que Ruby ou Python)?

Quelles sont les possibilités de conception qui pourraient être un bon choix pour un type qui est mauvais pour l'autre? Y a-t-il des fonctionnalités utiles réalisables avec un type qui n'est pas avec l'autre (dans la conception et l'architecture, bien sûr)?

Existe-t-il également des modèles de conception spécifiques à la dynamique?

Raphael
la source
1
Quelles que soient ces différences architecturales, les langages dynamiques - IronRuby et IronPython - complètent facilement les langages statiques de .Net.
IAbstract
3
Je ne suis pas certain, mais si la métaprogrammation est plus facile dans les langages dynamiques (cela semblait certainement plus facile en Ruby qu'en Java, la dernière fois que j'ai regardé), cela pourrait avoir une influence sur les décisions architecturales. Je ne sais pas quel genre d'influence parce que je n'ai jamais vraiment travaillé sur quelque chose d'aussi gros dans ces langages dynamiques.
FrustratedWithFormsDesigner

Réponses:

14

Mettons les choses au clair:

  1. Les scripts interactifs et les langages statiques ne s'excluent pas mutuellement. F # et Haskell ont tous deux des interfaces REPL.
  2. Les langages dynamiques et les hautes performances ne s'excluent pas mutuellement, bien que certaines optimisations le soient. De nos jours, JavaScript fonctionne plutôt vite sur la plupart des navigateurs.
  3. Même dans les langues dynamiques, vous devez toujours documenter, mémoriser et penser aux types.
  4. En raison de la popularité croissante de l'inférence de type, de nombreux langages statiques n'ont plus à noter les types très souvent. Dans les langages statiques avec une forte inférence de types, le compilateur détermine quels sont les types de votre code afin que la plupart du temps, et vous indique si vous faites quelque chose qui viole les définitions de type. En ce qui concerne la syntaxe, cela offre le meilleur des deux mondes.
  5. La POO et les langages dynamiques ne s'excluent pas mutuellement. PHP prend désormais en charge les classes et même l'héritage.

Toutes ces similitudes surprenantes mises à part, il existe des différences pratiques qui influencent le processus de développement:

  1. Les langages dynamiques permettent des moyens intéressants de transmettre des données dans les petits .
  2. Les langages statiques vous permettent de réduire la quantité de tests que vous devez faire en rendant impossible de nombreux types de bogues.
  3. Dans la même veine, les langages statiques permettent des fonctionnalités de validation et de conversion automatique intéressantes, comme les unités de mesure en F # .
  4. Poussé à l'extrême, les langages statiques permettent des contrats de code et une vérification formelle, qui peuvent documenter et prévenir les choses comme la division par zéros potentielle, les boucles infinies, les références nulles, les tailles de liste ou les index invalides, les erreurs de plage et d'autres états logiquement invalides que vous pourriez définir.
  5. En allant encore plus loin, des optimisations du processeur peuvent être effectuées sur la base de ces contraintes statiques, ce qui donne des performances encore meilleures.

Il existe également un type de programme qui n'aurait jamais pu être créé sans typage statique: la singularité , un système d'exploitation sans limites de processus matériel. Il est écrit dans une petite quantité de C, du C # et un dialecte de C # appelé Spec #, qui prend en charge les contrats de code.

Bien qu'ils soient écrits dans un langage récupéré, les performances de communication multitâche et interprocessus sur ce système d'exploitation sont en fait meilleures que toute autre chose, en raison du fait que tous les processus s'exécutent dans un espace mémoire et en raison des optimisations de vérification formelles I mentionné ci-dessus. Vous ne pouvez pas le faire sans taper statique, car pour que les programmes ne puissent pas compromettre le reste du système, les objets de communication doivent être statiquement vérifiables.

Cependant, la plupart du temps, les architectures devraient se ressembler. Les langages statiques peuvent rendre les programmes plus faciles à raisonner dans de nombreux cas parce que les types sont bien définis, mais un programme de langage dynamique bien écrit aurait également des types qui sont, à tout le moins, bien définis dans l'esprit des développeurs.

Rei Miyasaka
la source
Singularity peut-il offrir une garantie de latence maximale en temps réel?
Eonil
@Eonil Ce n'est pas vraiment mon domaine, mais je pense que vous demandez si cela peut être difficile en temps réel. Je ne pense pas, car il utilise la collecte des ordures partout. Pour autant que je sache, la singularité n'a pas été mise à jour depuis un certain temps, mais peut-être que quelqu'un a créé quelque chose de similaire avec un garbage collector en temps réel.
Rei Miyasaka
Merci. Je voulais juste vérifier. J'ai entendu dire qu'il y avait des implémentations GC en temps réel, mais je n'ai pas entendu comment elles étaient utilisées pratiquement dans l'industrie…
Eonil
2

Il existe une différence architecturale importante. Performance.

Selon votre budget matériel, la charge de travail attendue et les accords de niveau de service, il peut ne pas être possible de répondre aux exigences avec un langage dynamique.

Le plus souvent, la vitesse de développement et la flexibilité fournies par les langages dynamiques compensent les temps de réponse plus lents et la consommation de mémoire plus élevée. Mais pour les systèmes plus grands avec des contraintes de budget ou de performances, les frais généraux d'un langage dynamique peuvent être élevés.

James Anderson
la source
1

Je n'ai jamais pensé dans ce sens. Alors, quand a fait un Google, le blog de Peter Norvig a été l'un des meilleurs hits. Il indique que certains modèles de conception sont plus faciles à implémenter dans les langages dynamiques que les langages orientés objet traditionnels tels que C ++. Je pense qu'il devrait également y avoir des différences de conception / architecture, car il note que la mise en œuvre est plus facile dans les langages dynamiques. J'essaierai d'ajouter plus à la réponse au fur et à mesure de mes études.

vpit3833
la source
1

Existe-t-il des différences architecturales majeures lors de la conception d'applications qui seront construites sur des langages statiques (tels que C # ou Java) et des langages dynamiques (tels que Ruby ou Python)?

Non.

Il est légèrement plus facile d'écrire des frameworks sophistiqués pour les langages dynamiques. Mais ce n'est pas une chose d'application.

Quelles sont les possibilités de conception qui pourraient être un bon choix pour un type qui est mauvais pour l'autre?

Aucun, vraiment.

Vous pouvez écrire de bonnes choses dans les deux langues.

Y a-t-il des fonctionnalités utiles réalisables avec un type qui n'est pas avec l'autre (dans la conception et l'architecture, bien sûr)?

Non.

La différence est que les langages dynamiques sont "écrire, exécuter, corriger". Vous pouvez expérimenter et réparer rapidement.

Les langages statiques sont "écrire, compiler, construire, exécuter, corriger". Vous ne pouvez pas expérimenter aussi facilement.

En dehors de cela, ils sont presque identiques dans leurs capacités.

Existe-t-il des modèles de conception spécifiques à la dynamique?

Peut être. Le Python eval()et les execfile()fonctions - en quelque sorte - indiquent une fonctionnalité de langage dynamique qui est difficile (mais loin d'être impossible) à gérer dans un langage statique. Il faudrait beaucoup plus de lignes de code pour compiler et exécuter du code dans le même espace de processus.

Ce n'est pas spécifique au langage dynamique. C'est juste plus simple.

S.Lott
la source
2
"Vous ne pouvez pas expérimenter aussi facilement." - Vrai, le compromis étant que le compilateur vous aide à trouver des erreurs alors qu'avec les langages interprétés, vous ne pouvez pas trouver d'erreur tant qu'un utilisateur n'exécute pas cette ligne de code.
Doug T.
4
@Doug T .: "le compilateur vous aide à trouver les erreurs". Parfois. Pas assez souvent. Les erreurs intéressantes ne peuvent pas du tout être trouvées par un compilateur. C'est à cela que servent les tests unitaires.
S.Lott
2
@ S.Lott Je trouve que les API écrites dans des langages dynamiques nécessitent un peu plus de documentation. Dans un langage statique, la signature de la méthode vous indique quels types d'arguments sont requis. Dans un langage dynamique, vous ne pouvez pas le dire aussi facilement - la documentation de l'API doit vous dire quels objets sont attendus.
quanticle
1
@quanticle: Ce n'est pas vraiment architectural, n'est-ce pas?
S.Lott
2
"Vous ne pouvez pas expérimenter aussi facilement." - F # et Haskell sont tous les deux des langages statiques, et ils ont des REPL à part entière, et vous demandent rarement un identifiant ou un type d'expression.
Rei Miyasaka