Ricerca e sfide aperte nella teoria dei linguaggi di programmazione

32

Nello spirito di alcune discussioni generali come questa , sto aprendo questa discussione con l'intenzione di raccogliere opinioni su quali siano le sfide aperte e gli argomenti caldi nella ricerca sui linguaggi di programmazione . Spero che la discussione possa anche far emergere opinioni sul futuro della ricerca nei linguaggi di programmazione.

Credo che questo tipo di discussione aiuterà i nuovi ricercatori studenti, come me, interessati a PL, così come quelli che sono già in qualche modo coinvolti.

pl.programming-languages open-problem research-practice

— bellpeace
fonte

7

wiki della comunità?

— Suresh Venkat,

2

Penso che migliorerebbe davvero questa domanda e chi risponderà se citassi o riassumessi il testo della domanda "Frontiers of TCS". La portata prevista delle risposte a questa domanda non è chiara, mentre l'altra domanda è più precisa su ciò che si aspettava.

— Vijay D,

quando ho fatto questa domanda su StackOverflow qualche tempo fa ... ho ottenuto i voti negativi e la mia domanda è stata chiusa!

— Rorschach,

23

Penso che l'obiettivo generale della teoria PL sia quello di ridurre i costi della programmazione su larga scala migliorando i linguaggi di programmazione e l'ecosistema tecnico in cui vengono utilizzati i linguaggi.

Ecco alcune descrizioni di alto livello, piuttosto vaghe, delle aree di ricerca del PL che hanno ricevuto un'attenzione costante e probabilmente continueranno a farlo per un po '.

La maggior parte della ricerca sui linguaggi di programmazione è stata condotta nel contesto del calcolo sequenziale e ormai siamo probabilmente convergenti su un nucleo di funzionalità disponibili nella maggior parte dei linguaggi di programmazione moderni (ad es. Funzioni di ordine superiore, inferenza di tipo (parziale), corrispondenza dei modelli , ADT, polimorfismo parametrico) e sono ben compresi. Non esiste ancora tale consenso sulle funzioni del linguaggio di programmazione per il calcolo simultaneo e parallelo.
Relativamente al punto precedente, il campo di ricerca dei sistemi di tipizzazione ha visto che gran parte della sua attività riguardava il calcolo sequenziale. Possiamo generalizzare questo lavoro per trovare discipline di battitura trattabili e utili che limitano il calcolo simultaneo e parallelo?
Come caso speciale del punto precedente, la corrispondenza Curry-Howard mette in relazione la teoria della dimostrazione strutturale e la programmazione funzionale, portando a un trasferimento tecnologico sostenuto tra informatica e (basi della) matematica, con ad esempio la teoria del tipo di omotopia come esempio impressionante. Ci sono molti allettanti suggerimenti che possono essere estesi a (alcune forme di) calcolo simultaneo e parallelo.
Le specifiche e la verifica dei programmi sono maturate molto negli ultimi anni, ad esempio con assistenti di correzione interattivi come Isabelle e Coq, ma la tecnologia è ancora lontana dall'essere utilizzabile su larga scala nella programmazione quotidiana. C'è ancora molto lavoro da fare per migliorare questo stato di cose.
Linguaggi di programmazione e tecnologia di verifica per nuove forme di calcolo. Sto
pensando qui in particolare al calcolo quantistico e ai meccanismi computazionali di ispirazione biologica, vedi ad esempio qui .
Unificazione. Esistono molti approcci ai linguaggi di programmazione, ai tipi, alla verifica e talvolta si ritiene che vi sia molta sovrapposizione tra loro e che ci sia un approccio più astratto in attesa di essere scoperto. In particolare, è probabile che i meccanismi computazionali di ispirazione biologica continueranno a sopraffarci.

Un problema della ricerca PL è che non ci sono chiari problemi aperti come la domanda P / NP in cui possiamo immediatamente dire se una soluzione proposta funziona o no.

— Martin Berger
fonte

1

se posso aggiungere, il quantum computing e i linguaggi di programmazione quantistica, anche se il calcolo quantistico non sta accadendo, tuttavia lo studio di come alcuni concetti di programmazione potrebbero essere trasferiti in questo modello di calcolo è interessante se non altro, programmazione in linguaggio naturale, programmazione fuzzy, e persino calcolo fisico e programmazione fisica (programmazione direttamente sulla materia, oltre il livello molecolare)

— Nikos M.

1

@NikosM. Sono d'accordo, il controllo di qualità è un grosso problema e fortemente studiato. Questo documento mostra una sorprendente connessione tra le basi della meccanica quantistica e la teoria del linguaggio di programmazione, portata alla luce solo dall'astrazione.

— Martin Berger,

Bene, forse una domanda potrebbe riguardare questo tipo di relazioni formali (o non formali)

— Nikos M.

11

Vorrei elencare alcune ipotesi che limitano la ricerca nel linguaggio di programmazione. Questi sono difficili da staccare perché si sentono come una parte essenziale dei linguaggi di programmazione o perché esplorare alternative sarebbe "non programmare più la progettazione del linguaggio". Con ogni ipotesi ne elenco gli effetti limitanti.

I programmi sono costrutti sintattici.
- I veri programmatori non userebbero mai gli iPad per costruire il codice sorgente. E anche se lo facessero, non potrebbero mai essere così efficienti come con Emacs, Eclipse, NetBeans, XCode, ecc.
- La ricerca su modi alternativi di costruire programmi non è la programmazione del linguaggio, ma la progettazione grafica dell'interfaccia utente o l'educazione (cfr. Scratch).
Un programma parzialmente scritto non può essere eseguito.
- Per lo meno, si verifica un errore di runtime quando l'esecuzione arriva a una parte mancante.
- A cosa potrebbe servire l'esecuzione di programmi incompiuti?
I programmi riguardano il dare istruzioni ai computer.
- La progettazione del linguaggio di programmazione non ha nulla da dire su come scrivere e organizzare le leggi. apliances.
- I batteri non scrivono programmi.
La programmazione è come l'ingegnerizzazione e non può essere fatta dalla gente comune.
- Le persone comuni non conoscono la sintassi, i concetti, gli strumenti, quindi non possono scrivere programmi.
- Anche se proviamo a rendere possibile per la gente comune scrivere programmi, saranno in grado di scrivere solo cose banali.

Penso che potrei andare avanti.

— Andrej Bauer
fonte

2

James: eccellente, informerò mia zia. Martin: questo è esattamente il genere di cosa di cui sto parlando: la programmazione non testuale non è stata stabilita in modo convincente perché la comunità PL non la sta prendendo sul serio, perché non è stata stabilita in modo convincente. Ma mi sembra abbastanza ovvio che gli umani non sono fatti per scrivere parole sugli schermi. Siamo bravi a lanciare roba e raccogliere mirtilli.

— Andrej Bauer,

1

@AndrejBauer Come argomento scientifico, "È abbastanza ovvio per me" non va oltre il miglioramento. Se osservi la storia dei sistemi di scrittura, di cui i linguaggi di programmazione sono solo un esempio recente, la loro traiettoria storica è stata lontana dalla scrittura logografica. Forse la nostra capacità di analizzare le stringhe è più rilevante dei mirtilli. La scrittura alfabetica si è evoluta nel corso dei millenni, quindi è improbabile che contenga bug enormi e facilmente risolvibili. Detto questo, sono felice di credere che possiamo fare meglio delle stringhe lineari basate su ASCII. Penso che ci vorrà un po 'prima di noi.

— Martin Berger,

1

Il punto della mia risposta è "pensare fuori dagli schemi". Esaminare ipotesi nascoste nella ricerca sul PL e vedere come limitano il potenziale della ricerca sul PL.

— Andrej Bauer,

4

@AndrejBauer, penso che limitare il campo di applicazione a POPL sia un errore: gran parte di questo tipo di lavoro viene svolto presso OOPSLA, ICSE o persino CHI. POPL non è interessato a meno che non ci sia un nuovo approccio formale, ma POPL non è l'intera comunità PL.

— Sam Tobin-Hochstadt,

2

@DominicMulligan: certo, queste sono tutte idee molto gradite. Con i miei commenti sto cercando di cambiare la percezione di cosa sia la programmazione. Quindi, se le idee teoriche possono essere messe a frutto nella pratica (con questo intendo dire che i programmatori "ordinari" le useranno nella vita quotidiana), allora abbiamo vinto.

— Andrej Bauer,

0

C'è un problema che mi chiedevo. Non ho idea se si qualifichi come una sfida aperta.

Le conoscenze matematiche sono cresciute costantemente nel tempo. I fondamenti, i concetti, le notazioni e le prove teorici si sono evoluti nel corso dei secoli. I matematici hanno gestito l'aggregazione senza necessariamente controllare la sua coerenza globale in modo sistematico e formale in qualsiasi momento (anche se ci sono stati tentativi di farlo).

Dovremmo aspettarci che i linguaggi di programmazione e le librerie dei programmi si aggreghino e si evolvano in modo simile nel tempo. Che tipo di strumenti potrebbe aiutare a gestire l'aggregazione dei risultati di programmazione e delle librerie in modo da renderli coerenti ed effettivamente utilizzabili da tutti, poiché i computer possono essere più formali ed esigenti in termini di coerenza. Dobbiamo rifare le librerie per ogni nuovo linguaggio di programmazione. Perché dovremmo scegliere una lingua perché ha le librerie giuste per l'applicazione prevista piuttosto che per le sue qualità intrinseche come mezzo di programmazione?

Su un argomento diverso, potresti trovare idee nella seguente domanda: I linguaggi di programmazione stanno diventando più simili ai linguaggi naturali? Mi rendo conto che l'idea potrebbe non fare appello a molti scienziati informatici teorici, ma può comunque essere utile osservando questioni diverse o da un diverso punto di vista. Sono lungi dall'essere d'accordo con molte delle idee che sono state pubblicate, ma è a questo che serve la discussione.

— Babou
fonte

La coerenza è eccessiva.

— Andrej Bauer,

1

Vedo che non c'è molto accordo su questo, per quanto modesto, suggerimento. Tuttavia, potrebbe essere più utile, almeno per me, avere qualche parola esplicativa sul perché. Nel caso in cui non fossi chiaro, non intendevo mai dire che la matematica potesse essere incoerente, solo che non era (necessariamente) aggregata con mezzi coerenti (gli storici direbbero meglio). Da un punto di vista CS, potrei sbagliarmi riguardo alla difficoltà di aggregazione (non ho mai fatto alcun lavoro tecnico su questo), ma sto solo mettendo in relazione l'esperienza utente e il punto di vista comunemente sentito, dannosamente indiretto ai linguaggi prodotti da TCS.

— babou,

1

Bene, la mia osservazione riguarda principalmente il fatto che la coerenza è un'idea del tutto o niente, mentre in realtà la maggior parte dei software è "per lo più coerente". Eppure lo usiamo e lo troviamo utile. Perché allora i teorici sono ossessionati da ciò che sembra essere un concetto praticamente irraggiungibile e troppo idealistico? Sembrerebbe meglio essere in grado di quantificare la coerenza in un modo meno banale.

— Andrej Bauer,

@AndrejBauer - Grazie per la risposta. Sono un po 'sorpreso dalla tua affermazione, applicata a ciò che ho scritto. Niente lì supporta una qualche forma di coerenza assoluta, ma solo il desiderio di un approccio praticabile che renderebbe l'aggregazione possibile e significativa in un contesto in evoluzione. Per lo più coerente come dici tu, potrebbe fare. Trovare ciò che coerente dovrebbe significare per lo scopo era parte dell'idea, e non stavo suggerendo alcuna risposta, banale o meno. Non sono mai stato un teorico ossessionato e dalla tua risposta non vedo dove potremmo essere in contrasto.

— babou,

1

Penso che stavo solo insultando i "puri teorici", tutto qui. Per favore, ignorami.

— Andrej Bauer,

0

c'è stata un'enorme innovazione ed esplosione nei linguaggi di programmazione dal lato applicato e teorico nel corso dell'ultimo secolo, ma si potrebbe sostenere che si tratta di un evento singolare / unico nella storia dell'informatica, simile a una "esplosione evolutiva" (vedi anche "perché ci sono così tanti linguaggi di programmazione?" su cs.se), e che quindi il futuro non sarà come il passato in questo senso. tuttavia ci sono alcune tendenze attuali identificabili a lungo raggio in gioco / in fase di sviluppo.

La complessità della programmazione / software e le modalità di gestione / minimizzazione / mitigazione / riduzione è un argomento che ha sempre influenzato la progettazione del linguaggio ed è probabilmente ancora più significativo nell'era attuale con sistemi software molto grandi / complessi abbastanza comuni. era un aspetto importante della logica di progettazione OOP, ma ora abbiamo sistemi OOP molto complessi! la sua ponderata riflessione ha portato a classici del settore come Mythical man-month di Brooks che per molti versi è ancora una prospettiva molto valida, forse anche più rilevante di quando è stata scritta.
parallelismo. c'è uno spostamento dell'hardware verso un maggiore parallelismo (ad es. multicore ecc.) e gli aumenti della velocità di clock non sono più sufficienti per aumentare le prestazioni. questo cambiamento è avvenuto verso la metà degli anni 2000 e sta avendo una grande influenza sulla ricerca / progettazione linguistica. il parallelismo è sempre stato un argomento, ma ha una nuova preminenza / urgenza in primo piano, e vi è un certo pensiero / consenso diffuso sul fatto che il parallelismo sia eccessivamente complicato e difficile nella programmazione e forse diversi approcci teorici potrebbero alleviarne un po '. un bel riferimento a questo: The Landscape of Parallel Computing Research: A View from Berkeley
datamining / big data . questi stanno influenzando la progettazione del linguaggio di programmazione. anche nuove direzioni nell'architettura del database stanno increspando / influenzando i linguaggi di programmazione.
il supercalcolo ha un impatto significativo sulla progettazione del linguaggio e si sovrappone anche al parallelismo e al datamining / big data, ad esempio con nuovi linguaggi come MapReduce .
programmazione visiva / flusso di dati . c'è stato un aumento di questi tipi di "linguaggi" (in un certo senso la programmazione visiva è in molti modi in realtà disaccoppiando la programmazione da "linguaggi"). anche una forte impollinazione incrociata con parallelismo.
AI . questo è più di un carattere jolly e non è molto chiaro in questo momento come avrà un impatto sui linguaggi e sulla programmazione del computer, ma probabilmente sarà molto sostanziale. in passato [in una forma diversa] ha portato a intere lingue come il prologo . un'indicazione precoce di come può essere applicato con risultati sorprendenti è l'algoritmo genetico / la programmazione genetica .

un riferimento che potrebbe avere delle idee utili sulla falsariga del "futuro dei linguaggi di programmazione", Beyond Java di Tate. medita (anche se in modo controverso) che forse Java (probabilmente uno dei linguaggi di programmazione più sofisticati / completi esistenti) stia iniziando a mostrare la sua età e ci sono segni precoci di nuovi linguaggi / approcci che stanno emergendo per riempire il suo posto a lungo termine.

— vzn
fonte