Existe-t-il un mécanisme pour rendre le langage de programmation plus stable (compatible) pour les changements?

Il existe un grand nombre de langages de programmation. Certains d'entre eux grandissent et deviennent très populaires. Les gens utilisent de plus en plus ces langues. Le fondateur d'une telle langue (ou organisation / communauté fondatrice) peut essayer de mettre en œuvre des changements pour améliorer la langue. Mais parfois, il est difficile d'apporter des modifications en raison de la compatibilité descendante et de telles choses laides existent déjà dans la langue depuis des années et sont utilisées par de nombreux utilisateurs.

Y a-t-il des principes ou des étapes architecturales, pendant la phase de conception du langage, qui peuvent aider à le rendre plus stable afin que les concepteurs de langage n'aient pas aussi peur de briser la compatibilité descendante?

La stabilité linguistique n'est pas une décision technique. Il s'agit d'un contrat entre l'auteur de la langue et les utilisateurs.

L'auteur annonce une version donnée comme plus ou moins stable. Moins une langue est stable, plus l'auteur peut apporter de changements. Chaque utilisateur intéressé par la langue peut décider s'il veut y investir du temps pour apprendre de nouvelles fonctionnalités ou développer des applications qui pourraient être cassées par la mise à jour du mois prochain.

L'utilisation d'un langage instable peut être intéressante parce que vous êtes intéressé par un nouveau concept ou que vous souhaitez aider en donnant votre avis. Si vous êtes une entreprise, vous préférerez peut-être attendre qu'une technologie soit plus stable avant d'y investir votre temps. Vous vous souciez plus de choses comme le délai de commercialisation et l'expérience utilisateur.

Il s'agit donc d'un problème de communication et de confiance. Regardez le développement du langage de la rouille. Ils savent parfaitement ce qu'ils changent et ce qu'ils gardent. Lorsqu'ils veulent retarder une décision concernant une fonctionnalité donnée, ils utilisent ce qu'ils appellent une porte de fonctionnalité. De l'autre côté, l'équipe angulaire a fait face à beaucoup de colère à propos de son annonce 2.0 parce que les changements étaient plus importants que prévu.

Même les auteurs de bibliothèques doivent communiquer sur la stabilité de leurs API. Presque toutes les technologies utilisées par d'autres personnes doivent trouver un équilibre entre stabilité et perfection. Un constructeur automobile ne peut pas changer la position des pédales et un concepteur d'ordinateur portable n'inventera pas une nouvelle disposition de clavier pour la même raison: vous n'aidez pas vos utilisateurs si vous ne pouvez pas décider de la façon dont ils utiliseront votre produit.

• Soyez conscient que les langues changent tout au long de leur vie, quelle que soit la façon dont elles peuvent être conçues à l'avance. Au lieu d'essayer d'expédier immédiatement la langue la plus impressionnante sur terre, essayez d'abord d'être utile et extensible. Une langue médiocre que je peux réellement utiliser vaut plus que n'importe quel merveilleux langage de programmation qui n'existe qu'en théorie.

• Considérez les facilités pour rendre la syntaxe extensible, par exemple les macros. Les macros ne sont pas automatiquement une bonne chose et peuvent être trop puissantes. Certaines langues ont une syntaxe très flexible dès le départ, ce qui réduit le besoin de macros. Quelques scénarios à considérer:

  • Puis-je introduire un nouvel opérateur tel que |> sans quitter la langue? Puis-je choisir la priorité et l'associativité pour cet opérateur?
  • Combien de cérémonie dois-je passer pour une fonction en ligne / lambda / fermeture?
  • Puis-je utiliser la syntaxe de langage existante pour implémenter une syntaxe de boucle foreach? Par exemple, Ruby et Scala peuvent le faire grâce à leur syntaxe d'appel de méthode flexible avec lambdas.

• Considérez les installations pour garder la sémantique extensible. Les besoins communs sont:

  • Surcharge d'opérateur, où les types définis par l'utilisateur peuvent attribuer leur propre signification aux opérateurs existants. Cela rend un langage beaucoup plus agréable dans les applications mathématiques.
  • Surcharge littérale. Puis-je faire en sorte que les littéraux de chaîne soient de mon propre type de chaîne? Puis-je faire de tous les littéraux numériques de la portée actuelle des bignums?
  • Protocoles de métaobjet. Si le langage n'a pas de traits, puis-je les implémenter dans le système d'objet actuel? Puis-je implémenter un ordre de résolution de méthode différent? Puis-je échanger la façon dont les objets sont stockés ou comment les méthodes sont distribuées?
• Faites des tests de régression. Beaucoup de test. Non seulement écrit par les concepteurs de langage, mais aussi par les utilisateurs. Lorsque l'ajout d'une fonctionnalité rompt ces tests, pesez soigneusement les avantages de cette fonctionnalité par rapport à l'avantage de la compatibilité descendante.
• Version de votre langue. Pas seulement dans votre documentation, mais aussi dans le code source lui-même. Une fois que vous avez fait cela, la seule partie de votre langue qui ne peut pas changer est cette syntaxe de pragma de version. Exemples: La raquette vous permet de spécifier un dialecte. Perl vous le permet use v5.20, ce qui active toutes les fonctionnalités incompatibles avec Perl v5.20. Vous pouvez également charger explicitement des fonctionnalités uniques comme use feature 'state'. Similaire: Python from __future__ import division.
• Pensez à concevoir votre langue d'une manière qui se traduit par quelques mots réservés. Tout simplement parce que classintroduit une classe n'implique pas que je ne serais pas en mesure d'avoir une variable locale nommée class. En pratique, cela se traduit par des mots-clés qui introduisent des déclarations de variable ou de méthode, contrairement à la tradition de type C consistant à utiliser des noms de type pour introduire des déclarations. Une autre alternative est d'utiliser des sigils pour vous $variables, comme en Perl et PHP.

Certaines parties de cette réponse sont influencées par le discours de Guy Steele «Growing a Language» (1998) ( pdf ) ( youtube ).

Je pense qu'une étape assez importante est de promouvoir un gestionnaire de paquets qui peut également gérer la version du langage lui-même.

Par exemple, j'utilise SBT pour Scala ou Leiningen pour Clojure. Les deux me permettent de déclarer la version de la langue que je veux utiliser, par projet . Il est donc assez facile de démarrer des projets verts dans la dernière version de la langue, tout en améliorant les projets existants à un rythme plus confortable, si jamais.

Bien sûr, selon la langue, cela peut toujours vous laisser le besoin d'attendre que les bibliothèques pertinentes soient portées vers la version dont vous avez besoin (cela se produit, par exemple, dans Scala), mais cela facilite quand même les choses.