Différences architecturales entre les langages dynamiques et statiques

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?

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.

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.

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.

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.