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


46

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?


2
Molti compilatori possono essere invocati con switch che applicheranno gli standard più vecchi (ad esempio, --std=xswitch di GCC ), quindi non è come se la creazione di standard più recenti produca strumenti che destabilizzano il codice più vecchio.
Blrfl

2
Come definisci "una nuova lingua basata sulla vecchia"? Direi che Fortran 90 è un "nuovo linguaggio" basato sul vecchio F77. Ha completamente cambiato il modo di programmare - fisso contro memoria libera, dinamica vs memoria statica, ecc. Si potrebbe anche sostenere che Fortran 2003 è un "nuovo linguaggio" basato su F90 - ha aggiunto la programmazione orientata agli oggetti mantenendo la compatibilità con F90. Sembra il rapporto tra C ++ e C.
tpg2114

1
Penso che questa domanda sia molto importante e non capisco perché alcuni vogliono chiuderla. È un fenomeno molto interessante che probabilmente ha qualche spiegazione. Alcuni (20?) Anni fa stavo leggendo delle nuove funzionalità di Fortran e mi sono chiesto: se i programmatori Fortran hanno bisogno di queste funzionalità, perché non passano semplicemente a C? Recentemente ho avuto una considerazione simile riguardo al C ++: se gli sviluppatori C ++ vogliono usare lambdas, perché non passare a, diciamo, OCaml ( linux-nantes.org/~fmonnier/ocaml/ocaml-wrapping-c.php )? Perché preferiscono creare un nuovo linguaggio e chiamarlo ancora C ++?
Giorgio,

3
@ tpg2114 La differenza tra (FORTRAN 77: Fortran 90) e (C: C ++) è che si ritiene che Fortran 90 abbia sostituito FORTRAN 77, al punto in cui viene detto alle persone: "Se vuoi imparare Fortran, impara Fortran 2003 o almeno 90, perché quello è lo standard ora. " Nessuno direbbe qualcosa del tipo "Se vuoi imparare il C, impara il C ++ perché quello è il nuovo standard", perché sono presentati in due lingue diverse. Come ho detto, le connotazioni hanno conseguenze.

6
PERCHÉ C NON È MAI MORTO
Adel

Risposte:


13

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


Questa risposta ha più senso per me di qualsiasi altra cosa abbia visto qui: l'aggiornamento di una lingua consente di ereditare (almeno parte di) la comunità esistente, le biblioteche, ecc. Ricordo di aver letto che il problema più grande di Lisp è il grande numero di dialetti incompatibili che rendono difficile mantenere una comunità; l'aggiornamento di una lingua esistente potrebbe essere un modo per evitare di frammentare altre comunità allo stesso modo.

@SunAvatar: Per quanto ne so Lisp ha diversi dialetti ma alcuni hanno più successo di altri (Common Lisp, Scheme, Racket, Clojure). Ogni volta che inizi una nuova lingua corri il rischio che solo una comunità molto piccola si riunisca attorno ad essa. Nella comunità Lisp sembra una pratica comune: se qualcuno ha una nuova idea, si ramificano e vedono cosa succede. Per i creatori di altre lingue, perdere la community non è un'opzione.
Giorgio,

@SunAvatar: non vedo l'eredità delle librerie esistenti come un argomento forte. Non è necessaria la compatibilità del codice sorgente per questo. Vedi ad esempio come Clojure e Scala possono usare il codice Java.
Giorgio,

1
Le lingue non muoiono, solo i programmatori che le usano.
Evan Plaice,

@SunAvatar: ci sono anche comunità che cercano di seguire una politica diversa: un nome identifica una lingua e se una parte della comunità crea un dialetto che diverge troppo, usano un nuovo nome per evitare confusione. Vedi ad esempio racket-lang.org/new-name.html
Giorgio,

21

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.


14
Il dominio problematico del testo scientifico di Tex = format non è cambiato molto. Il dominio dei linguaggi di programmazione = trova nuovi usi per i nuovi computer, è piuttosto più ampio. È la stessa ragione per cui il latino non aggiunge tante nuove parole come l'inglese
Martin Beckett,

Non credo che la compatibilità con le versioni precedenti sia una ragione valida: Scala può essere facilmente integrata con il codice Java esistente ma non è un super set di Java. Quindi penso in generale che non sia necessario che una nuova lingua sia compatibile con una vecchia a livello di codice sorgente. È sufficiente disporre di un meccanismo ben definito per chiamare il codice legacy dal nuovo codice.
Giorgio,

@Martin Beckett: "Il dominio problematico di Tex = formato del testo scientifico, non è cambiato molto.": Penso che ti stia perdendo il punto della domanda. Il PO non chiede se ci debba essere innovazione nei linguaggi di programmazione (nessuno può negare che l'innovazione è necessaria) ma perché i vecchi linguaggi vengono rivisti invece di crearne di nuovi.
Giorgio,

I sistemi si basano su investimenti di tempo, denaro e competenza (esperienza acquisita in una determinata lingua). I nuovi sforzi costano significativamente di più degli interventi di manutenzione (in tutte e tre le categorie). Senza miglioramenti del linguaggio e della piattaforma in generale, il costo della manutenzione aumenta e quindi il costo di un nuovo sistema è più attraente e il vero rehosting dell'app COBOL su una piattaforma completamente diversa per l'ottava volta nella sua vita potrebbe non sembrare piace moltissimo.
Giustino

Se non fosse per gli standard aggiornati del linguaggio COBOL e gli implementatori dello strumento COBOL che aggiungono le loro caratteristiche uniche lungo la strada, ciò ha migliorato il linguaggio e migliorato la capacità di operare su piattaforme più ampie, tradizionali e moderne; l'app non sarebbe sopravvissuta a 60 anni. Mentre i costi relativi sono certamente aumentati più tardi nella sua vita, a causa di una crescente scarsità di competenze, lo sforzo nel suo complesso è stato di centesimi sul dollaro rispetto a una riscrittura regolare quando è emersa la lingua del momento.
Giustino

5

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


Quindi, se "abbastanza persone si preoccupano delle lingue più vecchie" è la ragione, diresti che la tua risposta può essere riformulata come "attaccamento sentimentale alle lingue esistenti"? Non lo sto dicendo in senso peggiorativo, sto solo cercando di capire la tua risposta.
Avner Shahar-Kashtan,

No, intendevo dire che le lingue sono ancora in uso attivo e sono utilizzate da persone che vogliono trarre vantaggio dalle ultime tecniche. Non penso che nessuno aggiungerà il supporto multithreading ad ALGOL perché (AFAIK) non viene utilizzato attivamente. FORTRAN e COBOL, tuttavia, sono ancora utilizzati per sviluppare nuovi sistemi, quindi le loro specifiche linguistiche vengono periodicamente aggiornate per incorporare nuove tecniche e tecnologie.
TMN,

1

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


1
Le modifiche che descrivi nel secondo paragrafo sono piuttosto ineccepibili (per cui intendo non solo che non mi oppongo, ma che nessuno può obiettare seriamente). Per quanto riguarda lambdas, non posso commentare la loro utilità in C ++, ma perché preoccuparsi di aggiungerli se non per cambiare il modo in cui gli algoritmi vengono espressi?

Oh, sono incredibilmente utili. Non fraintendetemi. Sono l'aggiunta più importante in C ++ (IMO). Penso di non essere stato chiaro su cosa intendessi dire lì. Di solito si sceglie C ++ per avere accesso diretto alla memoria, prestazioni deterministiche e potenziale di ottimizzazione elevato. Ciò non cambia con le recenti aggiunte. Semplifichiamo molte delle altre attività di programmazione sul perché hai scelto C ++, ma C ++ è ancora valido e utile per gli stessi motivi. Lo schema viene aggiornato con regolarità, ma il codice come dati e la pigrizia non cambiano, quindi scegli lo schema per gli stessi motivi oggi di 20 anni fa.
Ben

"Per quanto riguarda lambdas, non posso commentare la loro utilità in C ++, ma perché preoccuparsi di aggiungerli se non per cambiare il modo in cui sono espressi gli algoritmi?": Vado ancora oltre: perché aggiungerli a C ++ invece di passare a un linguaggio che li ha avuti fin dall'inizio?
Giorgio,

2
@Giorgio Per avere il controllo della cache e delle funzioni di astrazione nella lingua. Se nessuna lingua esistente fornisce entrambe, non è possibile cambiare lingua senza sacrificarne una. Devi modificare una lingua o crearne una nuova.
mike30,

@mike: cosa intendi con "funzionalità cache"?
Giorgio,

-2

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.


Penso che stai pensando a "facetious".
uliwitness,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.