Le problème des implémentations alternatives (Alternative Implementation Problem)

Le problème des implémentations alternatives

L’auteur explique le problème récurrent des implémentations alternatives dans le monde du logiciel. Son expérience concerne principalement l’optimisation des langages de programmation à typage dynamique.

• Le projet PyPy a développé un compilateur JIT avancé pour Python, mais il est en pratique très peu utilisé. Comme Python continue d’ajouter de nouvelles fonctionnalités et d’évoluer, il était difficile pour PyPy de suivre le rythme.
• LuaJIT est très apprécié, mais comme le langage Lua continue lui aussi d’ajouter de nouvelles fonctionnalités, LuaJIT se retrouve avec plusieurs versions de retard.
• Le JIT de TruffleRuby affichait les performances les plus impressionnantes, mais son manque de compatibilité fonctionnelle par rapport à CRuby a limité son déploiement.

Leçon : les implémentations alternatives sont un choix voué à l’échec

• Lorsqu’on crée une implémentation alternative, on devient inévitablement dépendant des évolutions de l’implémentation officielle.
• L’implémentation officielle contrôle l’orientation du projet, et l’implémentation alternative ne peut que suivre.
• Traditionnellement, lorsqu’on construit une implémentation JIT d’un langage interprété, il est bien plus rapide d’ajouter de nouvelles fonctionnalités à l’interpréteur, si bien que l’implémentation officielle peut prendre de l’avance sur le JIT.

YJIT : implémenter un compilateur JIT Ruby à l’intérieur de CRuby

• YJIT est un autre JIT pour Ruby, mais il a choisi d’être implémenté directement à l’intérieur même de CRuby.
• Cela a permis à YJIT d’être compatible à 100 % avec toutes les fonctionnalités de CRuby dès le départ.
• C’est désormais le JIT officiel de Ruby, déployé chez Shopify, Discourse, GitHub et ailleurs.

Une leçon valable à plus grande échelle

• Le langage Crystal, similaire aux langages existants mais non compatible avec eux, n’a lui aussi connu qu’un succès limité.
• Ce qui ressemble à un langage existant sans être compatible avec lui ne fait que semer la confusion.
• Lorsqu’on crée un nouveau langage de programmation, mieux vaut ne pas chercher à devenir un sous-ensemble d’un langage existant et suivre sa propre voie.
• Cela permet d’évoluer à son propre rythme et dans sa propre direction, sans être limité par les performances, les fonctionnalités ou les bibliothèques d’une autre implémentation.

L’avis de GN⁺

• Le « problème des implémentations alternatives » décrit dans cet article est un point d’attention non seulement pour les langages de programmation, mais aussi pour la conception de toutes sortes de systèmes logiciels et matériels.
• À trop se concentrer sur la stabilité et la compatibilité, il peut devenir difficile d’innover. Mais du point de vue des utilisateurs réels, la compatibilité reste un élément très important. Il est essentiel de trouver un équilibre entre nouvelles technologies et convivialité.
• Dans une perspective de long terme, tout nouveau projet doit réfléchir sérieusement à la question de savoir « avec quoi est-il compatible ? » et « dans quelle direction va-t-il évoluer ? ».
• Lorsqu’on crée un nouveau langage de programmation, se contenter de reprendre une syntaxe proche d’un langage existant ne fait qu’ajouter de la confusion. Il vaut mieux affirmer clairement sa propre philosophie et sa propre direction.
• Plus que la compétition sur le marché, proposer des solutions créatives et originales semble offrir de meilleures chances de succès à long terme.

[GN⁺]

Avis Hacker News

• Lorsqu’on développe une nouvelle implémentation alternative avec une architecture différente de la version existante, ce qui est facile dans l’ancienne version peut devenir très difficile dans la nouvelle. Par exemple, si un logiciel proprietary charge/sauvegarde par section alors que la nouvelle version charge l’ensemble du document en mémoire, il peut être nécessaire de modifier toute l’architecture de la nouvelle version pour prendre en charge l’ajout de pièces jointes.
• Se positionner comme une alternative à une implémentation existante est une proposition perdante. Les projets commercialisés comme « Python + X » ont du mal à rivaliser avec la version officielle. En revanche, si, comme MicroPython, ils sont conçus pour les microcontrollers et ne concurrencent pas CPython mais d’autres environnements de programmation pour microcontrollers, ils peuvent réussir.
• Malgré les promesses de compatibilité, la compatibilité réelle est souvent faible, même pour d’anciennes fonctionnalités du langage, ce qui contribue à l’échec des implémentations alternatives. Pour Ruby et Python, l’absence de prise en charge des extensions C natives en est un exemple.
• D’après une expérience de création de startup, au lieu de viser les fonctionnalités de base, il aurait fallu montrer que l’architecture pouvait prendre en charge des fonctionnalités d’entreprise et se concentrer sur un élément vraiment différenciant.
• Les développeurs accordent plus d’importance aux fonctionnalités du langage et à l’interopérabilité qu’au JIT. Il est plus facile de créer son propre projet parallèle que de contribuer à un projet existant, mais il faut se demander à qui cela sert. Il faut éviter de tomber dans l’autosatisfaction.
• Le code wrapper s’écarte du standard et souffre d’une documentation insuffisante, ce qui crée des difficultés. Il vaut mieux n’ajouter que les fonctionnalités strictement nécessaires et utiliser les valeurs par défaut.
• C’est similaire aux problèmes rencontrés par TiDB à cause de la compatibilité MySQL. En théorie, c’est un protocole ouvert, mais en pratique, c’est Chrome qui mène la danse.
• Il n’y avait aucune mention de Kotlin.