Mantieni un linguaggio di programmazione retrocompatibile e risolvendo i suoi difetti

Suona bene, ma raramente funziona nella pratica; le persone sono estremamente riluttanti a cambiare il codice in esecuzione, e anche per i nuovi progetti in campo verde sono molto riluttanti a passare da una lingua / versione che già conoscono.

Cambiare il codice esistente e funzionante che "funziona bene" non è qualcosa che si colloca in cima alla lista delle priorità di qualsiasi progetto. Piuttosto che applicare sforzi a cose che i gestori pensavano fossero già state pagate, solo per essere in grado di aggiornare a una versione più recente di una lingua o piattaforma, decreterebbero che gli sviluppatori dovrebbero semplicemente rimanere nella vecchia versione "per ora". Puoi provare ad attirare i tuoi utenti con fantastiche funzionalità disponibili solo nella nuova versione, ma è una scommessa in cui rischi di diminuire la base di utenti senza alcun guadagno chiaro per la lingua; caratteristiche moderne e interessanti non possono essere facilmente confrontate con il prezzo della base di installazione frammentata nell'opinione popolare, e si corre il rischio di ottenere una reputazione per essere un "tapis roulant aggiornato" che richiede uno sforzo costante per continuare a funzionare rispetto alle lingue / piattaforme più rilassate .

(Ovviamente, la maggior parte di questo non si applica ai progetti scritti dagli hobbisti solo per il loro piacere. Comunque (qui essere flamebait ...) PHP è sproporzionalmente scelto raramente dagli hacker perché è un vero piacere scrivere con primo posto.)

Stai sottovalutando l'impatto della retrocompatibilità; la tua stima che tutti i progetti attivi migrerebbero in 3 o 4 anni è troppo ottimista.

Supponiamo che io sia uno sviluppatore PHP. PHP ha dei difetti, ma so come aggirare questi difetti - questo è parte del motivo per cui sono pagato come sviluppatore PHP. Ora supponiamo che PHP 8 esca e risolva quei difetti, ma non è retrocompatibile. Di conseguenza:

• Devo passare il tempo ad aggiornare il mio codice per PHP 8. È il momento che potrei spendere per rispondere alle richieste dei clienti, implementare nuove funzionalità, tenere il passo con la concorrenza.
• Anche dopo che ho fatto questo , ci sono buone probabilità che mi sia sfuggito qualche caso d'angolo o un problema di compatibilità imprevisto, introducendo bug nel mio codice.

Dato questo, c'è un strong incentivo a mai migrare a PHP 8, anche se è "migliore, più chiaro, più sicuro ecc." Si stima che ci siano ancora miliardi di linee di COBOL (!) - anche se ovviamente ci sono tecnologie molto migliori disponibili, il costo di un aggiornamento, combinato con il rischio di bug, non vale la pena farlo.

In secondo luogo, anche se decido di migrare il mio codice, qualsiasi app non banale dipende da librerie di terze parti, e non c'è alcuna garanzia che le librerie di terze parti migreranno. Ad esempio, Python 3 è stato rilasciato nel dicembre 2008, ma Django (probabilmente il principale framework web Python) non aveva un supporto Python 3 stabile e pronto per la produzione da quasi cinque anni (vedi qui e qui ).

Stai facendo molte supposizioni sul comportamento umano. Se la cambi troppo, la gente valuterà i tuoi concorrenti, dal momento che dovranno comunque passare uno sforzo significativo. Per le lingue open source, le persone sostituiranno semplicemente la vecchia versione.

Guarda Python per un esempio. 3.x è disponibile da quattro anni e non è ancora ampiamente adottato. Le persone cercano di usarlo per progetti nuovi di zecca, ma penso che stai sottovalutando quanto lavoro sul codice sia in manutenzione.

Naturalmente, la maggior parte delle persone non ha ritenuto che python 2.x fosse "imperfetto". Non hanno avuto lamentele come utenti php. Php si trova in una posizione molto più precaria, perché molte persone lo seguono solo grazie alla sua ampia base di codice esistente. Se perdessi la compatibilità con le versioni precedenti, molte persone avrebbero colto l'opportunità che stavano aspettando per passare a Python.

Per qualsiasi lingua diversa da PHP direi, sì, che assolutamente ha senso! Questo è esattamente ciò che Python sta facendo con il passaggio a Python 3.

Tuttavia, il problema con PHP è che ci sono troppi difetti con la progettazione del linguaggio stesso, quindi quello che chiami "PHP 8" sarebbe un linguaggio completamente diverso. E se dovessi passare a una lingua diversa, perché dovresti seguire il nuovo PHP, piuttosto che una qualsiasi delle alternative attualmente esistenti e stabili?

Anche la comunità PHP è estremamente lenta nell'adattare qualcosa di nuovo. Guarda solo quanto tempo ci è voluto per eliminare register_globals . E 'noto per essere un rischio per la sicurezza dal 2000. E' stato rimosso definitivamente solo 12 anni dopo. Un altro esempio, quando è stato introdotto PHP5, è stato un enorme miglioramento rispetto a PHP4, tuttavia la comunità non l'ha adattata. Ho impiegato 4 anni e massicce azioni come GoPHP5 per dare il via all'adozione. E anche questo non ha avuto quantità significative di modifiche incompatibili all'indietro.

Dichiarazione di non responsabilità: gestisco un gruppo di utenti ColdFusion.

ColdFusion soffre degli stessi problemi: amato da molti, disprezzato da molti. Inoltre, tonnellate e tonnellate di FUD basate su versioni pre-Java. ColdFusion 10 è uscito l'anno scorso, è un grande venditore e la settimana scorsa mi sono iscritto per testare la versione preliminare della versione 11. Inoltre, ci sono due alternative open source principali, una delle quali è supportata da JBoss.

Ci sono tonnellate di nuove funzioni in CF10 che mi piacerebbe implementare, ma la migrazione da CF 7 o 8 può essere difficile a seconda delle dimensioni del tuo codice base, del numero di progetti imminenti e delle risorse che hai per il test di regressione tutto ciò una volta che sei sull'ultima versione. Ho riscontrato una serie di piccole differenze sintattiche tra 8 e 9, nonché casi limite in cui il codice non viene compilato nello stesso modo. Una volta trovato, li ho documentati nei nostri standard di codifica in modo che non vengano utilizzati in progetti futuri o da nuovi sviluppatori.

Detto questo, se ColdFusion 11 (o qualsiasi linguaggio di programmazione) dovesse completamente deprecare certe funzioni e sintassi, il livello di sforzo per trovare e sostituire funzionalità potrebbe essere enorme. Lo sforzo di test potrebbe essere gigantesco. Le aziende pagheranno i loro sviluppatori, QA e project manager per trovare, sostituire e testare tutte quelle cose deprecate? Dubbia.

Se l'ultima versione di una lingua è retrocompatibile, ma introduce un aumento delle prestazioni senza modifiche al codice (CF9 è circa il 30% più veloce di CF8 e CF10 è molto più veloce di CF9), a chi importa cambiare le chiamate di funzione se ancora lavoro?

Come azienda, dobbiamo preoccuparci di soddisfare i nostri clienti e soddisfare le loro esigenze al fine di fatturare i servizi, costruire l'azienda e reclutare più clienti.

FWIW, mi piacerebbe portarci sull'ultima versione di jQuery ad un certo punto, ma poiché alcune funzioni sono state deprecate alcune versioni dopo quello che usiamo, e dato il volume di JavaScript che abbiamo nel sistema, non lo faccio Sappiamo come riusciremo a farlo.

C'è un compromesso qui; alcuni bug hanno davvero bisogno di essere riparati, ma alcune cose non possono essere cambiate senza rompere il codice di qualcuno da qualche parte. Mi sembra di ricordare che qualcuno affermava come una "regola" che ogni bugfix spezzasse il progetto di qualcuno, non importa quanto oscuro o ovviamente rotto il bug, qualcuno lo userebbe per qualcosa. Questa è la natura dei programmatori.

Questa è (a mio avviso) la differenza tra le versioni principali, le versioni minori e le revisioni. Come principio generale:

• Si presume che le versioni principali contengano modifiche di rottura.
• Le versioni minori potrebbero modificare leggermente il comportamento.
• Le revisioni dovrebbero essere praticamente cross-compatibili.

Ad esempio, se scrivo qualcosa nella v2.3 di una lingua, non mi aspetto di notare alcuna differenza se eseguo l'upgrade alla v2.3.2. Se eseguo l'upgrade alla v2.4, alcune cose potrebbero cambiare: piccole modifiche alla sintassi, alcune funzioni si comportano in modo un po 'diverso quindi devo modificare la logica, ecc. Se eseguo l'aggiornamento alla v3.0, non sarei sorpreso se si rompesse interamente - funzioni deprecate o mancanti, operazioni non supportate o modificate così tanto che non posso semplicemente ridisegnarle in linea, in realtà devo riscrivere alcune funzioni per tenere conto delle nuove modifiche.

Modifica:

Il testo di Steve Vance Advanced SCM Branching Strategies ha questo da dire:

Typically, there are two to three levels of release, named by numbers connected with periods (e.g. 1.2.3). [...] In this structure the first number is associated with a major version, indicating that it has significant feature and functional enhancements from the previous; there may also be significant incompatibilities that require migration. The second number represents a minor version, which contains lesser feature and function enhancements, a significant number of bug fixes, and no incompatibilities. The third number refers to a patch level, signifying almost exclusively a collection of bug fixes; no feature or function enhancements and no incompatibilities are allowed between patch levels.

L'unica modifica che apporterei a questo è il suddetto principio che i programmatori spesso trovano modi per "usare" bug, quindi una versione minore con "un numero significativo di correzioni di bug e incompatibilità" potrebbe essere difficile, perché è probabilmente questi bug interromperanno qualcosa che li ha usati, o faranno diventare inutilizzabile una soluzione alternativa e inizieranno a causare problemi.

Dipende davvero da quale sia l'obiettivo della lingua - quali tipi di applicazioni sono progettati per essere costruiti con il linguaggio.

Ad esempio, ignorando Android, Java viene utilizzato principalmente in sistemi aziendali e middleware di grandi dimensioni; questi tipi di applicazioni tendono a diventare molto grandi sia in termini di dimensioni che di tempo. Questo ha alcune implicazioni; immagina un sistema con 500K + LoC su cui lavorano più di 50 ingegneri nella fase di sviluppo. In genere questo tipo di sistema entra in manutenzione dopo questo con 10 sviluppatori; ora se la lingua cambia e le modifiche non sono retrocompatibili, il progetto non può essere facilmente migrato a una nuova versione perché i programmatori che hanno scritto alcune parti sono spariti e nessuno vuole toccarlo. Questo è il problema più piccolo, il problema più grande consiste nel fatto che è un po 'costoso adattare un'applicazione 500 LoC a nuovi vincoli linguistici. Ad esempio, se i generici non sono stati implementati con la cancellazione dei tipi e List list = new List(); non è stato compilato, è necessario riscrivere milioni di righe di codice, il che è molto costoso.

D'altra parte, PHP tende ad essere utilizzato sul web per applicazioni più semplici; di solito è sviluppato da un singolo programmatore o da una piccola squadra. L'idea è che gli sviluppatori conoscono abbastanza bene l'intero progetto e possono integrare più facilmente i cambiamenti linguistici. Inoltre, lo scopo è quello di costruire un sito molto velocemente, e il più veloce è, meglio è, quindi se una nuova funzione linguistica può farlo meglio allora viene implementata anche con alcuni costi di compatibilità a ritroso.

Si può sostenere che Microsoft abbia eseguito un cambiamento simile con ASP.NET (come successore di ASP classico) o con VB.NET (anche se hanno fatto così tante concessioni con quest'ultimo che la maggior parte dei vantaggi del "riavvio" della lingua è andata persa ).

Ad ogni modo, se qualcuno ricorda l'incubo del codice VB6 migrante su VB.NET anche con l'aiuto di uno strumento di migrazione, sarà d'accordo sul fatto che gli strumenti di migrazione linguistica non funzionano molto bene per gli aggiornamenti linguistici più importanti.

Potrebbe essere possibile spostare la piattaforma in avanti, ma è comunque necessario fornire supporto per le API "deprecate" attraverso almeno alcune revisioni.

Molti dei "difetti" che la gente urla nei più popolari linguaggi di programmazione non lo sono, sono cose che il giocattolo preferito dagli urlatori del giorno ha che quella lingua manca, QUINDI quel linguaggio è fondamentalmente imperfetto perché manca questo. < br> Il prossimo hype arriva, la lingua è improvvisamente imperfetta perché non aderisce a questo clamore.

La mancanza di chiusure in Java è un classico esempio. Non è affatto un difetto nella lingua, e cambiare la lingua (come purtroppo è all'ordine del giorno) per includerli IMO fondamentalmente paralizzerà o, per lo meno, renderà molto più difficile leggere e comprendere.

Ciò che troppe persone perdono di vista è che ogni lingua ha i suoi punti di forza e di debolezza e che cercare di creare qualcosa che combini le forze di tutto evitando ogni debolezza creerà solo un mostro assolutamente inutilizzabile che è buono a nulla, incredibilmente ingombrante, impossibile da utilizzare in modo efficace.

Aggiungete, come altri hanno sottolineato, che la retrocompatibilità è vitale per mantenere gli utenti esistenti, molti dei quali NON passeranno le migliaia di ore e milioni di dollari / Euro per adattare le loro codebase di milioni di linee a qualsiasi cosa pensiate sia "migliore" rispetto alla versione del linguaggio che usano da anni, e hai una serie di ottimi argomenti da lasciare abbastanza bene da soli e se vuoi giocare con qualche nuova idea overhyped che è presumibilmente il prossimo "java killer" tu " È meglio giocare con quel giocattolo piuttosto che urlare "Java iz ded" a meno che non venga "riparato" per essere un clone di quel giocattolo.

Suggerirei che le versioni più recenti di una lingua dovrebbero sforzarsi di garantire che il 99,9999% di codice che compila sia nella vecchia che nella nuova versione della lingua dovrebbe funzionare in modo identico in entrambi, a meno che non sia deliberatamente progettato per non farlo, e che la maggior parte del tempo in cui la nuova versione rifiuta il codice compilato con la vecchia versione, sarà perché il codice è stato - nel migliore dei casi - oscuro, e avrebbe dovuto essere scritto in un modo diverso che sarebbe compilato sia con il vecchio che con il nuovo compilatore .

Ad esempio, se stavo progettando un nuovo linguaggio simile a Java o C #, vieterei le conversioni di tipo implicito in alcuni contesti in cui tali linguaggi consentono loro. Come un semplice esempio in C #, dato

int someInt;
double someDouble;

l'espressione someInt.Equals(someDouble) è garantita per restituire false, indipendentemente dal contenuto delle variabili. Si compila perché double può essere convertito in Object , e int ha un sovraccarico di Equals per quel tipo, quindi il compilatore esegue la conversione e fa la chiamata. Se stavo progettando una nuova versione di C # e .NET Framework, avrei vietato la conversione di boxe poiché non può fare nulla di utile. È possibile che ci sia un programma che fa un tale confronto in un modo che è inutile ma innocuo, e che il compilatore rifiuta tale codice potrebbe interrompere quel programma, ma correggere o rimuovere un tale codice inutile sarebbe un miglioramento.

Come esempio un po 'meno chiaro, supponiamo

float f=16777216f;
int i=16777217;

e considera l'espressione f==i . È possibile che alcuni codici facciano il confronto float / intero e funzioni correttamente, ma il codice dovrebbe essere riscritto come f==(float)i , (double)f==i; o (double)f==(double)i; [ int su double la promozione è senza perdita, quindi gli ultimi due sarebbe equivalente]. Alcuni codici che confrontano direttamente i valori di float e integer possono sempre trattare numeri che sono sufficientemente piccoli rispetto ai confronti di float e double che si comporterebbero in modo identico, ma generalmente un compilatore non può saperlo; il codice dovrebbe chiarire che tipo di confronto è necessario, piuttosto che sperare che le regole della lingua corrispondano all'intenzione del programmatore.

È meglio non interrompere mai la compatibilità all'indietro.

Microsoft ha sostituito il linguaggio di programmazione VB6 con un nuovo linguaggio che ha completamente interrotto la compatibilità. Quindi, anche oggi il 16enne VB6 è ancora più popolare della versione dotNet (indice Tiobe agosto 2014). E Gartner stima che ci siano 14 miliardi di righe di codice VB6 ancora in uso.

Nel 2014 Microsoft ha di nuovo dovuto annunciare che non aggiornerà o l'open source VB6 nonostante le richieste della comunità di programmazione di Visual Basic. Ma hanno esteso il supporto di VB6 fino a 'almeno' il 2024, e funziona bene su Windows 7 e 8. Ci saranno oltre 26 anni di supporto per la stessa versione di VB6.

Perché il software di lavoro esistente deve essere riscritto, anche Microsoft non ha mai "aggiornato" Office per utilizzare dotNet?

Ci sono alcuni problemi diversi con l'interruzione della compatibilità all'indietro. Alcuni dei problemi derivano dal fatto che la maggior parte dei linguaggi di programmazione sono anche piattaforme (interpreti / runtime), altri problemi derivano da un'assunzione della natura umana.

A. Il codice scritto in una versione precedente non beneficia delle nuove versioni che migliorano prestazioni, sicurezza o funzionalità. È possibile attenuare questo problema supportando più versioni principali del compilatore / interprete, ma si tratta di un enorme drenaggio delle risorse (ovvero è costoso o richiede molto tempo ed è un rompicapo).

B. Il codice scritto per le versioni più recenti potrebbe non essere compatibile con il codice scritto nelle versioni precedenti. È possibile aggirare il problema avendo un interprete / compilatore in grado di gestire più versioni principali del linguaggio, ma questo è più un rompicapo che supportare interpreti / compilatori separati (la soluzione alternativa per A).

C. I cambiamenti più importanti, se accadono troppo spesso / rapidamente, rendono anche più difficile usare la lingua, dal momento che devi imparare e disimparare di più. Le modifiche a una lingua potrebbero spingere le persone oltre il limite per passare a una nuova lingua, o potrebbero far sì che le persone continuino a utilizzare versioni obsolete della lingua e non passino mai alla nuova versione (come è successo con Python). Inoltre, i cambiamenti potrebbero attirare nuovi utenti e eccitare quelli vecchi.

D. La nuova documentazione deve essere mantenuta e mantenuta. È sempre un'esperienza piuttosto confusa cercare le cose su google e scoprire che stai leggendo i documenti per una versione diversa da quella che stai attualmente utilizzando.

In generale, se si crea un linguaggio di programmazione in cui i moduli esterni non devono preoccuparsi di quale versione si sta utilizzando, rompere la compatibilità con le versioni precedenti per i giusti motivi (per correggere i principali difetti nella lingua) è quasi sicuramente il giusto cose da fare. È probabile che la ragione principale per cui questo non viene fatto è che i progettisti di linguaggi di programmazione sovrastimano ( per contraddire la risposta di qualcun altro ) i costi di rottura della compatibilità, specialmente all'inizio. Il fatto è che i problemi di rottura della compatibilità possono essere risolti o potenziati dagli utenti di quella lingua. E questo non vale solo per i linguaggi di programmazione; questo vale per le API, le interfacce utente - davvero qualsiasi interfaccia in qualsiasi situazione.

Facebook infastidisce le persone quando cambia la sua interfaccia utente o le sue API per sviluppatori. In passato, ha reso la piattaforma difficile da gestire. In alcuni casi, le API hanno semplicemente smesso di funzionare all'improvviso. Ma le persone continuavano a usarlo, e ora le API e le interfacce utente sono migliori di quelle di 5 anni fa. La gente si lamenterà del cambiamento, sia esso positivo o negativo per loro, ma questo (lamentarsi) non è un buon motivo per rinunciare a questo cambiamento. Sfortunatamente, gli sviluppatori di linguaggi di programmazione usano questo come una ragione per mantenere intatti i problemi del loro linguaggio.

Quindi un altro paio di motivi per cui le lingue che non apportano modifiche di base per migliorarsi sono:

E. Gli sviluppatori di linguaggi ritengono che i loro utenti temano il cambiamento è una buona ragione per ristagnare la loro lingua

F. Agli sviluppatori di lingue è piaciuto il loro linguaggio quando ce l'hanno fatta, e probabilmente pensano che sia perfetto per i suoi difetti.

G. Le lingue man mano che invecchiano di solito smettono di avere un piccolo nucleo di sviluppatori e si trasformano in bestie costruite da commissioni. Ciò significa che le decisioni su quelle lingue sono lente e spesso conservatrici e non creative.

H. L'ultima ragione è che alcune modifiche urgenti richiedono una rivalutazione significativa delle decisioni di progettazione prese per l'interprete / runtime. A volte miglioramenti alla lingua richiedono semplicemente troppo lavoro per essere fattibili. Direi che questo è un problema più raro di molti.

Spesso i progettisti di linguaggi non sono necessariamente progettisti di strumenti e quindi non pensano a soluzioni valide a questo problema, oppure non li eseguono bene. Ecco alcune soluzioni a cui posso pensare per risolvere il problema dei cambi di rottura:

1. Deprecate le cose molto prima di quando saranno rimosse.

2. Fornisci uno buon , strumento di conversione standard. Python ha fornito lo strumento 2to3, ma non è stato ben pubblicizzato, non è venuto standard con python 3 come ricordo, e non ha nemmeno funzionato molto bene (ricordo di dover passare manualmente attraverso i programmi generati da 2to3 per risolvere i problemi non aggiustato). Questo strumento di conversione può anche essere eseguito automaticamente se il compilatore / interprete rileva una versione precedente. Cosa potrebbe essere più semplice?

Non so se questo è un problema per il codice PHP, ma in molte lingue vecchio, il codice legacy non viene mai aggiornato dopo anni o, a volte, anche decenni, perché funziona, è fondamentale per il business che lo esegue ed è troppo grande (diciamo milioni di SLOC), quindi non avrebbe senso riscriverlo. Questo è un motivo per cui java ha reso la retrocompatibilità un problema quasi religioso, nonostante conosca vecchi problemi, specialmente nelle biblioteche (anche se sono più facili da aggiornare). Immagino che un sacco di codice dal kernel di Linux non sia stato aggiornato per decenni, nonostante l'adozione di standard come C99 e C11.

Anche nelle lingue meno "imprenditoriali", il vecchio codice funzionale può costituire un problema. Questo è quello che è successo con Python 2 - > 3. Un sacco di librerie e script di sistema erano stabili e non mantenuti più, non perché erano stati abbandonati, ma perché erano stabili e stavano facendo il loro lavoro. Adattarli richiede alcuni anni. Quindi, come sviluppatore, non puoi necessariamente saltare a Python 3 se la tua libreria preferita non ha ancora effettuato la mossa, quindi il tuo codice non funzionerà neanche con python 3, risultando così nella frammentazione della community.

Il problema si trova nel problema di compatibilità con le versioni precedenti. La maggior parte degli script PHP che eseguo sono in esecuzione su un vecchio server RedHat. Se dovessi usare la versione più recente della lingua per futuri script, allora dovrei aggiornare PHP su questo server - e correre il rischio di avere i miei vecchi script interrotti / dover impiegare ore a riscrivere tutto il vecchio codice con il nuovo standard. Inoltre, tutti i miei sviluppatori sono abituati al fatto che PHP reagisca in un certo modo (sia che sia "rotto" o meno). Se non reagisce più in questo modo, potrebbe essere un ostacolo importante per la produttività, in quanto gli sviluppatori potrebbero dover sostanzialmente rieducarsi da soli PHP.