In che modo alcune comunità linguistiche (ad esempio, Ruby e Python) sono state in grado di prevenire la frammentazione, mentre altre (ad esempio, Lisp o ML) non lo erano?

67

Il termine "Lisp" (o "simile a Lisp") è un ombrello per molte lingue diverse, come Common Lisp, Scheme e Arc. Vi è una frammentazione simile in altre comunità linguistiche, come in ML.

Tuttavia, Ruby e Python sono entrambi riusciti a evitare questo destino, in cui l'innovazione si è verificata maggiormente 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 del linguaggio?

programming-languages language-design

— chrisaycock
fonte

10

Dici frammentazione come se fosse una brutta cosa.

— Sonia,

21

@Sonia Dal punto di vista della quota di mercato, la frammentazione è spesso un disastro.

— chrisaycock,

5

Le lingue sono in competizione tra loro?

— Barry Brown,

32

@Sonia Può essere una brutta cosa. Ad esempio, una libreria scritta per Python quasi sicuramente non dipende dall'implementazione, mentre una libreria scritta per Lisp potrebbe non funzionare in Scheme.

— Kris Harper,

2

@Barry Brown: ottimo punto! Le lingue non dovrebbero essere in concorrenza tra loro sul mercato. Ma i venditori di lingue lo sono e questo spesso influenza il design del linguaggio (non penso che sia il caso di Ruby, Python, Lisp, ML).

— Giorgio,

77

Ruby e Python hanno entrambi dittatori benevoli al loro timone. Sono lingue profondamente radicate in preoccupazioni pragmatiche. Questi sono probabilmente i fattori più significativi che inibiscono la frammentazione. Lisp e ML, invece, sono più simili ai linguaggi "design by Committee", concepiti in ambito accademico, a fini teorici.

Lisp è stato originariamente progettato da John McCarthy come una pratica notazione matematica per programmi per computer. Non l'ha mai implementato come un vero linguaggio di programmazione; la prima implementazione fu 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.

— Robert Harvey
fonte

4

Hmm, vedo sicuramente lo stato di dittatore tra comunità linguistiche omogenee come Objective-C (per app iOS) e Ada (per i contratti del Dipartimento della Difesa). In questi casi, un potere più elevato richiedeva l'adesione, che gli sviluppatori hanno seguito solo per poter vendere i loro articoli. Ma non mi è mai stato richiesto di scrivere codice in Python (progetto hobbista) nello stesso senso in cui mi potrebbe essere richiesto di scrivere codice in C # (componente .Net). Cioè, potrei fuggire più facilmente da Python che, diciamo, C. Senza questa minaccia di usarlo o non farai vendite , come può un dittatore trattenere il gregge? Questa potrebbe essere una domanda separata però.

— chrisaycock,

1

Per "dittatore benevolo" intendo che tutti i cambiamenti di lingua devono passare attraverso una persona che ha la visione di mantenere pura la lingua. Le persone stanno con Python per ragioni pragmatiche; a loro piace la lingua e ne sono produttivi. Ma non a tutti e ai loro fratelli è permesso di biforcarlo, e ancora lo chiamano Python.

— Robert Harvey,

4

@HenrikHansen Haskell è uno standard, come afferma Robert. Quindi il compilatore HUGS deve essere compatibile con GHC poiché entrambi si definiscono "Haskell". La stessa protezione basata su standard si estende a C e C ++, motivo per cui GCC e Visual Studio devono essere compatibili (presupponendo che non vengano utilizzate estensioni proprietarie). La curiosità è ciò che è accaduto a Lisp, dove esiste già uno standard (Common Lisp) e tuttavia ci sono molte altre Lisp. ML ha lo stesso problema in cui c'è ML standard e ancora altri ML.

— chrisaycock,

4

"Common Lisp è stato sviluppato per standardizzare le varianti divergenti di Lisp che lo hanno preceduto" - en.wikipedia.org/wiki/Common_Lisp . In altre parole, c'era già la frammentazione prima che lo standard fosse sviluppato.

— Robert Harvey,

3

Direi persino che ML e Lisp non sono linguaggi come lo sono Python e Ruby. Lisp e ML sono più simili a "concetti", implementati in diverse lingue.

— BenjaminB,

29

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 cambiamenti molto maggiori nelle capacità hardware, più tendenze nell'informatica e molti altri studenti di dottorato in cerca di qualcosa su cui lavorare.

— Caleb
fonte

7

Forse, ma non ricordo che Fortran abbia questo grado di biforcazione. (C'erano cose come Fortran D, ma la maggior parte di Fortrans ha attraversato la standardizzazione.) Suppongo che forse l'età della coalescenza potrebbe essere un fattore.

— chrisaycock,

2

AFAIK, Fortran ha avuto molte incompatibilità, estensioni non standard e diverse implementazioni fino a quando i comitati standard hanno gradualmente eliminato, probabilmente perché era più diffuso di Lisp e ML.

— Erjiang,

@erjian: FORTRAN ha eliminato le sue incompatibilità perché c'era un serio incentivo a: uso aziendale. LISP, utilizzato principalmente negli accademici, non ha mai avuto quel lusso. Cioè non è quanto fosse diffuso il suo uso, ma quanto erano ricchi i suoi utenti.

— Sali

2

O, in alternativa, le varianti non erano chiamate FORTRAN. BASIC, quando è uscito, sembrava sicuramente un FORTRAN semplificato.

— David Thornley,

1

@MSalters Common Lisp è stato in realtà uno sforzo (abbastanza riuscito IMO) per eliminare le incompatibilità nei vari dialetti maclisp dettati tra l'altro dall'uso delle imprese (e anche DARPA voleva che tutti i laboratori di ricerca finanziati fossero in grado di condividere il codice più facilmente) . Oggi oltre allo schema, al clojure e al lisp comune, non ci sono lisps pratici di uso generale e questi tre sono abbastanza diversi, hanno comunità molto separate con culture e storia separate per non contarli più come dialetti della stessa lingua più di quanto lo siano java e C ++ .

— Pavel Penev,

24

Sono essenzialmente tutti linguaggi definiti dall'implementazione

Quando è facile creare una nuova implementazione di un linguaggio ampiamente compatibile con il codice esistente, quindi gli hacker sono hacker, vanno avanti e lo fanno. Tutti scrivono un'implementazione di Lisp ad un certo punto. I compilatori ML sono quasi obbligatori per gli studenti laureati nella progettazione della lingua - la lingua è, dopo tutto, notoriamente ben documentata .

D'altra parte abbiamo i linguaggi ad hoc e definiti dall'implementazione. O lingue così complesse da costituire una barriera significativa per la produzione di un'implementazione alternativa praticabile:

rubino; perl; python - troppo definito dall'implementazione per produrre alternative praticabili
ghc haskell ed erlang - ben definito, ma così difficile da fare tutto ciò che compete con ghc (o erlang) che le persone di solito non si preoccupano

Questo aspetto negativo - i linguaggi a cui è troppo difficile produrre alternative praticabili, hanno il grande vantaggio: le scarse risorse per gli sviluppatori sono concentrate su un'unica vera implementazione.

Come nota storica, molti nella comunità di Haskell hanno attivamente perseguito le fusioni e la concentrazione degli sforzi degli sviluppatori, riconoscendo che qualsiasi frammentazione della comunità degli sviluppatori avrebbe significato che non avremmo avuto successo. GHC è stato scelto e sostenuto.

— Don Stewart
fonte

2

Mi piacerebbe saperne di più sulle "concentrazioni e concentrazioni attivamente perseguite".

— Sam Tobin-Hochstadt

La frammentazione è naturale. Linguaggi come Python e Ruby sono anomalie che non si sono frammentate principalmente, se non si contano le varianti non utilizzate, ad esempio ChinesePython, e le varianti che ristagnano in una versione precedente, ad esempio Jython. C'è anche una propensione alla sopravvivenza qui, perché la maggior parte delle lingue con un dittatore non diventano molto popolari, ad esempio Nermerle, Groovy, Beanshell, Boo, infatti ce ne sono probabilmente migliaia.

— Vorg van Geir,

1

Anche allora, Haskell potrebbe essere ancora più pratico per raggiungere lo stato di maturità di Python / Ruby. Haskell's cabalnon è uno strumento divertente da usare e piuttosto facile da rompere :. Anche Yesod lo riconosce: yesodweb.com/blog/2012/04/cabal-meta Python e Ruby sono molto meglio per quanto riguarda la gestione dei pacchetti.

— Ehtesh Choudhury,

1

@Shurane Python e Ruby non scrivono controlla i tuoi pacchetti prima dell'integrazione ...

— Don Stewart,

2

-1: per "ruby; perl; python - troppo definito dall'implementazione per produrre alternative praticabili" Jython, IronPython, JRuby, IronRuby, PyPy, Stackless dimostrano che hai torto per quanto riguarda le implementazioni (e queste sono solo le principali). Inoltre, CPython è un'implementazione di riferimento, ma non la definizione della lingua, questa è

— vartec

12

Direi che un fattore è una piattaforma determinante . 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.

Paragonalo a Lisp, dove non esisteva una piattaforma kick-ass originale che definiva la lingua. Se ricordo bene ogni macchina Lisp presentava lievi differenze a seconda del modello e del produttore. Il Lisp comune era per qualche motivo non definito. Forse a causa della troppa concorrenza e riluttanza a spostarsi su un'altra piattaforma.

Questa è, ovviamente, tutta una speculazione da parte mia. Il pensiero è venuto dalle risposte al commento 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à.

— Henrik Hansen
fonte

In realtà mi piace questa idea. Posso usare molte forme di Lisp perché nessuna di esse ha un "framework killer", ma se voglio usare Rails, devo attenermi al canonico Ruby. Certamente non è l'unica risposta, ma mi piace la tua ipotesi.

— chrisaycock,

sarei d'accordo sulla parte della piattaforma . Se hai un solo traduttore in grado di eseguire la lingua, non ci sarebbe molta frammentazione.

— c69,

Il lisp comune non si è stabilito presto su un'unica definizione perché le persone avevano opinioni forti su certe cose, ad esempio le macro igieniche.

— Robert Harvey,

Sono entrambi d'accordo e in disaccordo con questo. Sono d'accordo perché un "framework killer" corregge il linguaggio di base con preziose funzionalità, incoraggia la crescita e consente una rapida innovazione al di fuori delle specifiche standard. Non sono d'accordo perché, se i manutentori del framework non sono molto attenti, quel rapido aumento dell'innovazione potrebbe portare a un sacco di astrazioni gonfie e / o con perdite che potrebbero renderlo instabile.

— Evan Plaice,

1

(cont.) Framework come jQuery che estendono idealmente una funzionalità di base linguistica moriranno in futuro poiché i contributi più preziosi forniti da tali framework sono standardizzati e incorporati nel core. IMHO, i framework tendono a morire più velocemente perché gli sviluppatori generalmente preferiscono ridurre / eliminare le dipendenze mentre una base di codice si stabilizza. Se gli sviluppatori di lingue desiderano rimanere pertinenti, semplificheranno tale processo adattando e adottando la funzionalità del framework e incoraggiando i propri utenti a ridurre le dipendenze da framework di terze parti.

— Evan Plaice,

7

Non dimenticare di valutare la cultura che guida lo sviluppo di una lingua

Vorrei anche sottolineare il fatto che lo sviluppo su Python / PHP è attivamente svolto in pubblico. Hai un gruppo di individui inchiodare una specifica standard che è liberamente disponibile per chiunque.

Proprio come fa il W3C con lo standard HTML / CSS. Hai un piccolo gruppo di individui motivati che controllano i dettagli più fini di ciò che la lingua è progettata per realizzare. Tutto rientra in una specifica chiaramente definita prima di essere rilasciato al pubblico.

OTOH, lingue come LISP sono biforcute a porte chiuse da professori o altri individui che credono sinceramente che la loro prospettiva sul "miglior uso" della lingua sia giusta. Possono essere contemporaneamente giusti e sbagliati allo stesso tempo perché alcune implementazioni sono ottime 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 ottime lingue per l'apprendimento e la ricerca perché spingono i confini della comprensione.

Ma le qualità che rendono un ambiente buono per l'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 su una collaborazione attiva, a volte gli individui sono costretti a concedere a beneficio del grande insieme. Male per la ricerca / buono per coerenza.

Il fatto è che viviamo ancora nel selvaggio west dello sviluppo del linguaggio di programmazione. Il problema di progettare il "linguaggio ideale" è così grande che, nonostante gli sforzi monumentali, nessuno si è avvicinato per risolverlo.

Nel settore ricerca / università, c'è ancora molto spazio per il miglioramento e l'innovazione. Nel settore commerciale, dove c'è una crescita esponenziale del software utilizzato in applicazioni pratiche e la forza trainante è la semplicità e la coerenza.

Alcune lingue sono specializzate nella prima, altre nella seconda. Quelli che cercano di specializzarsi in entrambi di solito non fanno molto bene e muoiono.

Con entrambi, mi riferisco a linguaggi monolitici come VB / C # / Java. È troppo presto per dirlo, ma mi piacerebbe vedere come appariranno C # e Python tra 10 anni. Al ritmo attuale C # sta aumentando la funzionalità e l'incoerenza a un ritmo che lo fa sembrare piuttosto cupo. Anche con un'ottima documentazione, è troppo doloroso ricordare tutti i dettagli e le stranezze sottili inclusi nella lingua. È ottimo per un singolo sviluppatore, ma non appena aggiungi più sviluppatori con stili unici, l'incoerenza nella base di codice aumenta, la qualità soffre e nessuno vince. Penso che ci sia molto da imparare dalle difficoltà che Perl presenta in un ambiente di produzione.

— Evan Plaice
fonte

Scala? Vuoi dire quest'ultimo?

— Giorgio,

@Giorgio Sì, lo odio quando lo scrivo male.

— Evan Plaice,

2

Non credo sia corretto affermare che linguaggi come Python e Ruby non siano frammentati. Stiamo già iniziando a vedere alcuni effetti di frammentazione. Ad esempio, Python 3 non è completamente compatibile con le versioni precedenti di Python 2, quindi entrambe le versioni devono essere mantenute e un sacco di codice esistente funziona solo con Python 2. Esistono anche alcuni spinoff di Python, incluso PyPy.

Un altro fattore è l'età delle lingue. Quelle più soggette alla frammentazione sono le lingue più antiche e sono quindi soggette a pressioni di evoluzione e revisione. Lisp è stato inventato diversi decenni fa, quindi c'è stato molto tempo per prendere alcune delle sue idee e incorporarle in nuove lingue. C è un altro esempio di un linguaggio frammentato. Mentre C aveva solo una revisione molto importante del linguaggio stesso (da K&R a ANSI), ci sono stati numerosi spin-off tra cui C ++, Not Quite C e tutti gli altri che condividono una sintassi simile al C.

Il rubino stesso è una "frammentazione" (se vuoi) delle lingue precedenti. Dal momento che incorpora idee da C, Smalltalk, e Perl (tra gli altri), è attualmente la lingua facendo la frammentazione. Non vedo perché in futuro potremmo non vedere un'ulteriore convoluzione di Ruby con altre lingue.

— Barry Brown
fonte

6

-1 perché: (1) Python 3.x non è frammentazione. È solo il prossimo passo nell'evoluzione del linguaggio; Python 2.x verrà abbandonato interamente tra qualche anno. (2) Altre implementazioni linguistiche compatibili al 99% (l'1% sono dettagli di implementazione e per lo più piuttosto oscure) e rifiutano attivamente di prendere parte alla definizione della lingua non sono frammentazione. (3) Un linguaggio molto diverso che condivide un terreno comune ed è in qualche modo compatibile (da C ++ a C) non è certo frammentazione. (4) Accettare idee dalle lingue esistenti non è frammentazione, è l'unico modo in cui si progetta una lingua.

2

@delnan: Python 2.x verrà abbandonato completamente tra qualche anno? È una cosa un po 'sciocca da dire, quando COBOL e Fortran sono ancora in giro!

— Mason Wheeler,

3

@MasonWheeler Sto parlando di sviluppo. Il VCS avrà ancora un vecchio codice archiviato, i download binari non ufficiali potrebbero rimanere per decenni e alcuni negozi potrebbero evitare il porting. Ma mi aspetto che un giorno non troppo lontano, la stragrande maggioranza della programmazione Python avvenga in Python 3. Dopotutto, lo sviluppo delle funzionalità 2.x è cessato poco tempo fa (e non riprenderà a meno che non si faccia il lavaggio del cervello a python-dev) , gli aggiornamenti di bugfix / sicurezza non dovrebbero continuare per sempre e una parte significativa delle librerie viene trasferita su Python 3 con la maggior parte delle altre o in attesa di (ad esempio Djano) o non mantenute.

1

@MasonWheeler Oh, e quanto a Fortran e COBOL: Fortran ha ottenuto una nuova revisione standard dal 2008, e COBOL ha ottenuto una nel 2002 con una manciata di relazioni tecniche da allora.

@MasonWheeler Sapevi che il moderno COBOL consente una programmazione orientata agli oggetti?

2

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 ad esempio fortemente ispirato da Lisp, e Ruby è fortemente ispirato da Smalltalk. JavaScript è Lisp sotto mentite spoglie di Java, e così via .. È tutto collegato e ogni inventore di lingue seleziona i suoi pezzi preferiti da altre lingue.

Un altro fattore è che Lisp è probabilmente il concetto di programmazione più semplice da implementare, motivo per cui viene fatto ancora e ancora e ancora.

— Torbjørn
fonte

1

I linguaggi simili al Lisp sono troppo basilari e teorici per essere cambiati radicalmente. Cambiamenti grammaticali (non intendo solo cambiare i nomi dei comandi) non si adatterebbero alla teoria della programmazione funzionale dietro di loro.

Ma il fatto che ci siano lingue come lisp dimostra che i "cambiamenti" sono già stati fatti per lisp. In altre parole, ci sono lingue create da persone che sono state ispirate da lisp o dalla sua teoria e hanno creato un nuovo linguaggio simile.

Ci sono anche molte lingue ispirate a Python. Ad esempio Julia, CoffeeScript, ecc. Che formerebbero la propria famiglia di linguaggi orientati agli oggetti sensibili agli spazi.

Penso che le basi fondamentali di un linguaggio come Python non cambieranno mai veramente. 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ù calde;)

— PSchwede
fonte