Filosofia guida
1. Linguaggi di programmazione per le persone
I linguaggi di programmazione sono il modo in cui le persone comunicano con i computer. Il computer è felice di comunicare in qualsiasi linguaggio che non sia ambiguo. La ragione per cui abbiamo linguaggi di alto livello è che le persone non possono gestire il linguaggio macchina. L'essenza dei linguaggi di programmazione è quella di proteggere il nostro fragile e vulnerabile cervello umano dall'essere sopraffatto da una miriade di dettagli.
Gli architetti sanno che alcuni problemi di design sono più concreti di altri. Uno dei problemi di design più chiari e astratti è la progettazione di ponti. In questo caso, il tuo compito è quello di coprire la distanza richiesta con il minor materiale possibile. All'altro estremo dello spettro c'è la progettazione di sedie. I progettisti di sedie devono dedicare del tempo a riflettere sui fondoschiena umani.
Lo sviluppo software presenta delle analogie. La progettazione di algoritmi per la routing dei dati attraverso una rete è una buona, astratta problematica, proprio come progettare ponti. Tuttavia, la progettazione di linguaggi di programmazione è paragonabile alla progettazione di sedie: bisogna affrontare le debolezze umane.
A molti di noi è difficile ammetterlo. Progettare sistemi matematici eleganti suona molto più allettante per la maggior parte di noi rispetto a cedere alle debolezze umane. Il ruolo dell'eleganza matematica è che una certa dose 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 scadenti. In realtà, si dovrebbe 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 sono designate dalla 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 rivolgono sempre a un gruppo specifico: le persone non sono intelligenti come i creatori del linguaggio. Così ottieni un linguaggio che ti parla in modo condiscendente. Cobol è l'esempio più evidente, ma la maggior parte dei linguaggi è pervasa da questo spirito.
Questo non ha nulla a che fare con il livello del linguaggio. C è sufficientemente basso livello, ma è stato creato per essere utilizzato dai suoi autori, ed è per questo che gli hacker lo amano.
L'argomento a favore della progettazione di linguaggi per programmatori scarsi è che ci sono più programmatori scarsi che bravi. Probabilmente è vero. Ma è un numero ridotto di bravi programmatori a scrivere una quantità sproporzionata di software.
Mi interessa sapere come creare un linguaggio che piaccia ai migliori hacker? Penso che questa domanda sia equivalente a come creare un buon linguaggio di programmazione?, ma anche se non è così, è comunque una domanda interessante.
3. Dare al programmatore il maggior controllo possibile
Molti linguaggi (soprattutto quelli creati per altri) si comportano come dei babysitter: cercano di metterti in guardia da cose che ritengono non ti serviranno. Io la penso diversamente: dai al programmatore il maggior controllo possibile.
Quando ho iniziato a studiare Lisp, la cosa che mi è piaciuta di più è stata che parlavamo da pari. Negli altri linguaggi che avevo studiato fino a quel momento, c'era un linguaggio e la mia programma in quel linguaggio, e esistevano piuttosto separati. Ma in Lisp, le funzioni e i macro che ho scritto erano le stesse di quelle su cui era costruito il linguaggio stesso. Avrei potuto riscrivere il linguaggio se lo avessi voluto. Aveva lo stesso fascino del software open source.
4. La brevità è sorella del talento
La brevità è sottovalutata e persino disprezzata. Ma se guardate nei cuori degli hacker, vedrete che amano profondamente la concisione. Quante volte avete sentito gli hacker parlare con affetto del fatto che, ad esempio, in APL possono fare cose sorprendenti con solo un paio di righe di codice? Credo che le persone veramente intelligenti amino prestare attenzione a questo.
Penso che quasi tutto ciò che rende i programmi più brevi sia positivo. Devono esserci molte funzioni di libreria, tutto ciò che può essere implicito dovrebbe esserlo; la sintassi dovrebbe essere per lo più concisa; anche i nomi delle entità dovrebbero essere brevi.
E non solo i programmi devono essere brevi. Anche i manuali devono esserlo. Una buona parte dei manuali è piena di spiegazioni, avvertenze, caveat e casi particolari. Se dovete ridurre un manuale, la soluzione migliore è migliorare il linguaggio che richiede così tante spiegazioni.
5. Riconoscere che cos'è l'hackeraggio
Molte persone vorrebbero che l'hacking fosse matematica o, almeno, qualcosa di simile alle scienze naturali. Penso che l'hacking somigli di più all'architettura. L'architettura è legata alla fisica, nel senso che l'architetto deve progettare un edificio che non crolli, ma l'obiettivo reale dell'architetto è creare un grande edificio, non fare scoperte nel campo della statica.
Ciò che gli hacker amano è creare grandi programmi. E credo che, almeno nei nostri pensieri, dovremmo ricordare che scrivere programmi straordinari è fantastico, anche quando questo lavoro non è facilmente traducibile nella consueta valuta intellettuale degli articoli scientifici. Dal punto di vista intellettuale, è altrettanto importante sviluppare un linguaggio che i programmatori ameranno, così come creare qualcosa di terrificante che incarni l'idea su cui puoi pubblicare un articolo.
Problemi aperti
1. Come organizzare grandi biblioteche?
Le librerie stanno diventando una parte importante dei linguaggi di programmazione. Stanno diventando così grandi che può essere pericoloso. Se ci vuole più tempo per trovare una funzione in una libreria che fa ciò di cui hai bisogno rispetto a scrivere quella funzione da solo, allora tutto il codice non fa altro che appesantire il tuo manuale. (Le guide di Symbolics erano un esempio di questo.) Dobbiamo affrontare il problema dell'organizzazione delle librerie. Idealmente, dovremmo progettarle in modo che il programmatore possa intuire quale funzione della libreria sia adatta.
2. Le persone sono davvero spaventate dalla sintassi prefissata?
È un problema aperto nel senso che ci ho pensato per diversi anni e non so ancora la risposta. La sintassi prefissata mi sembra assolutamente naturale, tranne forse per il suo uso in matematica. Ma potrebbe essere che gran parte dell'impopolarità dei Lisp sia semplicemente dovuta alla sintassi poco familiare… Fare qualcosa al riguardo, se è vero, è un'altra questione.
3. Cosa ti serve per il software server?
Penso che la maggior parte delle applicazioni che verranno sviluppate nei prossimi venti 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 soluzioni.
Una di queste soluzioni è il supporto a un nuovo modo di rilasciare applicazioni server. Invece di uno o due grandi rilasci all'anno, come nel software desktop, il software server verrà rilasciato tramite una serie di piccoli aggiornamenti. Potresti avere cinque o dieci rilasci al giorno. E tutti avranno sempre l'ultima versione.
Sai come progettare programmi in modo che siano manutenibili? Il software server deve essere progettato per poter essere modificato. Devi avere la possibilità di cambiarlo facilmente, o almeno sapere cosa significa un piccolo cambiamento e cosa è considerato importante.
Un'altra cosa che può essere utile nel software server è, improvvisamente, la continuità della fornitura. In un'applicazione web puoi utilizzare qualcosa come , per ottenere l'effetto dei sottoprogrammi in un mondo web stateless. Potrebbe valere la pena considerare la continuità della fornitura se questa opzione non risulta 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 possa avere la stessa grande importanza delle funzioni di primo ordine o della ricorsione o almeno dei parametri predefiniti. Forse è un sogno irrealizzabile. Tali cose spesso non si scoprono. Ma non perdo la speranza.
Segreti poco conosciuti
1. Puoi utilizzare qualsiasi linguaggio tu voglia
In passato, la creazione di applicazioni significava sviluppare software per desktop. E nel software desktop c'era una forte inclinazione verso la scrittura di 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 stravaganti. E questa tradizione si è evoluta così a lungo che anche le persone non tecniche, come i manager e i capitalisti di rischio, l'hanno appresa.
Il software server distrugge completamente questo modello. Con il software server puoi utilizzare qualsiasi linguaggio desideri. Quasi nessuno lo comprende ancora (soprattutto i manager e i capitalisti di rischio). Ma alcuni hacker lo capiscono, ed è per questo che abbiamo sentito parlare di linguaggi indie come Perl e Python. Non sentiamo parlare di Perl e Python perché le persone li utilizzano per scrivere applicazioni per Windows.
Cosa significa questo per noi, persone interessate alla progettazione di linguaggi di programmazione, è che esiste un potenziale pubblico per il nostro lavoro.
2. La velocità deriva dai profiler
Gli sviluppatori di linguaggi o, quantomeno, i loro 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 da tempo che la velocità dipende solo da alcuni colli di bottiglia. E chiunque abbia cercato di rendere un programma più veloce sa che non puoi indovinare dove si trova 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 funzionino rapidamente. Hanno bisogno di un linguaggio in grado di mostrare quali parti del loro programma devono essere riscritte. In quel momento, la velocità è necessaria nella pratica. Quindi, potrebbe essere meglio se i realizzatori del linguaggio dedicassero metà del tempo che spendono per ottimizzare il compilatore a scrivere un buon profiler.
3. Hai bisogno di un'applicazione che faccia evolvere il tuo linguaggio
Non sarà la verità assoluta, ma sembra che i migliori linguaggi si siano evoluti insieme alle applicazioni in cui venivano utilizzati. Il C è stato creato da persone che avevano bisogno di programmazione di sistema. Il Lisp è stato sviluppato in parte per la differenziazione simbolica; McCarthy non vedeva l'ora di iniziare, tanto che ha cominciato a scrivere programmi di differenziazione già nel primo documento su Lisp nel 1960.
Questo è particolarmente utile se la tua applicazione affronta nuovi problemi. Questo spinge il tuo linguaggio a dotarsi di nuove funzionalità di cui i programmatori hanno bisogno. Personalmente, sono interessato a scrivere un linguaggio che sia valido per le applicazioni server.
[Durante la discussione, Guy Steele ha anche espresso questo pensiero, aggiungendo che l'applicazione non dovrebbe consistere nella scrittura di un compilatore per il proprio linguaggio, a meno che il proprio linguaggio non sia destinato alla scrittura di compilatori.]
4. Il linguaggio deve essere adatto per scrivere programmi usa e getta.
Sapete cosa significa un programma usa e getta: è quando è necessario risolvere rapidamente un compito limitato. Credo che, se guardate in giro, troverete molti programmi seri che sono iniziati come programmi usa e getta. Non sarei sorpreso se la maggior parte dei programmi fosse iniziata come usa e getta. Pertanto, se volete creare un linguaggio che sia adatto per scrivere software in generale, deve essere adatto anche per scrivere programmi usa e getta, poiché questo è lo stadio iniziale di molti programmi.
5. La sintassi è legata alla semantica
Tradizionalmente si ritiene che sintassi e semantica siano concetti molto diversi. Potrebbe suonare scioccante, ma non è così. Penso che ciò che volete ottenere nel vostro programma sia legato a come lo esprimete.
Recentemente ho parlato con Robert Morris, e lui ha notato che il sovraccarico degli operatori è un grande vantaggio nell'affermazione delle lingue con sintassi infissa. Nelle lingue con sintassi prefissa, ogni funzione che definisci è in effetti un operatore. Se desideri sommare un nuovo tipo di numero che hai inventato, puoi semplicemente definire una nuova funzione per aggiungerlo. Se fai così in una lingua con sintassi infissa, noterai che c'è una grande differenza tra l'uso di un operatore sovraccaricato e la chiamata di una funzione.
Idee che ritornano nel tempo
1. Nuove lingue di programmazione
Riflettendo sugli anni '70, era di moda sviluppare nuove lingue di programmazione. Ora non è più così. Ma credo che il software server riporterà di moda la creazione di nuove lingue. Con il software server puoi utilizzare qualsiasi lingua tu desideri, quindi se qualcuno crea una lingua che sembra migliore delle altre, ci saranno persone pronte a usarla.
2. Separazione del tempo
Richard Kelsey ha proposto questa idea, il cui momento è tornato, e la supporto pienamente. La mia ipotesi (e anche quella di Microsoft) è che molti calcoli si sposteranno dai desktop ai server remoti. In altre parole, la divisione del tempo è tornata. Penso che servirà un supporto per questo a livello linguistico. Ad esempio, Richard e Jonathan Reeves 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 di più ascoltiamo parlare di bytecode, il che per me significa che abbiamo potenza di riserva. Ma penso che con il software server, non ne abbiamo. Qualcuno dovrà pagare per server, su cui il software opera, e il numero di utenti che il server può gestire per ogni macchina sarà un divisore dei loro costi di capitale.
Penso che l'efficienza avrà importanza, almeno nei punti critici dei calcoli. Questo sarà particolarmente rilevante per le operazioni di input-output, poiché le applicazioni server eseguono un gran numero di tali operazioni.
Alla fine, potrebbe rivelarsi che il bytecode non sia la soluzione. Sun e Microsoft sembrano attualmente combattere faccia a faccia nel campo del bytecode. Ma lo fanno perché il bytecode è un luogo comodo per integrarsi nel processo, non perché il bytecode stesso sia una buona idea. Potrebbe anche succedere che tutta questa battaglia passi inosservata. Sarebbe divertente.
Trappole e insidie
1. Clienti
È solo un'ipotesi, ma si presume che vinceranno solo le applicazioni che saranno completamente server-side. Progettare software con l'assunzione che ciascuno avrà il proprio client è come costruire una società basata sull'assunzione che tutti saranno onesti. Sarebbe sicuramente comodo, ma bisogna ammettere che ciò non accadrà mai.
Penso che ci sarà una rapida crescita dei dispositivi con accesso al web, e si può supporre che supporteranno HTML di base e moduli. Hai un browser sul tuo telefono? Sarà il tuo telefono nel tuo PalmPilot? Il tuo BlackBerry avrà uno schermo più grande? Avrai la possibilità di collegarti a Internet con il tuo Game Boy? 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 questa sia un'affermazione controversa, ma non considero l'OOP qualcosa di importante. Penso che sia una parvenza di paradigma adatta per applicazioni specifiche che necessitano di strutture dati specifiche, come i sistemi a finestre, le simulazioni e i CAD. Ma non capisco perché debba essere adatta a tutti i programmi.
Penso che le persone nelle grandi aziende amano l'OOP, in parte perché fornisce molto di ciò che sembra lavoro. Ciò che naturalmente potrebbe essere rappresentato come, diciamo, un elenco di numeri interi, ora può essere rappresentato come una classe con tutti i tipi di impalcature, con rumore e confusione.
Un altro aspetto interessante della programmazione orientata agli oggetti è che i metodi offrono un effetto simile alle funzioni di primo livello. Ma questo non è una novità per i programmatori che usano Lisp. Quando hai vere funzioni di primo livello, puoi usarle in qualsiasi modo che soddisfi il compito, invece di dover forzare tutto in uno schema di classi e metodi.
Penso che questo significhi, per il design del linguaggio, che non dovresti integrare la programmazione orientata agli oggetti in modo troppo profondo. Potrebbe esserci una risposta nel proporre elementi più generali e fondamentali, e permettere alle persone di progettare sistemi oggetti come librerie.
3. Progettazione da parte di un comitato
Se il tuo linguaggio è progettato da un comitato, sei in una trappola, e non solo per ragioni note. È ben noto che i comitati tendono a creare un design del linguaggio frammentato e incoerente. Ma credo che il rischio maggiore sia che non si prendano responsabilità. Quando c'è una sola persona al comando, essa si assume i rischi che un comitato non sarebbe mai disposto a prendere.
È necessario rischiare per creare un buon linguaggio? Molte persone potrebbero sospettare che progettare un linguaggio sia qualcosa in cui si debba rimanere piuttosto vicini alla saggezza tradizionale. Posso sostenere che non è così. In tutte le altre attività umane, la ricompensa è proporzionale al rischio. Perché quindi dovrebbe essere diverso nella progettazione dei linguaggi?
Fonte: habr.com
