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é?

67

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?

programming-languages language-design

— Chrisaycock
source

10

Vous dites que la fragmentation est une mauvaise chose.

— Sonia

21

@Sonia Du point de vue des parts de marché, la fragmentation est souvent une catastrophe.

— chrisaycock

5

Les langues sont-elles en concurrence les unes avec les autres?

— Barry Brown

32

@ Sonia Cela peut être une mauvaise chose. Par exemple, une bibliothèque écrite pour Python ne dépend presque certainement pas de l'implémentation, alors qu'une bibliothèque écrite pour Lisp peut ne pas fonctionner dans Scheme.

— Kris Harper

2

@Barry Brown: Excellent point! Les langues ne doivent pas être en concurrence sur le marché les unes avec les autres. Mais les vendeurs de langage le sont et cela influence souvent la conception du langage (je ne pense pas que ce soit le cas de Ruby, Python, Lisp, ML, cependant).

— Giorgio

77

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.

— Robert Harvey
source

4

Hmm, je vois vraiment le statut de dictateur parmi les communautés linguistiques homogènes telles que Objective-C (pour les applications iOS) et Ada (pour les contrats du département de la Défense). Dans ces cas, une puissance plus élevée exigeait l'adhésion, ce que les développeurs ont suivi uniquement pour pouvoir vendre leur warez. Mais je n'ai jamais eu à coder en Python (projet amateur) de la même manière que je pourrais être obligé de coder en C # (composant .Net). C'est-à-dire que je pourrais plus facilement fuir Python que, disons, C. Sans cette menace d' utilisation, sinon vous ne ferez pas de ventes , comment un dictateur peut-il garder le troupeau? Cela pourrait être une question distincte cependant.

— chrisaycock

1

Par «dictateur bienveillant», je veux dire que tous les changements de langue doivent passer par une personne ayant la vision de garder la langue pure. Les gens restent avec Python pour des raisons pragmatiques; ils aiment la langue et y sont productifs. Mais tout le monde et son frère ne sont pas autorisés à le fourrer et l'appellent toujours Python.

— Robert Harvey

4

@HenrikHansen Haskell est un standard, comme le mentionne Robert. Donc, le compilateur HUGS doit être compatible avec GHC puisque les deux s'appellent "Haskell". La même protection basée sur des normes s'étend à C et C ++, raison pour laquelle GCC et Visual Studio doivent être compatibles (en supposant que les extensions propriétaires ne soient pas utilisées). La curiosité est ce qui est arrivé à Lisp, où il existe déjà un standard (Common Lisp) et pourtant de nombreux autres Lisps. Le ML a le même problème lorsqu'il existe le ML standard, mais aussi d'autres ML.

— chrisaycock

4

"Common Lisp a été développé pour normaliser les variantes divergentes de Lisp qui le précédaient" - en.wikipedia.org/wiki/Common_Lisp . En d’autres termes, il existait déjà une fragmentation avant l’élaboration de la norme.

— Robert Harvey

3

Je dirais même que ML et Lisp ne sont pas des langages comme Python et Ruby. Lisp et ML ressemblent davantage à des "concepts", mis en oeuvre par plusieurs langages différents.

— BenjaminB

29

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.

— Caleb
source

7

Peut-être, mais je ne me souviens pas de Fortran avoir ce degré de fourche. (Il y avait des choses comme Fortran D, mais la plupart des Fortrans ont été normalisées.) Je suppose que peut-être l'âge de coalescence pourrait être un facteur.

— chrisaycock

2

D'après les informations dont je dispose, Fortran avait beaucoup d'incompatibilités, d'extensions non standard et de mises en œuvre différentes jusqu'à ce que les comités de normalisation le définissent progressivement, probablement parce qu'il était plus répandu que Lisp et ML.

— erjiang

@erjian: FORTRAN a eu ses incompatibilités, car il y avait une incitation sérieuse à: une utilisation professionnelle. Le LISP, utilisé principalement par les universitaires, n'a jamais eu ce luxe. C'est-à-dire que son utilisation n'était pas répandue, mais à quel point ses utilisateurs étaient riches.

— MSalters

2

Ou, alternativement, les variantes ne s'appelaient pas FORTRAN. BASIC, à sa sortie, ressemblait certainement à un FORTRAN simplifié.

— David Thornley

1

@MSalters Common Lisp était en fait un effort (assez réussi pour l'OMI) pour résoudre les incompatibilités des divers dialectes maclisp dictés entre autres par l'utilisation professionnelle (et la DARPA souhaitait également que tous les laboratoires de recherche financés puissent partager plus facilement le code) . Aujourd’hui, mis à part le schéma, le clojure et le lis commun, il n’existe aucune pratique générique, et ces trois sont assez différents, ont des communautés très distinctes avec des cultures et une histoire distinctes pour ne plus les compter comme dialectes de la même langue que java et C ++. .

— Pavel Penev

24

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.

— Don Stewart
source

2

J'aimerais en savoir plus sur les "fusions et concentrations activement poursuivies".

— Sam Tobin-Hochstadt

La fragmentation est naturelle. Les langages tels que Python et Ruby sont des anomalies qui ne se fragmentent généralement pas, si vous ne comptez pas les variantes non utilisées, telles que ChinesePython, et les variantes stagnant sous une version antérieure, telle que Jython. Il y a aussi un biais de survie ici, parce que la plupart des langues avec un dictateur ne deviennent pas très populaires, par exemple Nermerle, Groovy, Beanshell, Boo, en fait, il y en a probablement des milliers.

— Vorg van Geir

1

Même dans ce cas, Haskell pourrait encore être plus pratique pour atteindre le statut de maturité Python / Ruby. Haskell cabaln'est pas un outil amusant à utiliser et plutôt facile à casser: Même Yesod le reconnaît: yesodweb.com/blog/2012/04/cabal-meta Python et Ruby sont bien meilleurs en ce qui concerne la gestion des paquets.

— Ehtesh Choudhury

1

@Shurane Python et Ruby ne dactylographient pas, vérifiez vos paquets avant l'intégration ...

— Don Stewart

2

-1: pour "ruby; perl; python - trop défini par implémentation pour produire des alternatives viables" Jython, IronPython, JRuby, IronRuby, PyPy, Stackless vous prouvent le contraire en ce qui concerne les implémentations (et celles-ci ne sont que les principales). En outre, CPython est une implémentation de référence, mais pas la définition du langage, c’est

— vartec

12

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é.

— Henrik Hansen
source

J'aime réellement cette idée. Je peux utiliser de nombreuses formes de Lisp car aucune d’entre elles n’a de "framework tueur", mais si je veux utiliser Rails, je dois rester avec le canonique Ruby. Ce n'est certainement pas la seule réponse, mais j'aime bien votre hypothèse.

— chrisaycock

Je suis d'accord sur la partie de la plate-forme . Si vous avez un seul traducteur capable d’exécuter la langue, il n’y aura pas beaucoup de fragmentation.

— c69

Le lis commun n'a pas adopté tôt une seule définition parce que les gens avaient des opinions bien arrêtées sur certaines choses, par exemple les macros hygiéniques.

— Robert Harvey

Je suis tous les deux d'accord et pas d'accord avec cela. Je suis d’accord, car un «cadre décisif» corrige le langage principal avec des fonctionnalités utiles, encourage la croissance et permet une innovation rapide en dehors des spécifications standard. Je ne suis pas d'accord parce que, si les responsables de la maintenance du cadre ne font pas très attention, cette augmentation rapide de l'innovation pourrait conduire à de nombreuses accumulations et / ou fuites qui pourraient la rendre instable.

— Evan Plaice

1

(suite) Les frameworks tels que jQuery qui étendent idéalement les fonctionnalités de base des langages disparaîtront à l'avenir, les contributions les plus précieuses apportées par ces frameworks étant normalisées et intégrées au noyau. IMHO, les frameworks ont tendance à mourir le plus rapidement parce que les développeurs préfèrent généralement réduire / éliminer les dépendances à mesure que le code se stabilise. Si les développeurs de langage souhaitent rester pertinents, ils faciliteront ce processus en adaptant et en adoptant les fonctionnalités du framework et en encourageant leurs utilisateurs à réduire les dépendances à l'égard des frameworks tiers.

— Evan Plaice

7

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.

— Evan Plaice
source

Échelle? Voulez-vous dire ce dernier?

— Giorgio

@ George Oui, je déteste quand je mal orthographier cela.

— Evan Plaice

2

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.

— Barry Brown
source

6

-1 car: (1) Python 3.x n'est pas une fragmentation. Ce n'est que la prochaine étape dans l'évolution du langage; Python 2.x sera complètement supprimé dans quelques années. (2) Les autres implémentations de langage compatibles à 99% (le 1% étant des détails d'implémentation et la plupart plutôt obscurs) et refusant activement de prendre part à la définition de la langue ne constituent pas une fragmentation. (3) Un langage très différent qui partage un terrain d’entente et qui est quelque peu compatible (C ++ à C) n’est guère une fragmentation. (4) Accepter des idées de langues existantes n’est pas une fragmentation, c’est la seule façon de concevoir une langue.

2

@delnan: Python 2.x sera-t-il complètement supprimé dans quelques années? C'est un peu bête à dire, quand COBOL et Fortran sont toujours là!

— Mason Wheeler

3

@MasonWheeler Je parle de développement. L'ancien code sera toujours archivé sur le VCS, les téléchargements binaires non officiels peuvent rester pendant des décennies et certains magasins peuvent éviter le portage. Mais je m'attends à ce qu'un jour pas trop lointain, la grande majorité de la programmation Python se déroule en Python 3. Après tout, le développement des fonctionnalités 2.x a cessé depuis un certain temps (et ne reprendra que si vous faites un lavage de cerveau python-dev) , les corrections de bugs / mises à jour de sécurité ne sont pas censées se poursuivre indéfiniment, et une grande partie des bibliothèques sont portées sur Python 3, la plupart des autres logiciels étant soit impatients (par exemple, Djano), soit non entretenus.

1

@MasonWheeler Oh, et pour Fortran et COBOL: Fortran a reçu une nouvelle révision de norme om 2008, et COBOL en a eu une en 2002 avec une poignée de rapports techniques depuis.

@MasonWheeler Saviez-vous que le COBOL moderne permet une programmation orientée objet?

2

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.

— Torbjørn
source

1

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;)

— PSchwede
source