Da un po 'di tempo mi interesso molto alla programmazione della teoria del linguaggio e ai calcoli di processo e ho iniziato a studiarli. Ad essere sincero, è qualcosa che non mi dispiacerebbe fare carriera. Trovo che la teoria sia incredibilmente affascinante. Una domanda costante in cui continuo a rispondere è se la teoria PL o i calcoli di processo hanno alcuna importanza nello sviluppo del linguaggio di programmazione moderno. Vedo così tante varianti sul Pi-calcolo là fuori e c'è molta ricerca attiva, ma saranno mai necessarie o avranno applicazioni importanti? Il motivo per cui lo chiedo è perché amo sviluppare linguaggi di programmazione e il vero obiettivo finale sarebbe usare la teoria per costruire effettivamente un PL. Per il materiale che ho scritto, non c'è stata alcuna correlazione con la teoria.
Utilizzo dei calcoli di processo e della teoria PL per lo sviluppo del linguaggio di programmazione moderno
Risposte:
La mia risposta è davvero solo un'elaborazione di Gilles, che non avevo letto prima di aver scritto la mia. Forse è comunque utile.
Vorrei iniziare il mio tentativo di rispondere alla tua domanda con una distinzione tra due dimensioni del lavoro dei linguaggi di programmazione che si relazionano in modo molto diverso alla teoria del linguaggio di programmazione in generale e al calcolo del processo in particolare.
Pura ricerca.
Ricerca e sviluppo incentrati sul prodotto.
Quest'ultimo si svolge in genere nell'industria con l'obiettivo di fornire linguaggi di programmazione come prodotto. I team che sviluppano Java presso Oracle e C # presso Microsoft ne sono esempi. Al contrario, la ricerca pura non è legata ai prodotti. Il suo scopo è comprendere i linguaggi di programmazione come oggetti di interesse intrinseco ed esplorare le strutture matematiche alla base di tutti i linguaggi di programmazione.
A causa di obiettivi divergenti, diversi aspetti della teoria del linguaggio di programmazione sono rilevanti nella ricerca pura e nella ricerca e sviluppo incentrata sul prodotto. L'immagine sotto può dare un'indicazione di ciò che è importante dove.
A questo punto ci si può chiedere perché le due dimensioni siano così apparentemente diverse e come si colleghino comunque.
L'intuizione chiave è che la ricerca e lo sviluppo del linguaggio di programmazione ha molteplici dimensioni: tecnica, sociale ed economica. Quasi per definizione, l'industria è interessata al payoff economico dei linguaggi di programmazione. Microsoft e altri non sviluppano i linguaggi per la bontà dei loro cuori ma perché credono che i linguaggi di programmazione offrano loro un vantaggio economico. E hanno studiato a fondo perché alcuni linguaggi di programmazione hanno successo e altri, apparentemente simili o con funzionalità più avanzate, non lo fanno. E hanno scoperto che non esiste un unico motivo. I linguaggi di programmazione e i loro ambienti sono complessi, così come i motivi per l'adozione o l'ignoranza di qualsiasi linguaggio specifico. Ma il singolo principale fattore per il successo di un linguaggio di programmazione è l'attaccamento preferenziale dei programmatori a linguaggi già ampiamente utilizzati: più persone usano una lingua, più sono disponibili librerie, strumenti, materiale didattico e più produttivo è un programmatore può usare quella lingua. Questo è anche chiamato effetto di rete. Un'altra ragione è l'elevato costo che cambia le lingue per individui e organizzazioni: padroneggiare la lingua, specialmente per un programmatore non così esperto, e quando la distanza semantica per le lingue familiari è grande, è uno sforzo serio e che richiede tempo. Alla luce di questi fatti, ci si potrebbe chiedere perché le nuove lingue ottengono trazione? Perché le aziende sviluppano nuove lingue? Perché non restiamo solo con Java o Cobol? Penso che ci siano diverse ragioni chiave per cui una lingua ha successo,
Si apre un nuovo dominio di programmazione che non ha incumbent da spostare. L'esempio principale è il web con il concomitante aumento di Javascript.
Appiccicosità del linguaggio. Con questo intendo l'alto prezzo del cambio di lingua. Ma a volte i programmatori si spostano in campi diversi, portando con sé un linguaggio di programmazione e avendo successo con il vecchio linguaggio nel nuovo campo.
Una lingua è spinta da una grande azienda con una seria potenza di fuoco finanziaria. Questo supporto riduce il rischio di adozione, poiché i primi utenti possono essere ragionevolmente sicuri che la lingua sarà ancora supportata tra qualche anno. Un buon esempio di ciò è C #.
Una lingua potrebbe venire con strumenti convincenti ed ecosistema. Anche in questo caso C # e il suo ecosistema .Net e Visual Studio potrebbero essere citati come esempio.
Le vecchie lingue acquisiscono nuove funzionalità. Viene in mente Java, che, in ogni iterazione, raccoglie più buone idee dalla tradizione di programmazione funzionale.
Infine, un nuovo linguaggio potrebbe avere vantaggi tecnici intrinseci, ad esempio essere più espressivo, avere una sintassi migliore, sistemi di battitura che rilevano più errori, ecc.
Alla luce di ciò, non dovrebbe sorprendere che ci sia un po 'di disconnessione tra la pura ricerca del linguaggio di programmazione e lo sviluppo del linguaggio di programmazione commerciale. Mentre entrambi mirano a rendere la costruzione e l'evoluzione del software più efficienti, in particolare per i software su larga scala, il lavoro sul linguaggio di programmazione industriale deve essere più interessato a facilitare l'adozione rapida per raggiungere una massa critica e ottenere l'effetto della rete. Ciò porta ad un focus di ricerca sulle cose che interessano ai programmatori che lavorano. E questo tende ad essere cose come la disponibilità della libreria, la velocità del compilatore, la qualità del codice compilato, la portabilità e così via. Il calcolo del processo come lo pratichiamo oggi è di scarsa utilità per i programmatori che lavorano su progetti tradizionali (anche se credo che cambierà in futuro).
-riduzione per programmazione funzionale, risoluzione / unificazione per programmazione logica, passaggio di nomi per calcolo simultaneo). Per capire se una lingua come Scala può avere un'inferenza di tipo completa praticabile, non dobbiamo preoccuparci della JVM. In effetti, pensare alla JVM toglierà una migliore comprensione dell'inferenza del tipo. Ecco perché l'astrazione del calcolo in piccoli calcoli core è vitale e potente.
Quindi puoi pensare alla programmazione del linguaggio di ricerca come un enorme sandbox in cui le persone giocano con i giocattoli e se trovano qualcosa di interessante quando giocano con un giocattolo specifico e hanno studiato a fondo il giocattolo, allora quel giocattolo interessante inizia la sua lunga marcia verso l'accettazione industriale tradizionale . Dico lunga marcia perché le caratteristiche del linguaggio inventate per la prima volta dai ricercatori del linguaggio di programmazione tendono a richiedere decenni prima di essere ampiamente accettate. Ad esempio, la raccolta dei rifiuti è stata concepita negli anni '50 e divenne ampiamente disponibile con Java negli anni '90. La corrispondenza del modello risale al 1970 ed è ampiamente utilizzata solo dalla Scala.
Il calcolo del processo è un giocattolo particolarmente interessante. Ma è troppo nuovo per essere studiato a fondo. Ci vorrà un altro decennio di pura ricerca. Ciò che sta attualmente accadendo nella ricerca sulla teoria dei processi è quello di prendere la più grande storia di successo della ricerca nel linguaggio di programmazione, la teoria dei tipi (sequenziali) e sviluppare la teoria dei tipi per la concorrenza che passa messaggi. I sistemi di tipizzazione di moderata espressività per la programmazione sequenziale, affermano Hindley-Milner, sono ora ben compresi, onnipresenti e accettati dai programmatori che lavorano. Vorremmo avere tipi moderatamente espressivi per la programmazione concorrente. La ricerca iniziò negli anni '80 da pionieri come Milner, Sangiorgi, Turner, Kobayashi, Honda e altri, spesso basati, esplicitamente o implicitamente, sull'idea di linearità che deriva dalla logica lineare. Gli ultimi anni hanno visto un notevole aumento dell'attività e mi aspetto che questa traiettoria ascendente continui per il prossimo futuro. Mi aspetto anche che questo lavoro inizi a infiltrarsi nella ricerca e sviluppo incentrata sul prodotto, in parte per la ragione pragmatica che i giovani ricercatori che sono stati formati nel calcolo dei processi andranno a lavorare nei laboratori di ricerca e sviluppo industriali, ma anche a causa dell'evoluzione della CPU e dell'architettura del computer via da forme sequenziali di calcolo.
In sintesi, non mi preoccuperei che non trovi utile la teoria del linguaggio di programmazione all'avanguardia come il calcolo del processo nel tuo lavoro di costruzione di linguaggi. Questo semplicemente perché la teoria all'avanguardia non affronta le preoccupazioni degli attuali linguaggi di programmazione. Riguarda le lingue future. Ci vorrà del tempo prima che il "mondo reale" raggiunga. La conoscenza che usi per costruire linguaggi per oggi è la teoria dei linguaggi di programmazione del passato. Ti incoraggio a saperne di più sul calcolo dei processi perché è una delle aree più interessanti di tutta l'informatica teorica.
La scienza della programmazione del linguaggio di programmazione è molto agli inizi. La teoria (lo studio del significato dei programmi e dell'espressività di una lingua) e l'empirismo (ciò che i programmatori gestiscono o non riescono a fare) forniscono molti argomenti qualitativi per valutare in un modo o nell'altro la progettazione di una lingua. Ma raramente abbiamo motivi quantitativi per decidere.
C'è un ritardo tra il momento in cui una teoria si stabilizza abbastanza da consentire a un'innovazione di essere utilizzabile in un linguaggio di programmazione pratico e il momento in cui questa innovazione inizia ad apparire in linguaggi "mainstream". Ad esempio, si può dire che la gestione automatica della memoria con Garbage Collection sia stata maturata per uso industriale a metà degli anni '60, ma abbia raggiunto il mainstream con Java solo nel 1995. Il polimorfismo parametrico era ben compreso alla fine degli anni '70, e lo fece in Java verso la metà del 200. Sulla scala della carriera di un ricercatore, 30 anni sono tanti.
L'adozione industriale su larga scala di una lingua è una questione che i sociologi devono studiare e che la scienza è ancora di più nella sua infanzia. Le considerazioni di mercato sono un fattore importante: se Sun, Microsoft o Apple spingono una lingua, ciò ha un impatto molto maggiore rispetto a qualsiasi numero di documenti POPL e PLDI. Anche per un programmatore che ha una scelta, la disponibilità delle biblioteche di solito è molto più importante della progettazione del linguaggio. Il che non vuol dire che il design del linguaggio non sia importante: avere un linguaggio ben progettato è un sollievo! Di solito non è il fattore decisivo.
I calcoli di processo sono ancora allo stadio in cui la teoria non si è stabilizzata. Crediamo di comprendere i calcoli sequenziali: tutti i modelli di cose che ci piace chiamare il calcolo sequenziale sono equivalenti (questa è la tesi di Church-Turing). Questo non vale per la concorrenza: diversi calcoli di processo tendono ad avere sottili differenze nell'espressività.
I calcoli di processo hanno implicazioni pratiche. Un sacco di calcoli là fuori sono distribuiti - coinvolgono client che parlano con server, server che parlano con altri server, ecc. Anche i calcoli locali sono molto spesso multithread per sfruttare il parallelismo su più processori e reagire alla concorrenza ambientale (comunicazione con programmi indipendenti e con l'utente).
Sono necessari progressi nella ricerca per realizzare un software migliore? Dopotutto c'è un'industria da miliardi di dollari là fuori che non sa distinguere il calcolo da una torta nel cielo. Ancora una volta, quell'industria spende miliardi di dollari per correggere bug.
"Saranno mai necessari" non è mai una domanda utile nella ricerca. È impossibile prevedere in anticipo quali saranno le conseguenze a lungo termine. Vorrei anche andare oltre e dire che è un presupposto sicuro che qualsiasi ricerca avrà conseguenze un giorno - semplicemente non sappiamo al momento se quel giorno arriverà il prossimo anno o il prossimo millennio.
Vedo così tante varianti sul Pi-calcolo là fuori e c'è molta ricerca attiva, ma saranno mai necessarie o avranno applicazioni importanti?
Il motivo per cui lo chiedo è perché amo sviluppare linguaggi di programmazione e il vero obiettivo finale sarebbe usare la teoria per costruire effettivamente un PL. Per il materiale che ho scritto, non c'è stata alcuna correlazione con la teoria.
Questa è una domanda difficile! Ti dirò la mia opinione personale e sottolineo che questa è la mia opinione .
Non credo che pi-calculus sia direttamente adatto come notazione per la programmazione concorrente. Tuttavia, penso che dovresti assolutamente studiarlo prima di progettare un linguaggio di programmazione concorrente. Il motivo è che pi-calculus fornisce un livello basso --- ma, soprattutto, compositivo! --- conto della concorrenza. Di conseguenza, può esprimere tutto ciò che desideri, ma non sempre in modo conveniente.
Spiegare questo commento richiede di pensare un po 'ai tipi. In primo luogo, i linguaggi di programmazione utili in genere necessitano di un qualche tipo di disciplina per costruire astrazioni. In particolare, è necessario un tipo di tipo di funzione per utilizzare le astrazioni procedurali durante la creazione di software.
Ora, la disciplina di tipo naturale del pi-calcolo è una variante della logica lineare classica. Vedi, ad esempio, il documento Realizzabilità del processo di Abramsky , che mostra come interpreti i semplici programmi concorrenti come prove di proposizioni dalla logica lineare. (La letteratura contiene molto lavoro sui tipi di sessione per la digitazione di programmi pi-calculus, ma tipi di sessione e tipi lineari sono strettamente correlati.)
Questo va bene dalla teoria dei tipi POV, ma è imbarazzante durante la programmazione. Il motivo è che i programmatori finiscono per gestire non solo le loro chiamate di funzione, ma anche lo stack di chiamate. (In effetti, le codifiche del calcolo lambda nel calcolo pi in genere finiscono per sembrare trasformazioni CPS.) Ora, la digitazione assicura che non rovineranno mai questo, ma tuttavia è un sacco di contabilità messa in discussione sul programmatore.
Questo non è un problema unico della teoria della concorrenza: il mu-calculus fornisce un buon resoconto teorico delle prove degli operatori di controllo sequenziale come call / cc, ma al prezzo di rendere esplicito lo stack, il che lo rende un linguaggio di programmazione scomodo.
Quindi, quando si progetta un linguaggio di programmazione concorrente, la mia opinione è che dovresti progettare il tuo linguaggio con astrazioni di livello superiore rispetto al pi-calcolo grezzo, ma dovresti assicurarti che sia tradotto in modo chiaro in un calcolo di processo tipizzato sensato. (Un bell'esempio recente di ciò sono i processi, le funzioni e le sessioni di ordine superiore di Tonhino, Caires e Pfenning: un'integrazione monadica .)
Dici che "il vero obiettivo finale sarebbe usare la teoria per costruire effettivamente un PL". Quindi, presumibilmente, ammetti che ci sono altri obiettivi?
Dal mio punto di vista, lo scopo n. 1 della teoria è quello di fornire comprensione, che può essere nel ragionamento sui linguaggi di programmazione esistenti e sui programmi in essi scritti. Nel mio tempo libero, mantengo un grosso software, un client di posta elettronica, scritto anni fa in Lisp. Tutta la teoria PL che conosco come la logica Hoare, la logica di separazione, l'astrazione dei dati, la parametricità relazionale e l'equivalenza contestuale ecc. È utile nel lavoro quotidiano. Ad esempio, se sto estendendo il software con una nuova funzionalità, so che deve ancora preservare la funzionalità originale, il che significa che dovrebbe comportarsi allo stesso modo in tutti i vecchi contesti anche se farà qualcosa di nuovo in nuovi contesti. Se non sapessi nulla sull'equivalenza contestuale, probabilmente non sarei nemmeno in grado di inquadrare il problema in quel modo.
Venendo alla tua domanda su pi-calculus, penso che pi-calculus sia ancora un po 'troppo nuovo per trovare applicazioni nella progettazione del linguaggio. La pagina di Wikipedia su pi-calculus menziona BPML e occam-pi come disegni di linguaggio usando pi-calculus. Ma potresti anche guardare le pagine del suo predecessore CCS e altri calcoli di processo come CSP, join calculus e altri, che sono stati usati in molti progetti di linguaggi di programmazione. Puoi anche guardare la sezione "Oggetti e pi-calculus" del libro Sangiorgi e Walker per vedere come pi-calculus si collega ai linguaggi di programmazione esistenti.
Mi piace cercare implementazioni pratiche di calcoli di processo in natura :) (oltre a leggere sulla teoria).
- I canali asincroni Clojure si basano su CSP: http://clojure.com/blog/2013/06/28/clojure-core-async-channels.html
- Golang ha anche canali basati su CSP (questo ispirato Rich Hickey per il clojure credo): http://www.informit.com/articles/printerfriendly/1768317
- C'è un ragazzo che ha fatto un'estensione basata su ACP per scala (Subscript) ma non ho abbastanza reputazione per pubblicare il link ...
eccetera.