Esiste un meccanismo per rendere il linguaggio di programmazione più stabile (compatibile) per le modifiche?

Esistono molti linguaggi di programmazione. Alcuni di loro crescono e diventano molto popolari. Le persone usano tali lingue sempre più spesso. Il fondatore di tale linguaggio (o organizzazione / comunità fondatrice) può tentare di attuare modifiche per migliorare il linguaggio. Ma a volte è difficile apportare alcune modifiche a causa della retrocompatibilità e cose così brutte sono già esistite nella lingua da anni e sono utilizzate da molti utenti.

Ci sono dei principi o passaggi dell'architettura, durante la fase di progettazione del linguaggio, che possono aiutare a renderlo più stabile in modo che i progettisti del linguaggio non abbiano paura di rompere la compatibilità con le versioni precedenti?

La stabilità della lingua non è una decisione tecnica. È un contratto tra l'autore della lingua e gli utenti.

L'autore pubblicizza una data versione come più o meno stabile. Meno una lingua è stabile, più modifiche l'autore può apportare. Ogni utente interessato dalla lingua può decidere se desidera investire del tempo in essa per apprendere nuove funzionalità o sviluppare applicazioni che potrebbero essere interrotte dall'aggiornamento del mese prossimo.

L'uso di un linguaggio instabile può essere interessante perché sei interessato a un nuovo concetto o vuoi aiutare dando il tuo feedback. Se sei un'azienda, potresti preferire aspettare che una tecnologia sia più stabile prima di investire il tuo tempo in essa. Ti preoccupi di più di cose come il time to market e l'esperienza dell'utente.

Quindi questo è un problema di comunicazione e fiducia. Guarda lo sviluppo del linguaggio ruggine. Sono chiarissimi su ciò che stanno cambiando e su ciò che stanno mantenendo. Quando vogliono ritardare una decisione su una determinata funzionalità, usano quello che chiamano gate funzione. Dall'altro lato, la squadra angolare ha dovuto affrontare molta rabbia per l'annuncio 2.0 perché i cambiamenti erano più grandi del previsto.

Perfino l'autore delle biblioteche deve comunicare sulla stabilità delle loro api. Praticamente qualsiasi tecnologia utilizzata da altre persone deve trovare un equilibrio tra stabilità e perfezione. Un produttore di automobili non può cambiare la posizione dei pedali e un designer di laptop non inventerà un nuovo layout di tastiera per lo stesso motivo: non stai aiutando i tuoi utenti se non riesci a prendere una decisione sul modo in cui utilizzeranno il tuo prodotto.

• Tieni presente che le lingue cambiano nel corso della loro vita, indipendentemente da quanto bene possa essere progettato in anticipo. Invece di provare a spedire immediatamente il linguaggio più fantastico sulla terra, prima cerca di essere utile ed estensibile. Un linguaggio mediocre che posso effettivamente usare vale più di qualsiasi meraviglioso linguaggio di programmazione che esiste solo in teoria.

• Considerare le strutture per rendere estensibile la sintassi, ad esempio le macro. Le macro non sono automaticamente una buona cosa e possono essere troppo potenti. Alcune lingue hanno una sintassi molto flessibile sin dall'inizio che riduce la necessità di macro. Un paio di scenari da considerare:

  • Posso presentare un nuovo operatore come |>senza lasciare la lingua? Posso scegliere la precedenza e l'associatività per questo operatore?
  • Quante cerimonie devo svolgere per una funzione inline / lambda / chiusura?
  • Posso usare la sintassi del linguaggio esistente per implementare una sintassi del ciclo foreach? Ad esempio, Ruby e Scala possono farlo attraverso la loro sintassi di chiamata del metodo flessibile con lambdas.

• Considerare le strutture per mantenere estensibile la semantica. I bisogni comuni sono:

  • Sovraccarico dell'operatore, in cui i tipi definiti dall'utente possono assegnare il proprio significato agli operatori esistenti. Questo rende un linguaggio molto più piacevole nelle applicazioni matematiche pesanti.
  • Sovraccarico letterale. Posso fare in modo che i letterali delle stringhe siano del mio tipo di stringa? Posso rendere letterali tutti i letterali numerici nell'ambito attuale?
  • Protocolli Metaobject. Se la lingua non ha tratti, posso implementarli all'interno dell'attuale sistema di oggetti? Posso implementare un diverso ordine di risoluzione del metodo? Posso scambiare il modo in cui gli oggetti vengono archiviati o come vengono inviati i metodi?
• Avere test di regressione. Molti test. Non solo scritto dai progettisti del linguaggio, ma anche dagli utenti. Quando si aggiunge una funzione si interrompe questi test, valutare attentamente i vantaggi di quella funzione rispetto ai vantaggi della compatibilità con le versioni precedenti.
• Versione la tua lingua. Non solo nella documentazione, ma anche nel codice sorgente stesso. Una volta che lo fai, l'unica parte della tua lingua che non può cambiare è questa sintassi pragma versione. Esempi: la racchetta consente di specificare un dialetto. Perl lo consente use v5.20, il che abilita tutte le funzionalità incompatibili con le versioni precedenti di Perl v5.20. Puoi anche caricare singole funzionalità come esplicitamente use feature 'state'. Simile: Python's from __future__ import division.
• Prendi in considerazione l'idea di progettare la tua lingua in modo da ottenere poche parole riservate. Solo perché classintroduce una classe non implica che non sarei in grado di avere una variabile locale denominata class. In pratica, ciò si traduce in parole chiave che introducono dichiarazioni di variabili o metodi, in contrasto con la tradizione di tipo C di utilizzare nomi di tipi per introdurre dichiarazioni. Un'altra alternativa è usare i sigilli per il tuo $variables, come in Perl e PHP.

Parti di questa risposta sono influenzate dal discorso di Guy Steele “Growing a Language” (1998) ( pdf ) ( youtube ).

Penso che un passo piuttosto importante sia quello di promuovere un gestore di pacchetti che può anche gestire la versione della lingua stessa.

Ad esempio, utilizzo SBT per Scala o Leiningen per Clojure. Entrambi mi permettono di dichiarare quale versione della lingua che voglio usare, per progetto . Quindi è abbastanza facile avviare progetti ecologici nell'ultima versione della lingua, aggiornando i progetti esistenti a un ritmo più confortevole, se mai.

Ovviamente, a seconda della lingua, questo può ancora lasciarti con la necessità di attendere che le relative librerie vengano portate sulla versione di cui hai bisogno (questo accade, ad esempio, in Scala), ma rende comunque le cose più facili.