Il termine "Lisp" (o "Lisp-like") è un ombrello per molte lingue diverse, come Common Lisp, Scheme e Arc. Esiste una frammentazione simile in altre comunità linguistiche, come in ML.
Tuttavia, Ruby e Python sono entrambi riusciti a evitare questo destino, dove l'innovazione si è verificata più sull'implementazione (come PyPy o YARV) invece di apportare modifiche al linguaggio stesso.
Le comunità Ruby e Python hanno fatto qualcosa di speciale per prevenire la frammentazione della lingua?
Ruby e Python hanno entrambi dittatori benevoli al timone. Sono lingue profondamente radicate in preoccupazioni pragmatiche. Questi sono probabilmente i fattori più significativi che inibiscono la frammentazione. Lisp e ML, d'altra parte, sono più simili ai linguaggi "design by committee", concepiti nel mondo accademico, a fini teorici.
Lisp è stato originariamente progettato da John McCarthy come una notazione matematica pratica per i programmi per computer. Non l'ha mai implementato come un vero linguaggio di programmazione; la prima implementazione è stata sviluppata da Steve Russell , ma non era un dittatore benevolo. Nel tempo sono apparse molte diverse implementazioni di Lisp; Common Lisp era un tentativo di standardizzarli.
Lisp è più una "famiglia" di lingue. Così è ML, che ha seguito un percorso evolutivo simile a Lisp.
Un fattore probabile è semplicemente l'età. Lisp e ML sono molto più vecchi di Python e Ruby:
Lisp: 1958
ML: 1973
Python: 1991
Ruby: 1995
Lisp e ML hanno ovviamente visto un cambiamento molto più grande nelle capacità dell'hardware, più tendenze nell'informatica e un numero ancora maggiore di studenti di dottorato in cerca di qualcosa su cui lavorare.
Sono essenzialmente tutti linguaggi definiti dall'implementazione
Quando è facile creare una nuova implementazione di un linguaggio che è largamente compatibile con il codice esistente, allora gli hacker sono hacker, vanno avanti e lo fanno. Ognuno scrive un'implementazione Lisp ad un certo punto. I compilatori ML sono quasi obbligatori per i laureandi nella progettazione linguistica - dopotutto la lingua è notoriamente ben documentato .
D'altra parte abbiamo i linguaggi ad hoc e definiti dall'implementazione. O le lingue che sono così complesse da costituire un ostacolo significativo per produrre un'implementazione alternativa attuabile:
Questo apparente inconveniente - linguaggi troppo difficili da produrre alternative praticabili, hanno il massiccio al rialzo: le scarse risorse degli sviluppatori sono concentrate sull'unica vera implementazione.
Come nota storica, diversi membri della comunità Haskell hanno perseguito attivamente fusioni e concentrazione di sforzi di sviluppo, riconoscendo che qualsiasi frammentazione della comunità di sviluppatori avrebbe significato che non avremmo avuto successo. GHC è stato scelto e sponsorizzato.
Direi che un fattore è una piattaforma di definizione . Per Haskell la piattaforma è lo standard Haskell e il GHC (immagino). Per Ruby è stato Ruby on Rails a "definire" la piattaforma di sviluppo di Ruby. Per C era Unix.
Confrontalo a Lisp, dove non esisteva una piattaforma di kick-ass originale che definisse come fosse la lingua. Se ricordo correttamente, ogni macchina Lisp aveva delle leggere differenze a seconda del modello e del produttore. Common Lisp è stato per qualche motivo non definito. Probabilmente a causa di troppa concorrenza e riluttanza a spostarsi su un'altra piattaforma.
Questo è, naturalmente, interamente speculazione dalla mia parte. Il pensiero è venuto dal commento risponde sulla risposta di Harvey. Tuttavia, sembra che la piattaforma di definizione abbia molte forme, ma la proprietà comune sembra essere quella da cui guadagna popolarità.
Non dimenticare di valutare la cultura che guida lo sviluppo di una lingua
Vorrei anche considerare il fatto che lo sviluppo su python / php viene fatto attivamente in pubblico. Avete un gruppo di persone che inchiodano una specifica standard che è liberamente disponibile a chiunque / tutti.
Molto simile al W3C con lo standard HTML / CSS. Hai un piccolo gruppo di persone motivate che controllano i dettagli più fini di ciò che il linguaggio è progettato per realizzare. Tutto va in una specifica chiaramente definita prima di essere rilasciato al pubblico.
OTOH, le lingue come LISP sono biforcute a porte chiuse da professori o altre persone che credono sinceramente che la loro prospettiva sul "miglior uso" della lingua sia giusta. Possono essere contemporaneamente giusto e sbagliato allo stesso tempo, perché alcune implementazioni sono grandi in certe cose; mentre nessuno è il migliore in tutto.
Non è necessariamente una cosa negativa perché la diversità genera innovazione. Lingue come LISP sono e rimarranno grandi linguaggi per l'apprendimento e la ricerca perché spingono i confini della comprensione.
Ma le qualità che rendono un ambiente favorevole all'innovazione non sono necessariamente benefiche per la stabilità; al contrario, le qualità che rendono un ambiente buono per la stabilità non sono necessariamente buone per la creatività.
Quando lo sviluppo si basa sulla collaborazione attiva, a volte gli individui sono costretti a concedere il beneficio di un insieme più grande. Cattivo per la ricerca / buono per coerenza.
Il fatto è che stiamo ancora vivendo nel selvaggio west dello sviluppo del linguaggio di programmazione. Il problema di progettare il "linguaggio ideale" è così grande che, nonostante gli sforzi monumentali, nessuno è arrivato vicino a risolverlo.
Nel settore ricerca / università, c'è ancora molto spazio per miglioramenti e innovazione. Nel settore commerciale, dove c'è una crescita esponenziale del software utilizzato nelle applicazioni pratiche e la forza trainante è la semplicità e la coerenza.
Alcune lingue sono specializzate nella prima, alcune sono specializzate nella seconda. Quelli che cercano di specializzarsi in entrambi di solito non fanno molto bene e muoiono.
Per entrambi, mi riferisco ai linguaggi monolitici come VB / C # / Java. È troppo presto per dirlo, ma mi piacerebbe vedere come appaiono C # e Python tra 10 anni. Al ritmo attuale C # sta aumentando la funzionalità e l'incoerenza a un ritmo che lo rende piuttosto triste. Anche con una grande documentazione, è troppo doloroso ricordare tutti i dettagli e le stranezze particolari inclusi nella lingua. È fantastico per un singolo sviluppatore, ma non appena si introducono più sviluppatori con stili unici, l'incoerenza nel codebase aumenta, la qualità soffre e nessuno vince. Penso che ci sia molto da imparare dalle difficoltà che Perl presenta in un ambiente di produzione.
Non penso sia corretto affermare che linguaggi come Python e Ruby non sono frammentati. Stiamo già iniziando a vedere alcuni effetti di frammentazione. Ad esempio, Python 3 non è interamente retrocompatibile con Python 2, quindi entrambe le versioni devono essere mantenute e molti dei codici esistenti funzionano solo con Python 2. Ci sono anche alcuni spinoff Python, incluso PyPy.
Un altro fattore è l'età delle lingue. Quelli più soggetti alla frammentazione sono le lingue più antiche e sono quindi soggetti a pressioni di evoluzione e revisione. Lisp è stato inventato alcuni decenni fa, quindi c'è stato un ampio margine di tempo per prendere alcune delle sue idee e incorporarle in nuove lingue. C è un altro esempio di linguaggio frammentato. Mentre C aveva solo una revisione molto importante del linguaggio stesso (K & R per ANSI), ci sono stati numerosi spin-off tra cui C ++, Not Quite C e tutti gli altri che condividono una sintassi simile a C..
Ruby stesso è una "frammentazione" (se vuoi) delle lingue precedenti. Poiché incorpora idee da C, Smalltalk e Perl (tra gli altri), è attualmente la lingua che fa la frammentazione. Non vedo perché, in futuro, non potremmo vedere un'ulteriore convoluzione di Ruby con altre lingue.
Il Lisp è frammentato perché è un modello così potente, il linguaggio più sorprendente mai concepito. La maggior parte delle lingue oggi prende in prestito cose che sono state implementate per la prima volta in Lisp, quindi in un certo senso si può dire che ogni lingua fa parte di questa particolare frammentazione. Smalltalk è stato per esempio strongmente ispirato da Lisp e Ruby è strongmente ispirato a Smalltalk. JavaScript è Lisp in un travestimento Java, e così via. È tutto connesso e ogni inventore di lingua seleziona i suoi pezzi preferiti da altre lingue.
Un altro fattore è che il Lisp è probabilmente il concetto di programmazione più semplice da implementare, motivo per cui viene ripetuto ancora e ancora e ancora.
Le lingue di tipo Lisp sono troppo semplici e teoriche per essere cambiate radicalmente. I cambiamenti grammaticali (non intendo solo cambiare i nomi dei comandi) non si adattano alla teoria della programmazione funzionale che sta dietro di loro.
Ma il fatto che ci siano linguaggi come lisp mostra che "modifiche" sono già state apportate a lisp in ogni caso. In altre parole, ci sono linguaggi creati da persone che sono state ispirate dal lisp o dalla sua teoria e hanno creato un nuovo linguaggio simile in-one.
Ci sono anche molte lingue ispirate a Python. Per esempio. Julia, CoffeeScript, ecc. Che formerebbero la propria famiglia di linguaggi orientati agli oggetti sensibili allo spazio bianco.
Penso che le basi fondamentali di un linguaggio come Python non cambieranno mai davvero. Python è orientato agli oggetti e quindi ha somiglianze con C ++ e Java, ma è dinamico e quindi anche simile a molti linguaggi di script.
Bene a chi importa davvero delle lingue? Ciò che conta è lo scopo: il francese è simile al latino, ma le ragazze che capiscono il francese sono molto più sexy;)
Leggi altre domande sui tag programming-languages language-design