Pourquoi la plupart d'entre nous n'inventerons pas de petites langues

samedi 20 novembre 2004

Pourquoi la plupart d'entre nous n'inventerons pas de petits langages

Sergey Dmitriev (PDG de JetBrains) a récemment écrit un article affirmant qu'il devrait être plus facile d'écrire des programmes informatiques dans des langages spécifiques à un domaine. J'ai un grand respect pour les développeurs d'IntelliJ IDEA et j'ai hâte de voir de nouveaux outils de leur part, mais je pense que sa justification pour écrire ces nouveaux outils ne tient pas vraiment la route.

Sergey semble croire que le principal obstacle à l'invention de nouveaux langages informatiques est qu'il est trop difficile d'écrire des outils spécifiques à un langage. Bien que ce soit un argument naturel pour un fournisseur d'outils, je pense qu'il manque quelque chose de fondamental à propos du langage. Le véritable inconvénient d'inventer un nouveau langage n'est pas que vous devez écrire de nouveaux éditeurs, compilateurs et de nombreux autres outils. C'est que les autres ne vous comprendront pas.

Si vous écrivez un article technique dans une langue naturelle telle que l'anglais, vous pouvez facilement inventer de nouveaux termes techniques - votre traitement de texte s'en moque. Mais si vous êtes le seul à utiliser ces termes, votre écriture sera obscure et difficile à lire. Toute personne intéressée à lire vos articles devra d'abord apprendre votre jargon. Vous avez de bien meilleures chances de succès si vous écrivez clairement avec le moins de jargon possible. Ou du moins, utilisez le jargon populaire dans la communauté à laquelle vous appartenez, si vous n'essayez pas d'avoir une plus grande influence.

Nous inventons constamment de nouveaux termes, parfois pour de bonnes raisons. Mais cela doit se faire lentement car la communauté a besoin de temps pour les apprendre, ou les rejeter, selon le cas. De nombreux articles populaires s'intéressent à l'introduction d'un seul nouveau concept, comme le récent article de Wired populisant l'expression "la longue traîne" - ou la tentative de Sergy de populariser la "programmation orientée langage".

Les langages informatiques fonctionnent de manière similaire ; une langue devient plus utile quand plus de gens la comprennent. Peu importe l'expressivité d'un langage et la qualité de ses compilateurs, si votre bibliothèque nécessite l'apprentissage d'un nouveau langage, peu l'utiliseront, et encore moins seront capables de le maintenir. La difficulté d'écrire de bons IDE spécifiques à un langage renforce cette tendance, mais elle existait à l'époque où nous utilisions tous emacs et vi.

Il est tout à fait possible que des langages comme Lisp ne soient pas devenus populaires (au-delà d'une petite communauté) en partie parce qu'ils encouragent les programmeurs à écrire des langages spécifiques à un domaine. Cela a tendance à fragmenter la communauté en groupes qui ont du mal à communiquer (effet "tour de Babel"). C'est aussi auto-renforçant - un langage sans beaucoup de bibliothèques attire les gens qui sont prédisposés à réinventer la roue en premier lieu, de sorte que le corps du code commun activement utilisé se développe très lentement. Beaucoup plus de code est partagé en Java, mais il y a encore beaucoup d'impasses évolutives - nous n'avons pas besoin de plus de raisons pour décourager le partage.

En outre, Surgey semble penser que les constructions de base que nous utilisons pour la programmation orientée objet (classes et méthodes) sont une limitation à surmonter. Bien qu'ils puissent parfois l'être, ils constituent également une force, comme tout autre standard de communication largement utilisé. Il est courant que les applications Java utilisent des dizaines de bibliothèques développées séparément. Ce n'est pas quelque chose à prendre pour acquis, et l'une des raisons pour lesquelles cela fonctionne est que, quel que soit le domaine, en bas, il s'agit de tous les appels de méthode Java. Si chacune de ces bibliothèques était écrite dans son propre petit langage, comment les intégrerions-nous ? Les API doivent avoir quelque chose en commun et il y a peu de fonctionnalités de Java qui n'ont rien à voir avec une API.

Je trouve donc quelque peu étrange que Sergey pense que les limitations de la programmation orientée objet rendent les bibliothèques plus difficiles à apprendre. Apprendre à utiliser correctement l'API Swing peut être difficile, mais serait-il vraiment plus facile si les développeurs Swing inventaient un nouveau langage pour l'écrire ? Lorsque vous apprenez quelque chose de nouveau, il est très utile de pouvoir compter sur ce que vous savez déjà ; rendre les choses moins familières ne semble pas être une grande amélioration.

Je ne veux certainement pas dire que les outils que JetBrains écrira pour la programmation orientée langage seront inutiles. Mais ils pourraient être utilisés différemment de ce que Surgey imagine. Les développeurs Web maintiennent déjà des programmes qui intègrent de nombreux petits langages, notamment XML, HTML, JavaScript, les expressions régulières, xpath et SQL. Sur la base de cette expérience, je m'attends à ce que la population de petites langues augmente lentement, et la plupart des équipes n'inventeront pas la leur. Le cas le plus courant pour les développeurs d'IDE sera d'écrire des plugins pour de petits langages déjà existants, et non de fournir des outils aux inventeurs de langages.