La tragédie du Common Lisp: pourquoi les langues populaires gonflent en complexité

Adapté de la discussion de 2015 . Ici, Common Lisp n'est qu'un des nombreux bons exemples.


L'avenir de JavaScript?

Je travaille sur le comité des normes JavaScript (TC39) depuis 2007. Nous apprécions la simplicité de la langue, mais avec le temps, nous avons perdu la vigilance. La complexité a commencé à croître de façon incontrôlable. Nous devons savoir pourquoi cela se produit naturellement, quel est le prix et que faire à ce sujet. Cet article s'adresse non seulement aux collègues du TC39, mais également à tous ceux qui souhaitent influencer le chemin de développement de JavaScript ou de toute norme qui a subi une pression similaire. Apprenez de nos erreurs!

Algol, Smalltalk, Pascal et Early Scheme étaient aimés comme de petites et belles langues. Les premiers C et JavaScript ont été à juste titre critiqués pour beaucoup et rarement appelés beaux. Mais ils étaient aussi petits et c'était très apprécié. Lorsque la langue est petite, notre appréciation est souvent déterminée par le sentiment: «Je peux tout apprendre et le maîtriser» , puis: «Je sais tout. J'aime qu'il ne reste aucun détail inconnu . » Mais dans le cas de C et de JavaScript, il est peu probable que quiconque ait un sens de la maîtrise totale du langage, car les détails étaient en fait diaboliquement complexes. Néanmoins, le sentiment d'une «petite langue» à bien des égards a déterminé la satisfaction de l'usage quotidien.

L'esthétique du minimalisme JavaScript a été préservée dans la norme EcmaScript-5. J'ai participé activement au développement d' EcmaScript-5 et d'EcmaScript-2015, et dans les deux cas, je suis fier de ma contribution. EcmaScript-2015 a considérablement augmenté en taille, mais a apporté des améliorations. Étant donné où nous avons commencé, il était impossible d'améliorer JavaScript sans une telle augmentation de taille. Je ne regrette pas la plupart des modules complémentaires qui ont conduit à gonfler EcmaScript-5 en EcmaScript-2015. Si vous revenez en arrière, probablement dans de nombreux cas, je suggérerais des ajouts similaires.

Chacun des ajouts a dû surmonter une barre très élevée. Psychologiquement, cela avait du sens, car nous avons examiné le minimalisme EcmaScript-5. Lorsque la langue est petite, chaque fonction supplémentaire est intuitivement ressentie comme une augmentation significative en pourcentage de la taille de la langue. Les avantages spécifiques d'une fonctionnalité sont toujours visibles pour ses partisans. Pour une petite langue, la contribution de la nouvelle fonctionnalité à l'augmentation du total est également toujours visible par tout le monde.

Dès qu'un langage dépasse une certaine complexité - disons, LaTeX, Common Lisp, C ++, PL / 1, Java moderne - la programmation devient plus comme découper un sous-ensemble de fonctions à usage personnel dans une mer infinie de fonctions, dont la plupart ne seront jamais maîtrisées et réconciliées avec ça. Une fois que le langage est perçu comme «infini», les avantages spécifiques de la nouvelle fonctionnalité sont toujours compris. Mais les coûts globaux associés à une complexité supplémentaire ne sont plus évidents. Ils ne sont plus ressentis par ceux qui discutent d'une nouvelle fonctionnalité.

$$ .

Même $$ .

C'est la mort de mille coupures, ce qui fait grandir ces monstres sans aucune restriction.

Par conséquent, je demande à tous ceux qui influencent la langue de considérer une barre plus élevée lorsqu’ils envisagent une nouvelle fonction que «c’est bien d’avoir une telle opportunité, n’est-ce pas? Je crois que EcmaScript-2015 est situé sur le territoire frontalier où une croissance effrénée peut encore être empêchée, mais seulement si nous commençons à nous restreindre avec des normes élevées pour toute nouvelle fonctionnalité proposée. En tant que communauté, nous avons besoin d'un sentiment de panique plus général face à la taille déjà atteinte par EcmaScript 2015. Idéalement, avec la croissance de la langue, lorsque la taille approche du point de non-retour, la panique devrait augmenter et non diminuer.

Quelques différences

Gardez une pression minimale inégale

La pertinence du minimalisme diminue à mesure que nous passons d'une langue de base à des bibliothèques. Le langage standard dans son ensemble peut être représenté comme la structure suivante:

• Syntaxe fondamentale : formes spéciales qui ne peuvent pas être exprimées avec précision par extension locale à une autre syntaxe.
  
• État sémantique : état manipulé par le calcul.
  
• Built-in du noyau : partie de la bibliothèque intégrée qui fournit des fonctionnalités que le code personnalisé ne peut pas fournir par lui-même.
  
• Intrinsèques non-noyau: bibliothèques intégrées pouvant être implémentées en JavaScript, mais l'état sémantique ou les modules intégrés dans le noyau en dépendent. Par exemple, via un proxy, vous pouvez implémenter un tableau dans le code utilisateur. Mais d'autres modules intégrés au noyau ont déjà une dépendance à l'égard de Array, ce qui donne à ce tableau particulier une position privilégiée sur tout remplacement proposé.
  
• Sucre syntaxique : syntaxe qui peut être exprimée par extension locale à la syntaxe fondamentale.
  
• Bibliothèques globales pour plus de commodité : peuvent être implémentées avec du code utilisateur non privilégié, mais en tenant compte des chemins de nommage globaux standard dans l'espace de noms global d'origine.
  
• Modules standard pour plus de commodité : modules développés par la communauté approuvés en standard.

Je les ai classés dans l'ordre, conformément à mon sentiment d'augmentation des coûts de croissance et au besoin urgent de minimalisme. Tout cela requiert de la discipline. Ce n'est que sur le dernier point que nous pouvons permettre une croissance illimitée, mais il est conseillé que les candidats soient testés par la communauté et acceptés de facto en premier. Idéalement, le comité TC39 cessera d'être un goulot d'étranglement, car les processus externes de facto et de jure pourront développer indépendamment des modules standard pour plus de commodité.