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 "semblable à LISP") est un parapluie pour de nombreuses langues différentes, telles que LISP commun, Schéma et Arc. Il existe une fragmentation similaire dans d'autres communautés linguistiques, comme en ML.
Cependant, Ruby et Python ont tous deux réussi à éviter ce sort, où l'innovation s'est produite davantage sur l'implémentation (comme PyPy ou YARV) au lieu d'apporter des modifications à la la langue elle-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 tous deux dictateurs bienveillants à leur tête. Ce sont des langues profondément enracinées Ce sont probablement les facteurs les plus importants qui inhibent la fragmentation. LISP et ML, en revanche, ressemblent davantage à des langages de "conception par comité", conçus dans le monde universitaire, à des fins théoriques.
LISP a été initialement conçu par John McCarthy comme une notation mathématique pratique pour les programmes informatiques. Il ne l'a jamais implémenté comme un véritable langage de programmation; la première implémentation 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; LISP commun était une tentative de les standardiser.
LISP est plus une "famille" de langues. Il en va de même pour ML, qui a suivi une voie évolutive similaire à LISP.
Un facteur probable est simplement l'âge. LISP et ML sont beaucoup plus anciens que Python et Ruby:
LISP: 1958
ML: 1973
Python: 1991
Rubis: 1995
Le LISP et le ML ont évidemment vu des changements beaucoup plus importants dans les capacités matérielles, plus de tendances en informatique et un plus grand nombre de doctorants à la recherche de quelque chose sur lequel travailler.
Ce sont essentiellement tous les langages définis par l'implémentation
Lorsqu'il est facile de créer une nouvelle implémentation d'un langage qui est largement compatible avec le code existant, alors les pirates étant des pirates, ils vont de l'avant et 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 de langue - la langue est après tout célèbre bien documentée .
D'autre part, nous avons les langages ad hoc et définis par l'implémentation. Ou des langages qui sont juste si complexes que c'est un obstacle important à la production d'une alternative 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 si difficiles à faire quoi que ce soit qui soit en concurrence avec ghc (ou erlang) que les gens ne dérangent généralement pas
Cet inconvénient apparent - les langues qui sont trop difficiles à produire des alternatives viables ont un avantage massif : les ressources rares des développeurs sont concentrées sur la seule véritable implémentation.
Comme note historique, plusieurs membres de la communauté de Haskell ont activement poursuivi les fusions et la concentration de l'effort de développement, reconnaissant que toute scission de la communauté de développement signifierait que nous ne réussirions pas. GHC a été choisi et défendu.
Je dirais qu'un facteur est ne plate-forme qui définit. Pour Haskell, la plate-forme est la norme Haskell et le GHC (j'imagine). Pour Ruby c'était Ruby sur Rails qui "définissait" le Ruby développement) Pour C, c'était Unix.
Comparez cela à LISP, où il n'y avait pas de plateforme kick-ass originale qui définissait à quoi ressemblait le langage. Si je me souviens bien, chaque machine LISP avait de légères différences selon le modèle et le fabricant. LISP commun n'était pas défini pour une raison quelconque. Peut-être à cause de trop de concurrence et de réticence à passer à une autre plateforme.
C'est, bien sûr, entièrement de la spéculation de mon côté. L'idée est venue des réponses aux commentaires sur la réponse de Harvey. Cependant, il semble que la plate-forme de définition se présente sous plusieurs formes, mais la propriété commune semble être que c'est ce qui gagne en popularité.
N'oubliez pas de peser la culture qui anime le développement d'une langue
Je voudrais également pondérer le fait que le développement sur python/php se fait activement en public. Vous avez un groupe de personnes définissant une spécification standard qui est librement accessible à tout le monde/tout le monde.
Tout comme le W3C le fait avec la norme HTML/CSS. Vous avez un petit groupe de personnes motivées qui contrôlent les moindres détails de ce que la langue est conçue pour accomplir. Tout va dans une spécification clairement définie avant sa publication au public.
OTOH, des langues comme LISP sont bifurquées à huis clos par des professeurs ou d'autres personnes qui croient sincèrement que leur point de vue sur la "meilleure utilisation" de la langue est juste. Ils peuvent être à la fois bons et mauvais en même temps car certaines implémentations sont excellentes à certains égards; alors qu'aucun n'est le meilleur en tout.
Ce n'est pas nécessairement une mauvaise chose car la diversité engendre l'innovation. Des langues comme 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é; à l'inverse, les qualités qui rendent un environnement bon pour la stabilité ne sont pas nécessairement bonnes pour la créativité.
Lorsque le développement est basé sur une collaboration active, les individus sont parfois contraints 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 le Far West du développement du langage de programmation. Le problème de la conception de la "langue idéale" est si grand que, malgré des efforts monumentaux, personne n'a réussi à le résoudre.
Dans le secteur de la recherche/du milieu universitaire, il y a encore beaucoup de place pour l'amélioration et l'innovation. Dans le secteur commercial, où il existe une croissance exponentielle des logiciels utilisés dans les applications pratiques et dont la force motrice est la simplicité et la cohérence.
Certaines langues sont spécialisées dans la première, d'autres dans la seconde. Ceux qui essaient de se spécialiser dans les deux ne réussissent généralement pas très bien et meurent.
Par les deux, je fais référence à des langages monolithiques comme 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 les fonctionnalités et les incohérences à un rythme qui le rend assez sombre. Même avec une excellente documentation, il est trop difficile de se souvenir de tous les détails subtils et des bizarreries inclus dans le langage. C'est génial 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 augmente , la qualité en souffre et personne ne gagne. Je pense qu'il y a beaucoup à apprendre des difficultés que Perl présente dans un environnement de production.
Je ne pense pas qu'il soit correct de dire que les langues comme Python et Ruby ne sont pas fragmentées. Nous commençons déjà à voir des effets de fragmentation. Par exemple, Python 3 n'est pas entièrement rétrocompatible avec Python 2, donc les deux versions doivent être maintenues et beaucoup de code existant ne fonctionne qu'avec Python 2. Il existe également quelques retombées Python, y compris PyPy.
Un autre facteur est l'âge des langues. Les plus sujettes à la fragmentation sont les langues plus anciennes et sont donc soumises à des pressions d'évolution et de révision. LISP a été inventé il y a plusieurs décennies, il y a donc eu suffisamment de temps pour reprendre certaines de ses idées et les intégrer dans de nouvelles langues. C est un autre exemple d'un langage fragmenté. Bien que C n'ait eu qu'une seule révision vraiment majeure du langage lui-même (K&R vers ANSI), il y a eu de nombreuses retombées, y compris C++, Not Quite C et toutes les autres qui partagent une syntaxe de type 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 faisant la fragmentation. Je ne vois pas pourquoi nous ne pourrions pas voir une nouvelle convolution de Ruby avec d'autres langues à l'avenir.
LISP est fragmenté parce que c'est un modèle si puissant, le langage le plus étonnant jamais conçu. La plupart des langues empruntent aujourd'hui des choses qui ont été implémentées pour la première fois dans LISP, donc en quelque sorte, vous pouvez dire que chaque langue fait partie de cette fragmentation particulière. Smalltalk était par exemple fortement inspiré de LISP, et Ruby est fortement inspiré de Smalltalk. JavaScript est LISP sous un déguisement Java, etc.) Tout est connecté, et chaque inventeur de langage sélectionne son pièces préférées d'autres langues.
Un autre facteur est que LISP est probablement le concept de programmation le plus facile à implémenter - c'est pourquoi il est fait encore et encore et encore.
Les langages de type LISP sont trop basiques et théoriques pour être radicalement modifiés. Les changements grammaticaux (je ne veux pas simplement changer le nom des commandes) ne cadreraient tout simplement pas avec la théorie de la programmation fonctionnelle.
Mais le fait qu'il existe des langues 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 gens qui ont été inspirés par LISP ou c'est la théorie derrière cela et ont fait un nouveau langage similaire en quelque sorte.
Il existe également de nombreux langages inspirés de Python. Par exemple. Julia, CoffeeScript, etc. qui formeraient leur propre famille de langages orientés objet sensibles aux espaces.
Je pense que les bases fondamentales d'un langage comme Python ne changeront jamais vraiment. Python est orienté objet et a donc des similitudes avec C++ et Java mais il est dynamique et donc aussi similaire à beaucoup de langages de script.
Eh bien, qui se soucie réellement des langues? Ce qui compte, c'est le but: le français est similaire au latin mais les filles qui comprennent le français sont bien plus chaudes;)