Perché il "linguaggio mainstream" è così contrario a "costruito su un piccolo nucleo di caratteristiche ortogonali"?

Perché i linguaggi naturali progettati non sono comuni

Ci sono tre motivi per cui impari un linguaggio naturale:

1. I tuoi genitori o l'ambiente parlano una lingua, e naturalmente cerchi di capire di cosa stanno parlando.
2. La tua scuola richiede di imparare un paio di lingue straniere.
3. ohmygosh {Esperanto, Quenya, Klingon, Lojban} è fantastico perché sono {interessato alla linguistica, a un fan di {LoTR, Star Trek}}.

Come accade, le lingue che impareresti al punto 3 non vengono generalmente pronunciate in pubblico o a casa e non vengono insegnate a scuola al posto del francese o dello spagnolo. Pertanto, sono tutti molto di nicchia.

La correlazione non implica nesso di causalità

Oh wow, quindi A e B sembrano avere qualche correlazione. A causa B? O viceversa? O ci sono altri fattori che non ho considerato?

La tua domanda sembra chiedere se un linguaggio di programmazione può diventare mainstream solo se non è ortogonale. Questo è fuorviante.

Le lingue evolvono

Le lingue cambiano nel tempo. La loro libreria standard viene rielaborata. Nuova sintassi aggiunta. L'orientamento dell'oggetto è reso disponibile. Le espressioni Lambda sembrano utili. Ma chiusure e oggetti possono essere implementati in termini l'uno dell'altro, quindi perché dovrei averne bisogno entrambi? Perché dovrei voler aggiungere generici o altri integratori di sistema? Ovviamente non ho bisogno di loro ...

Un linguaggio che non si evolve è probabilmente morto.

Alcune lingue sono fatte per portare a termine il lavoro

Per alcune lingue, la praticità è della massima importanza. Non importa se ci sono cinque o più cacciaviti nella mia cassetta degli attrezzi, perché non tutte le viti sono uguali. Un utente esperto sceglierà quello giusto per la situazione.

Altre lingue si sforzano di essere più minimali e / o eleganti. Questo può essere utile per scopi didattici o in contesti di ricerca. Le lingue piccole sono più facili da portare. Sono spesso utili, ma non sempre quando devi spedire la tua domanda ieri.

La quota di mercato è Ballast e Obbligo di spostarsi

Un linguaggio che cerca di essere rilevante domani deve continuare ad evolversi e includere nuovi concetti. Ad esempio, lo standard C ++ viene lentamente ma costantemente rielaborato. Ogni versione di Java è un passo avanti. C # è spesso all'avanguardia rispetto alle lingue tradizionali. Un linguaggio come SML o Smalltalk non ha serie ambizioni di diventare mainstream.

Un linguaggio già ampiamente utilizzato deve rimanere retrocompatibile o perdere quote di mercato. Le caratteristiche che erano lì ieri devono rimanere disponibili anche se è stata introdotta un'alternativa migliore. In Java, i parametri di tipo vengono cancellati durante la compilazione per back-compat. In PHP, lo spazio dei nomi principale è pieno di funzioni pericolose e deprecate che non possono essere rimosse senza interrompere una buona parte di Internet.

Conclusione

Suggerirei che le lingue di successo tendono a diventare meno ortogonali nel tempo, non solo che i linguaggi meno ortogonali tendono a diventare più facilmente mainstream. Tuttavia, non vi è alcun nesso di causalità perché ci sono più fattori da considerare.

Se guardo l'elenco delle lingue che hai collegato a noi vediamo come lingue ortogonali: Schema e Lua avevano il minimalismo come obiettivo di design, linguaggi accademici come Coq , Haskell , SML sono meno utili per la programmazione quotidiana o difficili da imparare, e alcuni linguaggi come Forth e APL sono usati a malapena.

Le lingue meno ortogonali sono abbastanza comuni o hanno una lunga storia. Fortran e COBOL sono antichi, ma hanno ancora una nicchia strong. Lingue come PHP e Shell sono cresciute al di là di ciò che intendevano fare. Alcune lingue sono esplicitamente pluralistiche, ad es. Perl e il suo discendente Ruby . La lingua C # è in competizione diretta con Java e cerca di ottenere un punteggio con caratteristiche migliori. Alcune lingue hanno un impegno religioso per il backcompat, ad es. C ++ o Perl .

Perché la riduzione del set di funzionalità di una lingua richiede un compromesso. Prendere una funzione fuori dalla lingua significa:

1. la lingua non ha più questa caratteristica, quindi le persone che hanno bisogno / valore di quella funzione non vogliono usare quella lingua (a parte: questo è il motivo per cui non ho mai provato golang ... mentre mi piacciono alcune delle le loro idee trovo le eccezioni troppo utili per abbandonare), o

2. la funzionalità deve essere implementata come libreria all'interno della lingua. Ma è difficile progettare un linguaggio tale che possa essere implementata un'ampia varietà di funzioni utili senza compromettere la sintassi, e la sintassi è fondamentale per guadagnare quote di mercato (se non lo fosse, useremmo LISP ormai).

LISP è un buon caso di studio: è costruito su un piccolo estremamente piccolo insieme di primitive di base, e quelle primitive possono essere combinate e ricombinate in modi molto utili, in modo tale che praticamente qualsiasi caratteristica linguistica tu può pensare di poter essere (e probabilmente è stato) implementato in LISP da qualche parte. Sfortunatamente, al fine di diventare abbastanza flessibile per raggiungere questo obiettivo, LISP ha compromesso quasi tutte le simpatie sintattiche, lasciando un linguaggio che (per dirla senza mezzi termini) solo gli hacker più esperti possono usare.

Non sto suggerendo che questo sia il modo solo di fare in modo che un piccolo linguaggio di base faccia cose utili e interessanti, ma certamente è più difficile farlo senza fare tali compromessi. E dato che il successo del linguaggio è un tipo di tipo "hit-and-miss", dominato principalmente da ciò che gli sviluppatori stanno cercando di fare che i loro linguaggi esistenti non funzionano bene e un nuovo linguaggio potrebbe fare meglio, la dimensione del core non lo fa Si può davvero capire molto se una lingua diventa popolare. E poiché creare un linguaggio piacevole con un nucleo di piccole dimensioni è più difficile che sacrificare una di queste funzioni, meno linguaggi di questo tipo sono fatti, il che rende sostanzialmente meno probabile (a causa della legge delle medie) che guadagneranno la trazione.

"Piccole caratteristiche ortogonali" è brillante in una lingua di insegnamento. È qualcosa che voglio, in una lingua in cui scrivo codice di produzione.

Ma apprezzo anche "ci sono buone librerie standard" e "Posso fare cose velocemente", dove c'è una strong correlazione tra "mancanza di buone librerie standard" e "piccolo linguaggio ortogonale". Esiste una debole correlazione tra "get stuff done quickly" e "small ortogonal", ma una massiccia anti-correlazione tra "get stuff done" e "lack of libraries".

Alcuni linguaggi ortogonali di piccole dimensioni prendono anche la loro "purezza" (per mancanza di una parola migliore) di uno o due passi troppo lontano, quindi mentre sono più puri e puliti, non appesantiti da considerazioni pratiche, in realtà finiscono per essere più difficile scrivere codice in .

Quando dico "codice di produzione" e "codice", intendo basi di codice di 100k linee e altro.