Filosofia guida
1. Linguaggi di programmazione per le persone
I linguaggi di programmazione sono il modo in cui le persone parlano ai computer. Il computer sarà felice di parlare qualsiasi lingua che non sia ambigua. Il motivo per cui disponiamo di linguaggi di alto livello è perché le persone non sono in grado di gestire il linguaggio macchina. Lo scopo dei linguaggi di programmazione è evitare che il nostro povero e fragile cervello umano venga sopraffatto da troppi dettagli.
Gli architetti sanno che alcuni problemi di progettazione sono più banali di altri. Alcuni dei problemi di progettazione più chiari e astratti riguardano la progettazione dei ponti. In questo caso, il tuo compito è coprire la distanza richiesta con la minor quantità di materiale possibile. All’estremità opposta dello spettro c’è il design della sedia. I designer di sedie dovrebbero dedicare il loro tempo a pensare al fondoschiena delle persone.
Lo sviluppo del software ha una differenza simile. Progettare algoritmi per instradare i dati attraverso una rete è un problema simpatico e astratto, come progettare ponti. Invece progettare linguaggi di programmazione è come progettare sedie: bisogna fare i conti con le debolezze umane.
Questo è difficile da realizzare per la maggior parte di noi. Progettare sistemi matematici eleganti sembra molto più attraente per la maggior parte di noi che assecondare le debolezze umane. Il ruolo dell'eleganza matematica è che un certo grado di eleganza rende i programmi più facili da comprendere. Ma non è solo una questione di eleganza.
E quando dico che i linguaggi dovrebbero essere progettati per accogliere le debolezze umane, non intendo dire che i linguaggi dovrebbero essere progettati per cattivi programmatori. In realtà, dovresti progettare software per i migliori programmatori, ma anche i migliori programmatori hanno i loro limiti. Non penso che a nessuno piacerebbe programmare in un linguaggio in cui tutte le variabili erano indicate dalla lettera "x" con pedici interi.
2. Progetta per te e i tuoi amici
Se si guarda alla storia dei linguaggi di programmazione, la maggior parte dei migliori linguaggi sono stati progettati per essere utilizzati dai propri autori, e la maggior parte dei peggiori sono stati progettati per essere utilizzati da altre persone.
Quando le lingue sono progettate per altre persone, si tratta sempre di un gruppo specifico di persone: le persone non sono intelligenti come i creatori della lingua. È così che ottieni una lingua che ti parla dall'alto in basso. Il cobol ne è l’esempio più eclatante, ma la maggior parte delle lingue è permeata di questo spirito.
Non ha nulla a che fare con il livello elevato della lingua. C è di livello piuttosto basso, ma è stato creato per essere utilizzato dai suoi autori, motivo per cui gli hacker lo adorano.
L’argomento a favore della progettazione di linguaggi per cattivi programmatori è che ci sono più programmatori cattivi che buoni. Forse è così. Ma questo piccolo numero di bravi programmatori scrive una quantità sproporzionatamente maggiore di software.
La mia domanda è: come si crea un linguaggio che piaccia ai migliori hacker? Mi sembra che questa domanda sia identica alla domanda su come creare un buon linguaggio di programmazione?, ma anche se non lo è, è almeno una domanda interessante.
3. Concedere al programmatore il massimo controllo possibile
Molte lingue (soprattutto quelle pensate per altre persone) si comportano come tate: cercano di metterti in guardia da cose che pensano non ti saranno utili. Io sono d'accordo con il punto di vista opposto: dai al programmatore il massimo controllo possibile.
Quando ho imparato il Lisp per la prima volta, quello che mi è piaciuto di più è stato il fatto che parlassimo da pari a pari. Nelle altre lingue che avevo imparato a quel punto, c'era una lingua, e c'era il mio programma in quella lingua, ed esistevano in modo abbastanza separato. Ma in Lisp le funzioni e le macro che ho scritto erano le stesse in cui è stato scritto il linguaggio stesso. Potrei riscrivere la lingua stessa se volessi. Aveva lo stesso fascino del software open source.
4. La brevità è la sorella del talento
La brevità è sottovalutata e perfino disprezzata. Ma se guardi nel cuore degli hacker, vedrai che a loro piace davvero la brevità. Quante volte avete sentito gli hacker parlare con affetto di come, ad esempio, in APL, possono fare cose straordinarie con solo un paio di righe di codice? Immagino che alle persone davvero intelligenti piaccia prestare attenzione a questo.
Credo che quasi tutto ciò che rende i programmi più brevi sia una buona cosa. Dovrebbero esserci molte funzioni di libreria, tutto ciò che può essere implicito dovrebbe esserlo; la sintassi dovrebbe essere più concisa; anche i nomi delle entità dovrebbero essere brevi.
E non solo i programmi dovrebbero essere brevi. Anche i manuali dovrebbero essere brevi. Buona parte dei manuali è ricca di spiegazioni, disclaimer, avvertenze e casi particolari. Se è necessario abbreviare il manuale, l'opzione migliore è correggere il linguaggio che richiede così tante spiegazioni.
5. Riconoscere cos'è l'hacking
Molte persone vorrebbero che l'hacking fosse matematica, o almeno qualcosa di simile alla scienza. Penso che l'hacking sia più simile all'architettura. L'architettura riguarda la fisica nel senso che un architetto deve progettare un edificio che non crolli, ma il vero obiettivo di un architetto è creare un grande edificio, non fare scoperte nel campo della statica.
Ciò che gli hacker amano è creare ottimi programmi. E penso che, almeno nei nostri pensieri, dovremmo ricordare che scrivere ottimi programmi è una cosa meravigliosa, anche quando quel lavoro non si traduce facilmente nella consueta valuta intellettuale degli articoli scientifici. Da un punto di vista intellettuale, progettare un linguaggio che i programmatori ameranno è altrettanto importante quanto progettarne uno terribile che incarni un'idea sulla quale si possa pubblicare un articolo.
Questioni aperte
1. Come organizzare le grandi biblioteche?
Le biblioteche stanno diventando una parte importante dei linguaggi di programmazione. Diventano così grandi che possono essere pericolosi. Se ci vuole più tempo per trovare una funzione in una libreria che faccia quello che ti serve piuttosto che scriverla tu stesso, allora tutto il codice non fa altro che rendere il tuo manuale più corposo. (I manuali Symbolics ne sono un esempio.) Quindi dovremo risolvere il problema dell'organizzazione della biblioteca. Idealmente, progettarli in modo che il programmatore possa indovinare quale funzione di libreria è adatta.
2. Le persone hanno davvero paura della sintassi del prefisso?
Questo è un problema aperto nel senso che ci penso da diversi anni e ancora non conosco la risposta. La sintassi del prefisso mi sembra del tutto naturale, tranne forse per il suo uso in matematica. Ma può darsi che gran parte dell'impopolarità del Lisp sia semplicemente dovuta alla sintassi non familiare... Se dovremmo 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 risiederanno su un server e comunicheranno con te attraverso un browser web. E per scrivere tali applicazioni abbiamo bisogno di cose nuove.
Una di queste cose è il supporto per un nuovo modo di rilasciare le applicazioni server. Invece di uno o due grandi rilasci all'anno, come il software desktop, il software server verrà rilasciato con una serie di piccole modifiche. Potresti avere cinque o dieci uscite al giorno. E tutti avranno sempre la versione più recente.
Sai come progettare programmi affinché siano manutenibili? Il software del server deve essere progettato per essere modificabile. Dovresti essere in grado di cambiarlo facilmente, o almeno sapere cosa significa un cambiamento minore e cosa è importante.
Un'altra cosa che può essere utile nel software server è, improvvisamente, la continuità di consegna. In un'applicazione web puoi usare qualcosa di simile per ottenere l’effetto della routine nel mondo apolide delle sessioni web. Può valere la pena avere continuità di fornitura se la funzionalità non è troppo costosa.
4. Quali nuove astrazioni restano da scoprire?
Non sono sicuro di quanto sia ragionevole questa speranza, ma personalmente mi piacerebbe davvero scoprire una nuova astrazione, qualcosa che potrebbe essere significativo quanto le funzioni di prima classe o la ricorsione o almeno i parametri predefiniti. Forse questo è un sogno impossibile. Spesso queste cose non vengono scoperte. Ma non perdo la speranza.
Segreti poco conosciuti
1. Puoi utilizzare qualsiasi lingua desideri
In precedenza, la creazione di applicazioni significava la creazione di software desktop. E nel software desktop c'è una grande propensione a scrivere applicazioni nella stessa lingua del sistema operativo. Quindi dieci anni fa, scrivere software in generale significava scrivere software in C. Alla fine, la tradizione si è evoluta: le applicazioni non dovrebbero essere scritte in linguaggi insoliti. E questa tradizione si è evoluta per così tanto tempo che anche persone non tecniche come manager e venture capitalist l’hanno imparata.
Il software del server distrugge completamente questo modello. Con il software server puoi utilizzare qualsiasi lingua desideri. Quasi nessuno lo capisce ancora (soprattutto manager e venture capitalist). Ma alcuni hacker lo capiscono, motivo per cui sentiamo parlare di linguaggi indy come Perl e Python. Non sentiamo parlare di Perl e Python perché le persone li usano per scrivere applicazioni Windows.
Cosa significa questo per noi, persone interessate alla progettazione del linguaggio di programmazione, che esiste un pubblico potenziale per il nostro lavoro.
2. La velocità viene dai profiler
Agli sviluppatori di linguaggi, o almeno agli implementatori di linguaggi, piace scrivere compilatori che generano codice veloce. Ma penso che non sia questo a rendere le lingue veloci per gli utenti. Knuth ha notato molto tempo fa che la velocità dipende solo da alcuni colli di bottiglia. E chiunque abbia provato ad accelerare un programma sa che non è possibile indovinare dove sia il collo di bottiglia. Profiler è la risposta.
Gli sviluppatori del linguaggio stanno risolvendo il problema sbagliato. Gli utenti non hanno bisogno di benchmark per funzionare velocemente. Hanno bisogno di un linguaggio in grado di mostrare quali parti del loro programma devono essere riscritte. A questo punto serve velocità nella pratica. Quindi forse sarebbe meglio se gli implementatori del linguaggio dedicassero metà del tempo che impiegano a ottimizzare il compilatore e lo dedicassero alla scrittura di un buon profiler.
3. Hai bisogno di un'app che faccia evolvere la tua lingua
Questa potrebbe non essere la verità ultima, ma sembra che i migliori linguaggi si siano evoluti insieme alle applicazioni in cui venivano utilizzati. C è stato scritto da persone che avevano bisogno di programmazione di sistema. Il Lisp è stato progettato in parte per la differenziazione simbolica e McCarthy era così ansioso di iniziare che iniziò persino a scrivere programmi di differenziazione nel primo articolo sul Lisp nel 1960.
Ciò è particolarmente utile se la tua applicazione risolve alcuni nuovi problemi. Ciò spinge il tuo linguaggio ad avere nuove funzionalità desiderate dai programmatori. Personalmente, sono interessato a scrivere un linguaggio che sia utile per le applicazioni server.
[Durante la discussione, anche Guy Steele ha sottolineato questo punto, aggiungendo che l'applicazione non dovrebbe consistere nello scrivere un compilatore per il proprio linguaggio, a meno che il proprio linguaggio non sia progettato per scrivere compilatori.]4. Il linguaggio deve essere adatto alla scrittura di programmi unici.
Sai cosa significa un programma one-shot: è quando devi risolvere rapidamente qualche problema limitato. Credo che se ti guardi intorno, troverai molti programmi seri che sono iniziati come una tantum. Non sarei sorpreso se la maggior parte dei programmi iniziassero come una tantum. Quindi, se vuoi creare un linguaggio che sia adatto alla scrittura di software in generale, allora dovrebbe essere adatto anche alla scrittura di programmi una tantum, perché questa è la fase iniziale di molti programmi.
5. La sintassi è correlata alla semantica
Si ritiene tradizionalmente che la sintassi e la semantica siano cose molto diverse. Questo può sembrare scioccante, ma non lo è. Penso che ciò che vuoi ottenere nel tuo programma abbia a che fare con il modo in cui lo esprimi.
Recentemente ho parlato con Robert Morris e ha notato che il sovraccarico degli operatori è un grande vantaggio per la vittoria dei linguaggi con sintassi infissa. Nelle lingue con sintassi del prefisso, qualsiasi funzione definita è in realtà un operatore. Se vuoi aggiungere un nuovo tipo di numero che hai creato, puoi semplicemente definire una nuova funzione per aggiungerlo. Se lo fai in un linguaggio con sintassi infissa, vedrai che c'è una grande differenza tra l'utilizzo di un operatore sovraccaricato e la chiamata di una funzione.
Idee che ritornano nel tempo
1. Nuovi linguaggi di programmazione
Guardando indietro agli anni ’1970, era di moda sviluppare nuovi linguaggi di programmazione. Adesso non è più così. Ma credo che il software server riporterà nuovamente la moda per la creazione di nuovi linguaggi. Con il software server puoi usare qualsiasi lingua tu voglia, quindi se qualcuno crea una lingua che sembra migliore delle altre, ci saranno persone che decideranno di usarla.
2. Condivisione del tempo
Richard Kelsey ha avuto questa idea il cui momento è giunto di nuovo e la sostengo pienamente. La mia ipotesi (e anche quella di Microsoft) è che gran parte dell'elaborazione si sposterà dal desktop ai server remoti. In altre parole, il time sharing è tornato. Penso che questo avrà bisogno di supporto a livello linguistico. Ad esempio, Richard e Jonathan Reeves hanno lavorato molto per implementare la pianificazione dei processi nello Schema 48.
3. Efficienza
Recentemente sembrava che i computer fossero già abbastanza veloci. Si sente parlare sempre più spesso di bytecode, il che, almeno per me, significa che abbiamo un po' di energia di riserva. Ma penso che con il software server non ce l’abbiamo. Qualcuno dovrà pagare per i server che eseguono il software e il numero di utenti che il server può supportare per macchina sarà un divisore dei costi di capitale.
Penso che l’efficienza avrà importanza, almeno per quanto riguarda i colli di bottiglia informatici. Ciò sarà particolarmente importante per le operazioni di I/O, poiché le applicazioni server eseguono molte di queste operazioni.
Alla fine, potrebbe risultare che il bytecode non è la risposta. Sun e Microsoft sembrano attualmente scontrarsi nel campo del bytecode. Ma lo fanno perché il bytecode è un posto conveniente per incorporarsi in un processo, non perché il bytecode stesso sia una buona idea. Potrebbe succedere che l'intera battaglia passerà inosservata. Sarebbe divertente.
Lacci e lacci
1. Clienti
Questa è solo un'ipotesi, ma le uniche applicazioni che ne trarranno vantaggio saranno quelle completamente lato server. Progettare software che operi partendo dal presupposto che tutti avranno un cliente è come progettare una società basata sul presupposto che tutti saranno onesti. Sarebbe sicuramente conveniente, ma bisogna dare per scontato che non accadrà mai.
Penso che ci sarà un rapido aumento dei dispositivi abilitati al web e possiamo presumere che supporteranno HTML e moduli di base. Hai un browser sul tuo telefono? Il tuo PalmPilot avrà un telefono? Il tuo BlackBerry avrà uno schermo più grande? Sarai in grado di accedere a Internet dal tuo Gameboy? Dal tuo orologio? Non lo so. E non dovrò scoprirlo se scommetto che sarà tutto sul server. È semplicemente molto più affidabile avere tutti i cervelli sul server. .
2. Programmazione orientata agli oggetti
Mi rendo conto che si tratta di un'affermazione controversa, ma non credo che l'OOP sia così importante. Penso che questo sia un paradigma adatto per applicazioni specifiche che necessitano di strutture dati specifiche, come sistemi a finestre, simulazioni, sistemi CAD. Ma non capisco perché dovrebbe essere adatto a tutti i programmi.
Penso che le persone nelle grandi aziende adorino l'OOP, in parte, perché rende molte cose che sembrano lavoro. Ciò che potrebbe essere naturalmente rappresentato, ad esempio, come una lista di numeri interi, ora può essere rappresentato come un'aula con ogni sorta di impalcature e trambusto.
Un'altra caratteristica interessante dell'OOP è che i metodi forniscono parte dell'effetto delle funzioni di prima classe. Ma questa non è una novità per i programmatori Lisp. Quando disponi di vere funzioni di prima classe, puoi semplicemente usarle nel modo più adatto al compito da svolgere, invece di inserire tutto in un boilerplate di classi e metodi.
Penso che ciò significhi per la progettazione del linguaggio è che non dovresti incorporare l'OOP troppo profondamente in esso. Forse la risposta è offrire cose più generali e fondamentali e consentire alle persone di progettare qualsiasi sistema di oggetti come librerie.
3. Progettazione da parte del comitato
Se il tuo linguaggio è progettato da un comitato, allora sei in trappola, e non solo per ragioni che tutti conoscono. Tutti sanno che i comitati tendono a creare progetti linguistici grumosi e incoerenti. Ma penso che il pericolo più grande sia che non si prendano rischi. Quando una persona è al comando, corre dei rischi che il comitato non accetterebbe mai di assumersi.
È necessario correre dei rischi per creare un buon linguaggio? Molte persone potrebbero sospettare che nella progettazione del linguaggio sia necessario restare molto vicini alla saggezza tradizionale. Scommetto che non è così. In tutto il resto, la ricompensa è proporzionale al rischio. Allora perché la progettazione del linguaggio dovrebbe essere diversa?
Fonte: habr.com