Perché i vecchi linguaggi di programmazione continuano a essere rivisti?

Questa domanda non è: "Perché le persone usano ancora vecchi linguaggi di programmazione?" Lo capisco abbastanza bene. In effetti i due linguaggi di programmazione che conosco meglio sono C e Scheme, entrambi risalenti agli anni '70.

Recentemente ho letto delle modifiche in C99 e C11 rispetto a C89 (che sembra essere ancora la versione più utilizzata di C in pratica e la versione che ho imparato da K&R). Guardando in giro, sembra che ogni linguaggio di programmazione in uso pesante ottenga una nuova specifica almeno una volta ogni decennio circa. Anche Fortran sta ancora ricevendo nuove revisioni, nonostante il fatto che la maggior parte delle persone lo stia ancora utilizzando FORTRAN 77.

In contrasto con l'approccio, diciamo, del sistema di composizione TeX. Nel 1989, con il rilascio di TeX 3.0, Donald Knuth dichiarò che TeX era completo di funzionalità e le versioni future conterrebbero solo correzioni di errori. Anche oltre a ciò, ha dichiarato che alla sua morte, "tutti i bug rimanenti diventeranno funzionalità" e assolutamente non verranno effettuati ulteriori aggiornamenti. Altri sono liberi di fork di TeX e lo hanno fatto, ma i sistemi risultanti vengono rinominati per indicare che sono diversi dal TeX ufficiale. Ciò non è perché Knuth pensa che TeX sia perfetto, ma perché comprende il valore di un sistema stabile e prevedibile che farà la stessa cosa in cinquant'anni che fa ora.

Perché la maggior parte dei progettisti di linguaggi di programmazione non segue lo stesso principio? Naturalmente, quando una lingua è relativamente nuova, ha senso che attraverserà un periodo di rapido cambiamento prima di stabilizzarsi. E nessuno può davvero obiettare a cambiamenti minori che non fanno molto di più che codificare pseudo-standard esistenti o correggere letture indesiderate. Ma quando una lingua sembra aver ancora bisogno di miglioramenti dopo dieci o venti anni, perché non limitarla o ricominciare da capo, piuttosto che provare a cambiare ciò che è già in uso? Se alcune persone vogliono davvero fare una programmazione orientata agli oggetti in Fortran, perché non creare "Objective Fortran" a tale scopo e lasciare in sé Fortran?

Suppongo che si possa dire che, indipendentemente dalle future revisioni, C89 è già uno standard e nulla impedisce alle persone di continuare a usarlo. Questo è un po 'vero, ma le connotazioni hanno conseguenze. GCC, in modalità pedante, avvertirà della sintassi che è deprecata o ha un significato leggermente diverso in C99, il che significa che i programmatori C89 non possono semplicemente ignorare totalmente il nuovo standard. Quindi ci deve essere qualche vantaggio in C99 che è sufficiente per imporre questo sovraccarico a tutti coloro che usano la lingua.

Questa è una vera domanda, non un invito a discutere. Ovviamente ho un'opinione su questo, ma al momento sto solo cercando di capire perché questo non è solo il modo in cui le cose sono già fatte. Suppongo che la domanda sia:

Quali sono i vantaggi (reali o percepiti) dell'aggiornamento di uno standard linguistico rispetto alla creazione di un nuovo linguaggio basato sul vecchio?

Penso che la motivazione per i progettisti di lingue a rivedere le lingue esistenti sia quella di introdurre l'innovazione garantendo al contempo che la loro comunità di sviluppatori target stia insieme e adotti la nuova lingua: spostare una comunità esistente in una nuova revisione di una lingua esistente è più efficace della creazione di una nuova comunità intorno a una nuova lingua. Naturalmente, questo costringe alcuni sviluppatori ad adottare il nuovo standard anche se stavano bene con quello vecchio: in una comunità a volte devi imporre determinate decisioni a una minoranza se vuoi mantenere la comunità insieme.

Inoltre, considera che un linguaggio generico cerca di servire il maggior numero possibile di programmatori e spesso viene applicato in nuove aree per le quali non è stato progettato. Quindi, invece di puntare alla semplicità e alla stabilità del design, la comunità può scegliere di incorporare nuove idee (anche da altre lingue) mentre la lingua si sposta in nuove aree di applicazione. In tale scenario, non puoi aspettarti di farlo bene al primo tentativo.

Ciò significa che le lingue possono subire profondi cambiamenti nel corso degli anni e l'ultima revisione può apparire molto diversa dalla prima. Il nome della lingua non viene mantenuto per motivi tecnici, ma perché la comunità di sviluppatori accetta di utilizzare un vecchio nome per una nuova lingua. Quindi il nome del linguaggio di programmazione identifica la comunità dei suoi utenti piuttosto che il linguaggio stesso.

IMO la motivazione per cui molti sviluppatori trovano questo accettabile (o addirittura desiderabile) è che una transizione graduale a una lingua leggermente diversa è più facile e meno confusa di un salto in una lingua completamente nuova che richiederebbe loro più tempo e sforzi per padroneggiare. Considera che ci sono un certo numero di sviluppatori che hanno una o due lingue preferite e non sono molto interessati all'apprendimento di nuove lingue (radicalmente diverse). E anche per coloro a cui piace imparare cose nuove, imparare un nuovo linguaggio di programmazione è sempre un'attività difficile e che richiede tempo.

Inoltre, può essere preferibile far parte di una grande comunità e di un ricco ecosistema rispetto a una comunità molto piccola che utilizza un linguaggio meno conosciuto. Quindi, quando la comunità decide di andare avanti, molti membri decidono di seguire per evitare l'isolamento.

Come commento laterale, penso che l'argomento di consentire l'evoluzione mantenendo la compatibilità con il codice legacy sia piuttosto debole: Java può chiamare il codice C, Scala può facilmente integrarsi con il codice Java, C # può integrarsi con C ++. Esistono molti esempi che dimostrano che è possibile interfacciarsi facilmente con il codice legacy scritto in un'altra lingua senza la necessità della compatibilità del codice sorgente.

NOTA

Da alcune risposte e commenti mi sembra di capire che alcuni lettori hanno interpretato la domanda come "Perché i linguaggi di programmazione devono evolversi".

Penso che questo non sia il punto principale della domanda, poiché è ovvio che i linguaggi di programmazione devono evolversi e perché (nuovi requisiti, nuove idee). La domanda è piuttosto "Perché questa evoluzione deve avvenire all'interno di un linguaggio di programmazione invece di generare molti nuovi linguaggi?"

La compatibilità con le versioni precedenti è la tua risposta. Un determinato linguaggio, in particolare uno ampiamente usato come C, può avere un codice che è in funzione, inalterato, per decenni. Se è necessario eseguire la manutenzione, è utile disporre di compilatori in grado di indirizzare ancora quel tipo di piattaforma durante l'esecuzione su sistemi moderni per il lavoro di sviluppo. Le standardizzazioni e gli aggiornamenti delle versioni linguistiche aiutano a mantenere aggiornate le pratiche di programmazione fornendo al contempo un senso di familiarità per i programmatori veterani che potrebbero essere resistenti all'apprendimento di un linguaggio "nuovo".

Tieni presente che molte delle lingue aggiornate sono meno aggiornate tanto quanto "hanno nuove punte lucide imbullonate". Le bestie di un tempo spesso si nascondono ancora dentro.

Per quanto riguarda Knuth, ricorda che è un accademico e che TeX si è dimostrato solo corretto, non aggiornato.

Penso che la risposta ovvia sia che si stanno ancora compiendo progressi nella progettazione del linguaggio e nell'architettura di sistema, e abbastanza persone si preoccupano delle lingue più vecchie che vogliono trarre vantaggio dalle nuove tecniche (più core, migliore threading o modelli di memoria) che vengono bloccate acceso o inserito nello standard linguistico. Aiuta anche ad avere "un vero modo" per fare cose (ad esempio, analisi XML, accesso al DB) su cui puoi contare per essere lì, indipendentemente dal compilatore o dalla piattaforma in cui ti trovi, al contrario di dipendere da alcune terze parti libreria che può o non può essere installata (e può essere o meno la versione richiesta, ecc.).

I concetti o gli obiettivi fondamentali su cui è costruita una lingua per scopi generali non perdono rilevanza; tuttavia piccoli cambiamenti nell'ambiente di lavoro o nell'hardware richiedono l'aggiunta di aggiornamenti o piccole funzionalità a una lingua.

Il modo in cui gli algoritmi sono espressi in una lingua non cambierà, anche se potrebbe essere necessario un supporto più pulito per i tipi a 64 bit, o un supporto più standard per le espressioni regolari o un supporto più solido per nuovi tipi di file system.

Ci sono alcuni casi in cui vengono aggiunte "nuove" funzionalità alle lingue esistenti, ma in molti casi questi cambiamenti equivalgono a semplificazioni di cose che le persone stavano già facendo nel modo più duro. (Vedi C ++ utilizzando le funzioni di ordine superiore anziché i puntatori e i funzioni delle funzioni.)

Questo è un po 'come una considerazione della lingua parlata.

In passato lì dove le parole non venivano usate così spesso come lo sono ora (o usate per un significato diverso).

per esempio. bello: nell'inglese (molto antico) ha il significato quasi inverso a quello che usiamo oggi, specialmente se usato per descrivere il carattere di qualcuno.

Cattivo: non molto tempo fa cattivo aveva un solo significato, ora può significare qualcosa che è "super sorprendente" (è usato in modo fittizio (probabilmente mi è mancato il farro fesico)!

un altro nuovo sviluppo è il cellulare "Text speak" per le lingue scritte.

Personalmente non vedo perché un linguaggio di programmazione non si svilupperà in modo simile, parole e funzioni hanno specifici significati / azioni ed è necessario che cambi per incorporare nuove idee, nuove metodologie.

Conosco persone che parlano molte lingue diverse e spesso suggeriscono che dopo il 3 o il 4 diventa più facile impararne una nuova.

Non so se ci sono programmatori che hanno un'esperienza simile, non sarei sorpreso se ci fossero.

So di sentirmi felice programmando in JAVA (così come mi sento felice parlare in inglese) Questo non significa che non posso comunicare in "inglese americano" o "inglese australiano" anche se ci sono alcuni "trucchi" a cui prestare attenzione . Proprio come andare da Java a PHP a Perl, i costrutti sono simili, ma ci sono piccoli trucchi per catturarmi e farmi sbattere la testa contro il muro.

Ciò è diverso dal passaggio dall'inglese al francese o da Java a SAS. questi sono così diversi che ci vuole un po 'di tempo per diventare abili.

Comunque questa è la mia opinione su questo.