Filosofia direttiva
1. Linguaggi di programmazione per le persone
I linguaggi di programmazione sono il modo in cui le persone comunicano con i computer. Il computer sarà felice di parlare in qualsiasi linguaggio che non sia ambiguo. Il motivo per cui abbiamo linguaggi di alto livello è che le persone non possono affrontare il linguaggio macchina. L'essenza dei linguaggi di programmazione è quella di prevenire il nostro povero fragile cervello umano dal sovraccarico di dettagli.
Gli architetti sanno che alcuni problemi di progettazione sono più concreti di altri. Una delle problematiche più chiare e astratte nella progettazione è quella di progettare ponti. In questo caso, il tuo lavoro consiste nel coprire la distanza richiesta con il minor quantitativo possibile di materiale. All'altro estremo dello spettro c'è la progettazione di sedie. I progettisti di sedie devono dedicare il loro tempo a riflettere sui sederi umani.
Lo sviluppo software ha una distinzione simile. Progettare algoritmi per instradare i dati attraverso una rete è un buon problema astratto, come progettare ponti. Mentre progettare linguaggi di programmazione è simile a progettare sedie: bisogna affrontare le debolezze umane.
Per la maggior parte di noi è difficile riconoscerlo. Progettare sistemi matematici eleganti suona molto più attraente per la maggior parte di noi rispetto a soddisfare le debolezze umane. Il ruolo dell'eleganza matematica è che una certa misura di eleganza rende i programmi più facili da comprendere. Ma l'eleganza non è tutto.
E quando dico che i linguaggi devono essere progettati tenendo conto delle debolezze umane, non intendo che i linguaggi debbano essere progettati per programmatori scarsi. In realtà, devi progettare il software per i migliori programmatori, ma anche i migliori programmatori hanno i loro limiti. Non credo che a qualcuno piacerebbe programmare in un linguaggio in cui tutte le variabili sarebbero designate con la lettera «x» con indici interi.
2. Progetta per te stesso e per i tuoi amici
Se guardi la storia dei linguaggi di programmazione, la maggior parte dei migliori linguaggi è stata progettata per essere utilizzata dai loro stessi autori, mentre la maggior parte dei peggiori è stata progettata per altre persone.
Quando i linguaggi vengono progettati per altre persone, si tratta sempre di un gruppo specifico: le persone non sono così intelligenti come i creatori del linguaggio. Così si ottiene un linguaggio che ti parla con condiscendenza. Cobol è l'esempio più evidente, ma la maggior parte dei linguaggi è intrisa di questo spirito.
Questo non ha nulla a che vedere con quanto sia di alto livello il linguaggio. C è abbastanza di basso livello, ma è stato creato per essere usato dai suoi autori, ed è per questo che gli hacker lo adorano.
L'argomento a favore della progettazione di linguaggi per programmatori scarsi è che ci sono più programmatori scarsi che bravi. Questo potrebbe essere vero. Ma quella piccola quantità di bravi programmatori scrive in modo sproporzionato più software.
Mi interessa la questione di come creare un linguaggio che piaccia ai migliori hacker? Penso che questa domanda sia equivalente a quella di come creare un buon linguaggio di programmazione?, ma anche se non lo fosse, è sicuramente una domanda interessante.
3. Dai al programmatore il maggior controllo possibile
Molti linguaggi (soprattutto quelli creati per altre persone) si comportano come delle babysitter: cercano di metterti in guardia da cose che pensano non ti saranno utili. Io la penso esattamente al contrario: dai al programmatore tanto controllo quanto puoi.
Quando ho studiato Lisp per la prima volta, ciò che mi è piaciuto di più è stato che parlavamo da pari. Negli altri linguaggi che avevo studiato fino a quel momento, c'era il linguaggio e c'era il mio programma in quel linguaggio, e coesistevano piuttosto separatamente. Ma in Lisp le funzioni e i macro che ho scritto erano le stesse su cui era scritto il linguaggio stesso. Potevo riscrivere il linguaggio stesso, se lo avessi voluto. Aveva lo stesso fascino del software open source.
4. La concisione è sorella del talento
La brevità è sottovalutata e persino disprezzata. Ma se guardi nei cuori degli hacker, vedrai che amano molto la brevità. Quante volte hai sentito hacker parlare con affetto del fatto che, ad esempio, in APL possono fare cose straordinarie con sole poche righe di codice? Credo che le persone veramente intelligenti apprezzino davvero questo.
Credo che quasi tutto ciò che consente di rendere i programmi più brevi sia positivo. Dovrebbero esserci molte funzioni di libreria, tutto ciò che può essere implicito dovrebbe esserlo; la sintassi dovrebbe essere il più concisa possibile; anche i nomi delle entità dovrebbero essere brevi.
E non solo i programmi dovrebbero essere brevi. Anche i manuali dovrebbero esserlo. Buona parte dei manuali è piena di spiegazioni, avvertenze, avvisi e casi particolari. Se hai bisogno di accorciare un manuale, la soluzione migliore è correggere il linguaggio che richiede così tante spiegazioni.
5. Riconosci cosa significa essere hacker
Molte persone vorrebbero che l'hackeraggio fosse come la matematica o, perlomeno, qualcosa di simile alle scienze naturali. Credo che l'hackeraggio assomigli di più all'architettura. L'architettura è legata alla fisica, nel senso che l'architetto deve progettare un edificio che non crolli, ma il vero obiettivo dell'architetto è creare un grande edificio, non fare scoperte nel campo della statica.
Ciò che gli hacker amano è creare grandi programmi. E penso che, almeno nelle nostre menti, dovremmo ricordare che scrivere programmi straordinari è meraviglioso, anche quando questo lavoro non si traduce facilmente in valuta intellettuale comune di pubblicazioni scientifiche. Dal punto di vista intellettuale, è altrettanto importante sviluppare un linguaggio che i programmatori amino quanto creare un'idea terribile di cui puoi pubblicare un articolo.
Problemi aperti
1. Come organizzare grandi librerie?
Le librerie diventano una parte importante dei linguaggi di programmazione. Stanno diventando così grandi che può diventare pericoloso. Se ci vuole più tempo per trovare una funzione in una libreria che fa ciò di cui hai bisogno, rispetto a scrivere tu stesso quella funzione, allora tutto il codice non fa altro che appesantire il tuo manuale. (Le guide di Symbolics ne sono un esempio.) Dobbiamo quindi risolvere il problema dell'organizzazione delle librerie. Ideale sarebbe progettarle in modo che il programmatore possa intuire quale funzione della libreria sia appropriata.
2. Le persone sono davvero spaventate dalla sintassi prefissa?
È un problema aperto nel senso che ci ho pensato per diversi anni e ancora non so la risposta. La sintassi prefissa mi sembra assolutamente naturale, tranne forse per il suo uso in matematica. Ma potrebbe essere che gran parte dell'impopolarità dei Lisp derivi proprio dalla sintassi poco familiare... Se sia utile fare qualcosa al riguardo, se è vero, è un'altra questione.
3. Di cosa hai bisogno per il software server?
Penso che la maggior parte delle applicazioni che verranno scritte nei prossimi vent'anni saranno applicazioni web, nel senso che i programmi saranno ospitati su un server e comunicheranno con te tramite un browser web. E per scrivere tali applicazioni abbiamo bisogno di nuove cose.
Una di queste cose è il supporto per un nuovo modo di rilasciare applicazioni server. Invece di uno o due grandi rilasci all'anno, come nel software desktop, il software server sarà rilasciato attraverso una serie di piccoli aggiornamenti. Puoi avere cinque o dieci rilasci al giorno. E tutti avranno sempre l'ultima versione.
Sai come progettare programmi affinché siano manutenibili? Il software server deve essere progettato per essere facilmente modificabile. Devi avere la possibilità di modificarlo senza problemi, o almeno sapere cosa significa un aggiornamento minore e cosa è importante.
Un'altra cosa che può essere utile nel software server è, improvvisamente, la continuità della distribuzione. In un'applicazione web puoi utilizzare qualcosa come , per ottenere l'effetto delle sotto-programmazioni in un mondo stateless di sessioni web. Potrebbe valere la pena mantenere la continuità della distribuzione, se questa opzione non si rivela troppo costosa.
4. Quali nuove astrazioni rimangono da scoprire?
Non sono sicuro di quanto sia ragionevole tale speranza, ma personalmente mi piacerebbe molto scoprire una nuova astrazione: qualcosa che potesse avere la stessa grande importanza delle funzioni di prima classe, della ricorsione o almeno dei parametri predefiniti. Forse è un sogno irrealizzabile. Queste cose non vengono spesso scoperte. Ma non perdo la speranza.
Segreti poco conosciuti
1. Puoi utilizzare qualsiasi linguaggio tu desideri
Un tempo, la creazione di applicazioni indicava la creazione di software desktop. E nel software desktop c'è una forte inclinazione a scrivere applicazioni nello stesso linguaggio del sistema operativo. Dieci anni fa, scrivere software in generale significava scrivere software in C. Alla fine, la tradizione si è evoluta: le applicazioni non devono essere scritte in linguaggi insoliti. E questa tradizione si è sviluppata così tanto che anche le persone non tecniche, come manager e investitori di venture capital, l'hanno compresa.
Il software server distrugge completamente questo modello. Con il software server puoi utilizzare qualsiasi linguaggio tu desideri. Quasi nessuno lo capisce ancora (soprattutto manager e investitori di venture capital). Ma alcuni hacker lo comprendono, ed è per questo che abbiamo sentito parlare di linguaggi indie come Perl e Python. Non sentiamo parlare di Perl e Python perché la gente li usa per scrivere applicazioni per Windows.
Cosa significa questo per noi, persone interessate alla progettazione di linguaggi di programmazione, è che c'è un pubblico potenziale per il nostro lavoro.
2. La velocità deriva dai profiler
I creatori di linguaggi, o almeno i suoi implementatori, amano scrivere compilatori che generano codice veloce. Ma penso che non sia questo a rendere i linguaggi veloci per gli utenti. Knuth ha notato tempo fa che la velocità dipende solo da pochi colli di bottiglia. E chiunque abbia cercato di velocizzare un programma sa che non puoi indovinare dove sia il collo di bottiglia. Il profiler è la risposta.
I programmatori del linguaggio stanno affrontando il problema sbagliato. Gli utenti non hanno bisogno che i benchmark siano veloci. Hanno bisogno di un linguaggio che possa mostrare quali parti del loro programma devono essere riscritte. In questo momento, la velocità è necessaria nella pratica. Quindi, forse sarebbe meglio se i realizzatori del linguaggio dedicassero metà del tempo che spendono per ottimizzare il compilatore alla scrittura di un buon profiler.
3. Hai bisogno di un'applicazione che faccia evolvere il tuo linguaggio
Forse non è la verità assoluta, ma sembra che i migliori linguaggi si siano evoluti insieme alle applicazioni in cui sono stati utilizzati. C è stato scritto da persone che avevano bisogno di programmazione di sistema. Lisp è stato sviluppato in parte per la differenziazione simbolica; McCarthy era così ansioso di iniziare che ha cominciato a scrivere programmi di differenziazione già nel primo documento su Lisp nel 1960.
Questo è particolarmente utile se la tua applicazione affronta alcuni problemi nuovi. Questo spinge il tuo linguaggio a avere nuove funzionalità di cui i programmatori hanno bisogno. Personalmente, mi interessa scrivere un linguaggio che sarà buono per le applicazioni server.
[Durante la discussione, Guy Steele ha anche espresso questo pensiero, aggiungendo che un'applicazione non dovrebbe consistere nello scrivere un compilatore per il tuo linguaggio, a meno che il tuo linguaggio non sia destinato a scrivere compilatori.]
4. Il linguaggio deve essere adatto per scrivere programmi usa e getta.
Sai cosa significa un programma usa e getta: è quando hai bisogno di risolvere rapidamente un compito limitato. Credo che se guardi in giro, troverai molti programmi seri che sono iniziati come usa e getta. Non mi sorprenderei se la maggior parte dei programmi sia iniziata come usa e getta. Quindi, se vuoi creare un linguaggio che sia adatto alla scrittura di software in generale, deve essere adatto anche per scrivere programmi usa e getta, perché questa è la fase iniziale di molti programmi.
5. La sintassi è legata alla semantica
Tradizionalmente si ritiene che sintassi e semantica siano cose molto diverse. Potrebbe sembrare scioccante, ma non è così. Penso che ciò che desideri ottenere nel tuo programma sia legato a come lo esprimi.
Recentemente ho parlato con Robert Morris, e lui ha notato che il sovraccarico degli operatori è un grande vantaggio per i linguaggi con sintassi infissa. Nei linguaggi con sintassi prefissa, qualsiasi funzione che definisci è essenzialmente un operatore. Se vuoi sommare un nuovo tipo di numero che hai inventato, puoi semplicemente definire una nuova funzione per aggiungerlo. Se fai così in un linguaggio con sintassi infissa, vedrai che c'è una grande differenza tra l'uso di un operatore sovraccarico e la chiamata di una funzione.
Idee che ritornano nel tempo
1. Nuovi linguaggi di programmazione
Riflettendo sugli anni '70, era di moda sviluppare nuovi linguaggi di programmazione. Oggi non è così. Ma penso che il software server riporterà la moda per la creazione di nuovi linguaggi. Con il software server, puoi usare qualsiasi linguaggio desideri; quindi, se qualcuno crea un linguaggio che sembra migliore degli altri, ci saranno persone pronte a utilizzarlo.
2. Tempi di inattività
Richard Kelsey ha proposto questa idea, il cui tempo è di nuovo arrivato, e io la sostengo completamente. Il mio presupposto (e anche quello di Microsoft) è che molti calcoli si sposteranno dai desktop ai server remoti. In altre parole, il tempo di inattività è tornato. Credo che ci sarà bisogno di supporto a livello di linguaggio. Ad esempio, Richard e Jonathan Rees hanno fatto molto lavoro per implementare la pianificazione dei processi in Scheme 48.
3. Efficienza
Recentemente sembrava che i computer fossero già abbastanza veloci. Sempre più spesso sentiamo parlare di bytecode, che per me significa che abbiamo capacità in riserva. Ma penso che con il software server, non ce l'abbiamo. Qualcuno dovrà pagare per servers, su cui il software opera, e il numero di utenti che un server può supportare per ogni singola macchina sarà il divisore dei loro costi di capitale.
Penso che l'efficienza avrà importanza, almeno nei colli di bottiglia dei calcoli. Questo sarà particolarmente importante per le operazioni di input-output, perché le applicazioni server generano molte di queste operazioni.
Alla fine potrebbe rivelarsi che il bytecode non è la soluzione. Al momento Sun e Microsoft sembrano affrontarsi faccia a faccia nel campo del bytecode. Ma lo fanno perché il bytecode è un luogo comodo per integrarsi nel processo, non perché il bytecode sia di per sé una buona idea. Potrebbe accadere che tutta questa battaglia passi inosservata. Sarebbe divertente.
Trappole e inganni
1. Clienti
È solo un'ipotesi, ma sembra che vinceranno solo le applicazioni che saranno completamente server-side. Progettare software che funziona con l'ipotesi che ognuno avrà il tuo client è come costruire una società basata sull'ipotesi che tutti saranno onesti. Sarebbe certamente comodo, ma dovresti accettare che ciò non accadrà mai.
Penso che ci sarà un rapido aumento dei dispositivi con accesso al web, e si può ipotizzare che supporteranno HTML di base e moduli. Hai un browser sul telefono? Ci sarà un telefono nel tuo PalmPilot? Il tuo blackberry avrà uno schermo più grande? Avrai la possibilità di navigare in internet con il tuo gameboy? Con i tuoi orologi? Non lo so. E non dovrò scoprirlo se scommetto che tutto sarà sul server. È semplicemente molto più affidabile avere tutta la logica sul server.
2. Programmazione orientata agli oggetti
Capisco che sia un'affermazione controversa, ma non penso che la OOP sia qualcosa di importante. Credo che sia una paradigama appropriata per applicazioni specifiche che necessitano di strutture dati particolari, come sistemi finestra, simulazioni, sistemi CAD. Ma non capisco perché dovrebbe essere adatta a tutti i programmi.
Penso che le persone nelle grandi aziende amino la OOP, in parte perché offre molto di ciò che sembra lavoro svolto. Ciò che naturalmente potrebbe essere rappresentato come, diciamo, una lista di numeri interi, ora può essere presentato come una classe con tutti i tipi di impalcature, con rumore e confusione.
Un'altra caratteristica attraente della OOP è che i metodi ti danno una sorta di effetto di funzioni di prim'ordine. Ma questa non è una novità per i programmatori di Lisp. Quando hai vere funzioni di prim'ordine, puoi semplicemente usarle in qualsiasi modo che si adatti al compito invece di cercare di forzare tutto in un modello di classi e metodi.
Credo che ciò significhi per il design del linguaggio che non si dovrebbe incorporare l'OOP troppo profondamente. La risposta potrebbe essere quella di offrire cose più generali e fondamentali, e permettere alle persone di progettare qualsiasi sistema basato su oggetti sotto forma di librerie.
3. Progettazione da parte di un comitato
Se il tuo linguaggio è progettato da un comitato, sei in una trappola, e non solo per le ragioni ben note. È risaputo che i comitati tendono a creare un design linguistico inconsistente e confuso. Ma credo che il pericolo maggiore sia che non si assumono rischi. Quando c'è una sola persona al comando, essa prende dei rischi che un comitato non accetterebbe mai di assumere.
È necessario correre dei rischi per creare un buon linguaggio? Molti potrebbero sospettare che la progettazione di un linguaggio sia qualcosa in cui si debba rimanere piuttosto vicini alla saggezza tradizionale. Posso scommettere che non è così. In tutto il resto che le persone fanno, la ricompensa è proporzionale al rischio. Allora perché dovrebbe essere diverso nella progettazione dei linguaggi?
Fonte: habr.com
