La programmation orientée langage est-elle pratique?

J'ai lu cet article sur la programmation orientée langage. Il souligne certaines faiblesses des approches procédurales / POO modernes de la programmation et suggère un nouveau paradigme de programmation qui les résoudra.

Je suis tout pour les petites parties de programme à couplage lâche: il vaut beaucoup mieux apprendre beaucoup de petites choses, que vous utiliserez toutes, que quelques grandes choses, que vous n'utilisez que des morceaux.

En lisant l'article, j'ai eu l'impression que l'auteur faisait la promotion de deux choses:

• Une multitude de langages de script faciles à créer
• Un langage unique et facilement extensible qui peut se réécrire pour répondre aux besoins du programmeur

S'il propose le second, je répondrais par "Déjà fait!" et donnez Lisp comme exemple. Comme le suggère Paul Graham, les langues semblent de toute façon évoluer dans ce sens .

En ce qui concerne le premier, je pense que c'est une bonne idée, s'il existe un langage sous-jacent qui les relie tous ensemble. Cela me semble être le point faible: la communication entre les langues. Souhaitez-vous utiliser des appels, qui est un concept procédural ou un passage de message, qui me rappelle la communication interprocessus? Je serais ravi d'avoir l'opportunité de travailler avec des langues spécifiques à un petit domaine, s'il est facile de les utiliser toutes en même temps. Cette approche (LOP) serait-elle pratique?

Je préconise les DSL depuis longtemps, mais je m'inquiète de ce qui arrive aux bonnes idées lorsqu'elles deviennent des fourgons. Des produits sont construits qui font la publicité de The Good Idea, promettant que tout ce que vous avez à faire est d'en obtenir un , et vous serez dans le groupe, sans avoir à réfléchir très attentivement à ce que cela signifie.

Qu'est-ce qu'une langue? C'est un vocabulaire et une syntaxe dans lesquels les significations peuvent être communiquées, non? Chaque fois que vous déclarez une variable, écrivez une fonction, définissez une classe, vous construisez un nouveau langage, en ajoutant des noms et des verbes à un langage existant. Vous pouvez maintenant y dire des choses que vous ne pouviez pas auparavant.

Je pense que ce qui rend un langage spécifique au domaine, c'est la mesure dans laquelle il exprime naturellement les concepts mentaux qui sont communiqués, et je pense qu'il existe une mesure simple de cela. Fondamentalement, s'il existe une simple exigence autonome indépendante X, qui pourrait être incluse ou non dans le programme, sa mise en œuvre correcte nécessite un ensemble d'insertions, de suppressions et de remplacements de code Y. Un simple avant-après diff peut afficher Y. Le nombre N de ces modifications est une mesure de la spécificité du domaine de la langue. Le plus petit N est, pour les besoins typiques, meilleur.

Cela ne dépend pas nécessairement de la syntaxe sophistiquée, des structures de contrôle, de la transmission des messages ou de ce que vous avez. Cela dépend de la concision avec laquelle il met en œuvre l'exigence. De nombreux outils prétendent le faire, mais les affirmations ne sont pas réelles. Cela doit être réel .

Parfois, une technologie inhabituelle est nécessaire. Voici mon exemple préféré. Quand il l'est, il illustre le fait qu'il peut nécessiter des efforts de la part des programmeurs pour le comprendre. La spécificité du domaine (et la maintenabilité) n'est donc pas du tout la même chose que la lisibilité .

Je suis donc d'accord avec la deuxième approche, qu'une bonne langue est celle qui permet facilement de construire les langues nécessaires par-dessus. (C'est ce que j'ai aimé à propos de Lisp.) Mais ce qui est encore plus important, c'est que les programmeurs doivent savoir comment créer des langues pour correspondre aux domaines dans lesquels ils travaillent et être prêts à gravir les courbes d'apprentissage de ces langues.

Je ne vois pas vraiment cela se produire. Au lieu de cela, ils sont coincés dans les "programmes = algorithmes + structure de données", ou "les noms deviennent des classes et les verbes deviennent des méthodes". Ils ne travaillent pas sur la façon de prendre des domaines de pensée et de les linguiser pour une concision maximale.

C'est tout à fait l'approche Ruby.

• Gardez le langage de base simple et étendez-le via des gemmes
• Créez des dialectes de Ruby pour des domaines spécifiques via le patch de singe. ig Ruby on Rails.

Je ne sais pas si c'est mieux, mais je suppose que c'est très pragmatique.

L'approche LOP est extrêmement pratique. Gardez à l'esprit que vous n'avez pas nécessairement à implémenter des "langages de script" - la méthodologie est également applicable aux eDSL, et ils sont généralement compilés efficacement. J'utilise cette approche dans littéralement tout mon travail de développement.

Nous en verrons beaucoup plus sur les langages spécifiques à un domaine à l'avenir, à en juger par les gens qui en parlent maintenant - j'ai remarqué que Martin Fowler en parlait beaucoup aussi et quelques articles intéressants sur Lambda The Ultimate sur Lambda The Ultimate , entre autres.

Cela me donne à penser que c'est certainement une direction dans laquelle le vent souffle en ce qui concerne la conception de langages de programmation et les plateformes de programmation. À certains égards, cela fait déjà un certain temps - l'un des avantages de Ruby (comme quelqu'un l'a déjà observé) est qu'il facilite la création de DSL, mais en fait il y en a beaucoup dans les applications et les bibliothèques de programmation que nous utilisons déjà.

J'utilise LOP chaque fois que je programme en solo. J'ai trouvé que dans certains projets, il n'y avait pas d'autre moyen de respecter le calendrier. Dans une allégorie simple, on peut assimiler l'utilisation de la LOP aux outils électriques. Si vous travaillez seul dans l'atelier, vous ne pouvez pas faire les choses manuellement et respecter la date limite. S'il y a d'autres personnes avec vous, la coordination de l'utilisation de ces outils électriques est essentielle pour l'efficacité et la sécurité.
En mode équipe, LOP nécessite une préparation organisationnelle pour éviter une catastrophe de la Tour de Babel.