Comment certaines communautés linguistiques (par exemple, Ruby et Python) ont-elles pu empêcher la fragmentation alors que d'autres (par exemple, Lisp ou ML) ne l'ont pas été?

Le terme "Lisp" (ou "Lisp-like") est un parapluie pour beaucoup de langues différentes, telles que Common Lisp, Scheme et Arc. La fragmentation est similaire dans les autres communautés linguistiques, comme dans ML.

Cependant, Ruby et Python ont tous les deux réussi à éviter ce destin, où l’innovation était davantage liée à la mise en œuvre (comme PyPy ou YARV) au lieu d’apporter des modifications au langage lui-même.

Les communautés Ruby et Python ont-elles fait quelque chose de spécial pour empêcher la fragmentation du langage?

Ruby et Python ont à leur tête des dictateurs bienveillants . Ce sont des langues profondément enracinées dans des préoccupations pragmatiques. Ce sont probablement les facteurs les plus importants inhibant la fragmentation. Lisp et ML, en revanche, ressemblent davantage à des langages de "conception par comité", conçus dans les universités, à des fins théoriques.

Lisp a été conçu à l'origine par John McCarthy comme une notation mathématique pratique pour les programmes informatiques. Il ne l'a jamais implémenté en tant que langage de programmation réel; La première mise en œuvre a été développée par Steve Russell , mais il n'était pas un dictateur bienveillant. Au fil du temps, de nombreuses implémentations différentes de Lisp sont apparues; Common Lisp était une tentative de normalisation.

Lisp est plutôt une "famille" de langues. Il en va de même pour ML, qui a suivi un chemin d'évolution similaire à celui de Lisp.

Un facteur probable est simplement l'âge. Lisp et ML sont beaucoup plus âgés que Python et Ruby:

• Lisp: 1958

• ML: 1973

• Python: 1991

• Rubis: 1995

Lisp et ML ont évidemment constaté des changements beaucoup plus importants dans les capacités matérielles, davantage de tendances en informatique, et beaucoup plus d'étudiants au doctorat à la recherche d'un travail sur lequel travailler.

Ils sont essentiellement tous les langages définis par la mise en œuvre

Lorsqu'il est facile de créer une nouvelle implémentation d'un langage largement compatible avec le code existant, les pirates étant des pirates, ils le font. Tout le monde écrit une implémentation Lisp à un moment donné. Les compilateurs ML sont presque obligatoires pour les étudiants diplômés en conception linguistique - la langue est après tout bien connue .

D'autre part, nous avons les langages ad hoc et définis par l'implémentation. Ou des langues tellement complexes qu’il s’agit d’un obstacle important à la production d’une mise en œuvre alternative viable:

• rubis; perl; python - trop défini par l'implémentation pour produire des alternatives viables
• ghc haskell et erlang - bien définis, mais il est si difficile de faire tout ce qui est en concurrence avec ghc (ou erlang) que les gens ne se dérangent généralement pas

Cet inconvénient apparent - des langages trop difficiles à produire, offre un avantage considérable: les ressources de développement rares se concentrent sur la seule implémentation.

En tant que note historique, plusieurs membres de la communauté Haskell ont activement cherché à fusionner et à concentrer leurs efforts de développement, reconnaissant que toute scission de la communauté de développeurs signifierait que nous ne réussirions pas. GHC a été choisi et défendu.

Je dirais qu'un facteur est une plate-forme déterminante . Pour Haskell, la plate-forme est la norme Haskell et le GHC (j'imagine). Pour Ruby, c'est Ruby on Rails qui a "défini" la plate-forme de développement Ruby. Pour C c'était Unix.

Comparez cela à Lisp, où il n'y avait pas de plate-forme kick-ass originale définissant la langue. Si je me souviens bien, chaque machine Lisp présentait de légères différences selon le modèle et le fabricant. Common Lisp était pour une raison quelconque ne pas définir. Peut-être à cause d'une concurrence excessive et de la réticence à changer de plate-forme.

Ceci est, bien sûr, entièrement spéculation de mon côté. Cette pensée venait du commentaire qui répondait à la réponse de Harvey. Cependant, il semble que la plate-forme de définition se présente sous de nombreuses formes, mais la propriété commune semble être que c'est ce qui gagne en popularité.

N'oubliez pas de peser la culture qui motive le développement d'une langue

Je tiens également à souligner le fait que le développement sur python / php se fait activement en public. Vous avez un groupe d'individus en train de définir une spécification standard qui est librement disponible pour tout le monde.

Tout comme le W3C le fait avec le standard HTML / CSS. Vous avez un petit groupe de personnes motivées qui contrôlent les détails les plus fins de ce que le langage est conçu pour accomplir. Tout va dans une spécification clairement définie avant sa publication au public.

OTOH, des langues comme LISP sont abordées à huis clos par des professeurs ou d’autres personnes qui croient sincèrement que leur point de vue sur le «meilleur usage» de la langue est juste. Ils peuvent être simultanément bons et mauvais en même temps, car certaines implémentations sont excellentes à certains égards; alors que aucun n'est le meilleur de tout.

Ce n'est pas forcément une mauvaise chose car la diversité engendre l'innovation. Les langues telles que LISP sont et resteront d'excellentes langues pour l'apprentissage et la recherche, car elles repoussent les limites de la compréhension.

Mais les qualités qui rendent un environnement propice à l’innovation ne sont pas nécessairement bénéfiques pour la stabilité; Inversement, les qualités qui rendent un environnement propice à la stabilité ne le sont pas nécessairement pour la créativité.

Lorsque le développement est basé sur une collaboration active, les individus sont parfois obligés de concéder au profit du plus grand tout. Mauvais pour la recherche / bon pour la cohérence.

Le fait est que nous vivons toujours dans l'extrême ouest du développement du langage de programmation. La difficulté de concevoir le «langage idéal» est telle que, malgré des efforts monumentaux, personne n’est parvenu à le résoudre.

Dans le secteur de la recherche et des universités, il reste encore beaucoup à faire pour améliorer et innover. Dans le secteur commercial, les logiciels utilisés dans des applications pratiques connaissent une croissance exponentielle et la force motrice est la simplicité et la cohérence.

Certaines langues se spécialisent dans les premières, certaines se spécialisent dans les dernières. Ceux qui essaient de se spécialiser dans les deux domaines ne réussissent généralement pas très bien et meurent.

Par les deux, je me réfère à des langages monolithiques tels que VB / C # / Java. Il est trop tôt pour le dire, mais j'aimerais voir à quoi ressemblent C # et Python dans 10 ans. Au rythme actuel, C # augmente la fonctionnalité et les incohérences à un rythme qui le rend plutôt sombre. Même avec une excellente documentation, il est trop pénible de se rappeler tous les détails subtils et les bizarreries incluses dans le langage. C'est formidable pour un seul développeur, mais dès que vous ajoutez plus de développeurs avec des styles uniques, l'incohérence dans la base de code grandit, la qualité en souffre et personne ne gagne. Je pense que nous avons beaucoup à apprendre des difficultés que présente Perl dans un environnement de production.

Je ne pense pas qu'il soit correct de dire que des langages comme Python et Ruby ne sont pas fragmentés. Nous commençons déjà à constater des effets de fragmentation. Par exemple, Python 3 n'est pas entièrement rétrocompatible avec Python 2; il est donc nécessaire de conserver les deux versions et de nombreux codes existants ne fonctionnent qu'avec Python 2. Il existe également quelques retombées de Python, dont PyPy.

Un autre facteur est l'âge des langues. Les plus exposés à la fragmentation sont les anciens langages et sont donc soumis aux pressions de l'évolution et de la révision. Lisp a été inventé il y a plusieurs décennies, il a donc eu amplement le temps de reprendre certaines de ses idées et de les incorporer dans de nouvelles langues. C est un autre exemple de langage fragmenté. Alors que C n’avait qu’une révision très importante du langage lui-même (K & R à ANSI), de nombreuses retombées ont eu lieu, notamment C ++, Not Quite C et tous les autres qui partagent une syntaxe semblable à celle du C.

Ruby lui-même est une "fragmentation" (si vous voulez) des langues précédentes. Puisqu'il incorpore des idées de C, Smalltalk et Perl (entre autres), c'est actuellement le langage qui fragmente. Je ne vois pas pourquoi on ne verrait peut-être plus de convolution ultérieure de Ruby avec d'autres langues.

Lisp est fragmenté parce que c'est un modèle tellement puissant, le langage le plus étonnant jamais conçu. De nos jours, la plupart des langues empruntent des choses qui avaient été implémentées pour la première fois en Lisp. Vous pouvez donc dire que chaque langue fait partie de cette fragmentation particulière. Smalltalk était par exemple fortement inspiré de Lisp et Ruby fortement inspiré de Smalltalk. JavaScript est Lisp dans un déguisement Java, et ainsi de suite. Tout est connecté, et chaque inventeur de langage sélectionne ses morceaux préférés dans d'autres langues.

Un autre facteur est que Lisp est probablement le concept de programmation le plus simple à mettre en œuvre - c’est pourquoi il est répété à maintes reprises.

Les langages de type Lisp sont trop basiques et théoriques pour être modifiés de façon spectaculaire. Les changements grammaticaux (je ne veux pas simplement changer les noms des commandes) ne cadreraient tout simplement pas avec la théorie de la programmation fonctionnelle qui les sous-tend.

Mais le fait qu'il existe des langages comme lisp montre que des "modifications" ont déjà été apportées à lisp de toute façon. En d'autres termes, il y a des langages créés par des personnes qui se sont inspirés du lisp ou de sa théorie pour créer un nouveau langage similaire.

Il y a aussi beaucoup de langages inspirés par Python. Julia, CoffeeScript, etc., qui formeraient leur propre famille de langages orientés objet sensibles aux espaces.

Je pense que les bases d'un langage comme Python ne changeront jamais vraiment. Python est orienté objet et présente donc des similitudes avec C ++ et Java, mais il est dynamique et par conséquent similaire à de nombreux langages de script.

Bien qui se soucie réellement des langues? Ce qui compte, c’est le but: le français est semblable au latin, mais les filles qui comprennent le français sont beaucoup plus chaudes;)