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

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

L'autore pubblicizza una determinata versione più o meno stabile. Più la lingua è stabile, più modifiche possono essere apportate dall'autore. Ogni utente interessato dalla lingua può decidere se vuole investire del tempo per apprendere nuove funzionalità o sviluppare applicazioni che potrebbero essere interrotte dall'aggiornamento del prossimo mese.

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

Quindi questa è una comunicazione & problema di fiducia. Guarda lo sviluppo del linguaggio della ruggine. Sono chiari su ciò che stanno cambiando e su cosa stanno mantenendo. Quando vogliono ritardare una decisione su una determinata caratteristica, usano quello che chiamano un cancello di funzionalità. Dall'altro lato, il team angolare ha affrontato molta rabbia rispetto al loro annuncio 2.0 perché le modifiche erano più grandi del previsto.

Anche gli autori delle librerie devono comunicare sulla stabilità della loro apis. Praticamente qualsiasi tecnologia utilizzata da altre persone deve trovare un equilibrio tra stabilità e perfezione. Un produttore di automobili non può modificare la posizione dei pedali e un designer di laptop non inventa un nuovo layout di tastiera per lo stesso motivo: non aiuti i tuoi utenti se non puoi prendere una decisione sul modo in cui useranno il tuo prodotto.

• Tieni presente che le lingue cambiano nel corso della loro vita, indipendentemente da come potrebbe essere progettato in anticipo. Invece di cercare di spedire immediatamente il linguaggio più fantastico sulla terra, prima cerca di essere utile ed estensibile. Una langauge mediocre che posso effettivamente usare vale più di ogni meraviglioso linguaggio di programmazione che esiste solo in teoria.

• Considerare le strutture per estendere la sintassi, ad es. macro. I 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 introdurre un nuovo operatore come |> senza lasciare la lingua? Posso scegliere la precedenza e l'associatività per questo operatore?
  • Quante cerimonie devo seguire per una funzione inline / lambda / chiusura?
  • Posso utilizzare la sintassi del linguaggio esistente per implementare una sintassi del ciclo foreach? Per esempio. Ruby e Scala possono farlo attraverso la sintassi di chiamata del metodo flessibile con lambdas.

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

  • Sovraccarico dell'operatore, in cui i tipi definiti dall'utente possono assegnare il proprio significato agli operatori esistenti. Ciò rende la lingua molto più divertente in applicazioni matematiche.
  • Sovraccarico letterale. Posso fare in modo che i letterali stringa siano del mio tipo di stringa? Posso fare in modo che tutti i valori letterali numerici nell'ambito corrente siano bignum?
  • Protocolli Metaobject. Se la lingua non ha tratti, posso implementarli all'interno del sistema di oggetti corrente? Posso implementare un diverso ordine di risoluzione dei metodi? Posso scambiare il modo in cui gli oggetti sono archiviati o in che modo vengono inviati i metodi?
• avere test di regressione. Un sacco di test. Non solo scritto dai progettisti di lingue, ma anche dagli utenti. Quando aggiungi una funzione interrompe questi test, pesa attentamente i vantaggi di tale funzione con il beneficio della retrocompatibilità.
• Versione della tua lingua. Non solo nella tua 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 di versione. Esempi: Racket consente di specificare un dialetto. Perl ti permette di use v5.20 , che abilita tutte le caratteristiche incompatibili con le versioni precedenti di Perl v5.20. Puoi anche caricare esplicitamente le singole funzioni come use feature 'state' . Simile: from __future__ import division di Python.
• Considerare la progettazione della tua lingua in un modo che risulti in poche parole riservate. Solo perché class introduce 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 dell'uso dei nomi di tipo per introdurre dichiarazioni. Un'altra alternativa è usare sigilli per $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 importante sia promuovere un gestore di pacchetti che possa anche gestire la versione della lingua stessa.

Per esempio, io uso SBT per Scala o Leiningen per Clojure. Entrambi consentono di dichiarare quale versione della lingua voglio utilizzare, per progetto . Quindi è abbastanza semplice avviare progetti ecologici nell'ultima versione della lingua, aggiornando i progetti esistenti a un ritmo più constrongvole, se mai.

Ovviamente, a seconda della lingua, questo potrebbe comunque lasciare il bisogno di aspettare che le librerie rilevanti siano trasferite alla versione che ti serve (questo accade, ad esempio, in Scala), ma rende le cose più semplici.