La comprensione della storia di un linguaggio di programmazione aiuta a capire la lingua?

Questo dipende molto dal tuo stile di apprendimento (e dal fatto che la lingua abbia una storia interessante). Che storia può dirti:

• ciò che ha motivato il design iniziale della lingua e quali influenze c'erano
• quando sono state introdotte funzionalità più recenti, quali carenze venivano affrontate e come (se del caso) hanno cambiato l'uso idiomatico
• se un dato framework o libreria si avvale di nuove funzionalità linguistiche e, al contrario, se ha una base di adozione stabile e di lungo termine
• se la diffusione è il risultato di una buona integrazione tecnologica o di un marketing intelligente.

Che storia non può dirti:

• se i progettisti hanno capito bene, inizialmente o durante le successive modifiche
• se lo stato corrente riflette una lingua che desideri utilizzare
• se lo stato corrente corrisponde a qualcosa che dovrebbe utilizzare per il tuo progetto.

Grandi esempi di lingue che hanno una cronologia (indipendentemente dal fatto che ci si riferisca ad esso) includono C ++ e Java. In ogni caso, quando le funzionalità sono state aggiunte alla lingua è documentata, spesso insieme al motivo e se gli utenti stavano già provando a risolvere un problema a quelle nuove parti indirizzate.

Prendendo ulteriormente l'esempio di C ++, puoi vedere che alcune aggiunte allo standard provengono da librerie di terze parti come Boost. Inoltre, il libro di Stroustrup fa un buon lavoro di spiegazione dei problemi risolti dalle aggiunte.

Alcune cose potrebbero essere interessanti da sapere. La storia in sé non è importante, ma comprendi il perché è. In questo modo, la prossima volta che userai la sintassi, penserai al ragionamento alla base di tale sintassi piuttosto che cercare semplicemente di ricordare la sintassi stessa.

Spesso è più facile ricordare A e un modo logico di passare da A a B quindi da A a C, piuttosto che ricordare cosa sono B e C.

Anche se la storia dei linguaggi di calcolo e di programmazione può essere utile e interessante, direi che questo non è molto utile, perché le nuove versioni di un linguaggio cercano di correggere la vecchia sintassi strana. Prendiamo ad esempio come vengono dichiarate le funzioni in C (fonte: dichiarazione di funzione: K & R vs ANSI ):

// K&R syntax
int foo(a, p) 
    int a; 
    char *p; 
{ 
    return 0; 
}

// ANSI syntax
int foo(int a, char *p) 
{ 
    return 0; 
}

Questo è ancora più visibile quando confronti Fortran 77 e Fortran 90.

Martin Odersky apre la sua presentazione attuale su Scala (allo ScalaDays di New York e ripreso sulla costa occidentale) con una lezione di storia.

Che cosa ha motivato la popolarità della programmazione orientata agli oggetti? "Sono un vecchio ragazzo e lo ricordo."

Suggerisce che Scala occupa un momento storico nella transizione da un paradigma orientato all'oggetto a un paradigma funzionale, o come preferirebbe, una confluenza di questi paradigmi nello stile ibrido di Scala.

Il suo tema è che c'è più di un modo per farlo in Scala, e che questa è una buona cosa perché le scelte che fai, nella programmazione quotidiana, sono informate dalla pratica storica. Ad esempio, se usi i combinatori o un ciclo while; se estendi una funzionalità sottotitolo o pattern matching per gestire casi aggiuntivi; o qualcosa di semplice come se si esprima un'operazione con un simbolo (/: con il mnemonico di un domino che cade) o un nome (foldLeft).

(Una delle sue battute è che /: sembrava così bello ma è oscuro nella pratica, mentre ??? significare "non implementato" ha chiarezza immediata per chiunque guardi il codice.)

La storia non ti dice che esiste un modo giusto per affrontare un problema, ma che ce ne sono due o tre o nove. Odersky dice - riecheggiando il famoso editto di Knuth sull'ottimizzazione prematura - che non ti devi preoccupare di farlo bene la prima volta, che in effetti uno dei vantaggi di uno stile ibrido è che puoi provare il piacere di migliorare un'espressione , ottimizzando le prestazioni o la chiarezza o cosa hai, non una volta, ma più volte. Questo è ciò che rende divertente la programmazione!

Per Scala, la tensione tra stili funzionali e imperativi o orientati agli oggetti non è una battaglia da vincere, ma un Auseinandersetzung, che non è la parola di Odersky, ma di Heidegger per l'intimo rapporto di amore-odio tra due forze storiche esistenti in una stretta abitazione .

Daniel Spiewak sul problema dell'espressione: link

I talk di ScalaDays saranno presto pubblicati su parleys.com. link