Perché i cambiamenti linguistici di rottura minori non sono gestiti con i transpilers?

Ti focalizzi sulle modifiche alla sintassi in una lingua. Le modifiche alla sintassi sono abbastanza facili da eseguire in un modo compatibile con le versioni precedenti:

• La nuova sintassi sarebbe stata illegale nelle versioni precedenti. Ecco perché le nuove funzionalità linguistiche spesso riutilizzano le parole chiave o introducono parole chiave contestuali.

• Le nuove funzionalità devono essere abilitate esplicitamente, sia come switch di funzionalità nel codice sorgente (come use v5.22 o use feature 'state' ), o come opzione di compilazione (come g++ --std=c++14 o javac -source 1.8 ). Entrambe mettono efficacemente il transpiler nel frontend del compilatore stesso, evitando così la necessità di uno strumento extra.

Se una lingua non è ancora molto stabile, uno strumento di conversione di origine è più desiderabile che supportare le vecchie versioni di sintassi nel compilatore. Per Golang, go fix è uno strumento che può riscrivere il codice per riflettere la sintassi e le modifiche API. Ma a lungo termine, la stabilità è più importante: mentre non si può fare questo ogni giorno, è importante che anche il codice vecchio di decenni possa essere eseguito senza problemi extra. Le modifiche alla piattaforma incompatibili con le versioni precedenti potrebbero essere necessarie, ma spiegare perché alcune organizzazioni hanno bisogno di mantenere alcuni computer DOS o Windows XP in giro ...

Alcune modifiche alla lingua non influiscono sulla sintassi, ma sulla semantica. Riscrivere il codice per riflettere i cambiamenti semantici potrebbe essere possibile in alcuni casi semplici, ma nel caso generale è impossibile: si incontra rapidamente il problema dell'arresto.

Per facilitare la transizione da Python 2 a Python 3, è stato scritto un convertitore sorgente 2to3 . Con questo strumento, non ci si può aspettare che funzioni sempre senza interventi. Semplici aggiornamenti come la riscrittura delle dichiarazioni di stampa come funzioni di stampa non rappresentano un problema. Ma le modifiche ai tipi numerici ( long è stata piegata in int , che non è più di dimensione fissa e l'operatore / ora produce sempre float) sono già più difficili - ricorda che Python è digitato in modo dinamico. Gli usi non banali di metaprogrammazione sono completamente senza speranza. La lezione qui non è che non dovresti scrivere tali strumenti, ma quegli strumenti sono molto limitati in quello che possono fare.

Per le librerie e alcune applicazioni, è spesso importante che possano essere utilizzate con versioni in più lingue. Se dovessimo aggiornare il codice sorgente per utilizzare una versione più recente della lingua, ciò impedirebbe che funzionasse anche su altre versioni linguistiche. Tali programmi devono essere scritti nel sottoinsieme comune di tutte le versioni linguistiche. Questo non è ipotetico, ma ad es. comune in C ++ (dove potresti volere che i tuoi file di intestazione siano legali C code, o che voglia supportare più standard C ++), o in applicazioni per linguaggi interpretati come Perl, Python, PHP dove non vuoi forzare gli utenti ad aggiornare (spesso non possono essere aggiornati facilmente).

Rompere le modifiche della lingua sono quindi OK solo se hai il controllo su tutti gli aspetti della distribuzione e hai il tempo di verificare le modifiche apportate da alcuni strumenti di conversione. In caso contrario, gli utenti sono strongmente incentivati ad evitare l'aggiornamento alla nuova versione linguistica: i cambiamenti improvvisi sono altamente dirompenti e sono un strong indicatore del fatto che la lingua non è ancora adatta per uno sviluppo serio.

Se una funzione deprecata può essere convertita in sicurezza al suo equivalente, è davvero deprecata?

I linguaggi di programmazione sono disponibili per i programmatori, non per i computer. Potresti nutrire un computer mumbo-jumbo e se tu avessi un interprete mumbo-jumbo, funzionerebbe perfettamente.

Apportare piccole modifiche di rottura a una lingua catturerà di più di alcuni programmatori off-shore.

Penso che lo stai guardando dalla prospettiva sbagliata, centrato sul computer. Mentre dovresti guardare al punto di vista del programmatore.

Senza apportare modifiche potenzialmente , "interruzioni" in una lingua, una lingua non può evolversi (deve essere invece abbandonata e sostituita).

Esistono numerose strategie da affrontare e ridurre al minimo l'interruzione di tali cambiamenti che l'uso varia da una lingua all'altra e dipendono molto dalla mentalità degli sviluppatori linguistici.

Questi includono:

• Flag di compatibilità all'indietro per permetterti di specificare quale versione della lingua stai usando
• Versione Semantica ti consente di sapere quanto aspettarti di essere cambiato
• Il supporto lungo vive ti dà il tempo di recuperare
• Messaggi di errore in chiaro quando si incontra un vecchio codice
• Avvisi di deprecazione molto prima che venga introdotta la modifica finale
• Fornire strumenti di porting automatici - anche se questo può essere un problema se devi ancora supportare le versioni precedenti e quelle nuove.
• Strumenti per il porting manuale - idem
• Back porting ti permette di iniziare a introdurre le nuove funzionalità mentre usi ancora la vecchia versione
• Ottima documentazione e cronologia delle modifiche
• Supporto valido e reattivo possibilmente dagli autori delle modifiche.
• Supporto della comunità nei forum Web, SO, ecc.

Tutto quanto sopra può funzionare molto bene spostandosi in avanti in modo incrementale, cioè da una versione all'altra, ma in generale è probabile che si verifichino dei problemi quando si fa quando si saltano in avanti numerosi passaggi come spesso accade quando è necessario resuscitare un progetto che non è stato toccato da anni. Gli strumenti di porting cercheranno di aiutare, ma sono per natura inclini a sbagliare le cose perché gli autori degli strumenti non possono sapere ogni utilizzo.

I progetti open source, in particolare quelli con grandi sviluppatori e utenti, tendono a utilizzare tutto quanto sopra.

L'atteggiamento meno popolare è "è cambiato con esso" e modifica i cambiamenti anche su un numero di versione minore o modifica del numero di build senza menzionare alcuna compagnia specifica.