Il sogno della programmazione dichiarativa [chiuso]

Perché il sogno della programmazione dichiarativa non è stato realizzato? Quali sono alcuni ostacoli concreti che si frappongono? Per un semplice esempio, perché non posso dirlo

sort(A) is defined by sort(A) in perm(A) && asc(sort(A))

e ne ricava automaticamente un algoritmo di ordinamento. permsignifica permutazioni e ascsignifica ascendente.

Ci sono alcune risposte molto buone. Proverò a contribuire alla discussione.

Sul tema della programmazione dichiarativa e logica in Prolog, c'è il grande libro "The Craft of Prolog" di Richard O'Keefe . Si tratta di scrivere programmi efficienti utilizzando un linguaggio di programmazione che consente di scrivere programmi molto inefficienti. In questo libro, mentre discute le implementazioni efficienti di numerosi algoritmi (nel capitolo "Metodi di programmazione"), l'autore adotta il seguente approccio:

• definire il problema in inglese
• scrivere una soluzione funzionante il più dichiarativa possibile; di solito, questo significa praticamente esattamente quello che hai nella tua domanda, solo Prolog corretto
• da lì, prendere provvedimenti per perfezionare l'implementazione per renderla più veloce

L'osservazione più illuminante (per me) che sono stato in grado di fare mentre mi facevo strada attraverso questi:

Sì, la versione finale dell'implementazione è molto più efficiente della specifica "dichiarativa" con cui l'autore ha iniziato. È ancora molto dichiarativo, conciso e di facile comprensione. Ciò che è accaduto nel mezzo è che la soluzione finale cattura le proprietà del problema a cui la soluzione iniziale era ignara.

In altre parole, durante l'implementazione di una soluzione, abbiamo utilizzato quante più conoscenze possibili sul problema. Confrontare:

Trova una permutazione di un elenco in modo tale che tutti gli elementi siano in ordine crescente

a:

L'unione di due elenchi ordinati comporterà un elenco ordinato. Poiché potrebbero essere presenti elenchi già ordinati, utilizzarli come punto di partenza, anziché elenchi di lunghezza 1.

Un piccolo inconveniente: una definizione come quella che hai dato è attraente perché è molto generale. Tuttavia, non posso sfuggire alla sensazione che ignori intenzionalmente il fatto che le permutazioni sono, beh, un problema combinatorio. Questo è qualcosa che già sappiamo ! Questa non è una critica, solo un'osservazione.

Per quanto riguarda la vera domanda: come andare avanti? Bene, un modo è quello di fornire la stessa conoscenza del problema che stiamo dichiarando al computer.

Il miglior tentativo che conosco per risolvere davvero il problema è presentato nei libri scritti da Alexander Stepanov, "Elementi di programmazione" e "Dalla matematica alla programmazione generica" . Purtroppo non sono all'altezza del compito di riassumere (o persino comprendere appieno) tutto in questi libri. Tuttavia, l'approccio è quello di definire algoritmi e strutture di dati efficienti (o addirittura ottimali), a condizione che tutte le proprietà pertinenti dell'input siano note in anticipo. Il risultato finale è:

• Ogni trasformazione ben definita è un affinamento dei vincoli che sono già in atto (le proprietà conosciute);
• Lasciamo che il computer decida quale trasformazione è ottimale in base ai vincoli esistenti.

Per quanto riguarda il motivo per cui non è ancora del tutto accaduto, beh, l'informatica è un campo davvero giovane e stiamo ancora affrontando apprezzando davvero la novità di gran parte di esso.

PS

Per darti un'idea di cosa intendo "perfezionando l'implementazione": prendi ad esempio il semplice problema di ottenere l'ultimo elemento di un elenco, in Prolog. La soluzione dichiarativa canonica è quella di dire:

last(List, Last) :-
    append(_, [Last], List).

Qui, il significato dichiarativo di append/3è:

List1AndList2è la concatenazione di List1eList2

Dato che nel secondo argomento append/3abbiamo una lista con un solo elemento, e il primo argomento viene ignorato (il trattino basso), otteniamo una divisione della lista originale che scarta il fronte della lista ( List1nel contesto di append/3) e richiede che il retro ( List2nel contesto di append/3) è davvero un elenco con un solo elemento: quindi, è l'ultimo elemento.

L' attuale implementazione fornita da SWI-Prolog , tuttavia, dice:

last([X|Xs], Last) :-
    last_(Xs, X, Last).

last_([], Last, Last).
last_([X|Xs], _, Last) :-
    last_(Xs, X, Last).

Questo è ancora ben dichiarativo. Leggi dall'alto verso il basso, dice:

L'ultimo elemento di un elenco ha senso solo per un elenco di almeno un elemento. L'ultimo elemento per una coppia di coda e la testa di un elenco, quindi, è: la testa, quando la coda è vuota, o l'ultimo della coda non vuota.

Il motivo per cui viene fornita questa implementazione è aggirare le questioni pratiche che circondano il modello esecutivo di Prolog. Idealmente, non dovrebbe fare la differenza sull'implementazione utilizzata. Allo stesso modo, avremmo potuto dire:

last(List, Last) :-
    reverse(List, [Last|_]).

L'ultimo elemento di un elenco è il primo elemento dell'elenco invertito.

Se vuoi fare il pieno di discussioni inconcludenti su ciò che è buono, Prolog dichiarativo, basta passare attraverso alcune delle domande e risposte nel tag Prolog su Stack Overflow .

I linguaggi logici lo fanno già. Puoi definire l'ordinamento in modo simile come lo stai facendo.

Il problema principale è la prestazione. I computer potrebbero essere bravi a calcolare un sacco di cose, ma sono intrinsecamente stupidi. Ogni decisione "intelligente" che un computer potrebbe prendere è stata programmata da un programmatore. E questa decisione viene generalmente descritta non da come appare il risultato finale, ma da come raggiungere, passo dopo passo, questo risultato finale.

Immagina la storia di un Golem . Se provi a dargli un comando astratto, nella migliore delle ipotesi lo farà in modo inefficiente e nella peggiore delle ipotesi, farà male a te stesso, a te o a qualcun altro. Ma se descrivi ciò che desideri nel modo più dettagliato possibile, hai la certezza che l'attività verrà completata in modo efficace ed efficiente.

È compito del programmatore decidere quale livello di astrazione usare. Per l'applicazione che stai realizzando, stai andando ad alto livello e descriverlo in modo astratto e prendere il colpo di prestazione o andare basso e sporco, passare 10 volte più tempo su di esso, ma ottenere un algoritmo che è 1000 volte più performante?

Oltre all'eccellente punto di Euphoric , vorrei aggiungere che stiamo già utilizzando linguaggi dichiarativi in ​​molti luoghi in cui funzionano bene, vale a dire descrivendo lo stato che non è probabile che cambi o richieda qualcosa per cui il computer può effettivamente generare codice efficiente da solo:

• HTML dichiara qual è il contenuto di una pagina Web.

• Il CSS dichiara come dovrebbero apparire i vari tipi di elementi in una pagina web.

• Ogni database relazionale ha un linguaggio di definizione dei dati che dichiara quale sia la struttura del database.

• SQL è molto più vicino a dichiarativo che a imperativo, dal momento che dici quello che vuoi vedere e il pianificatore di query del database capisce come farlo realmente accadere.

• Si potrebbe sostenere che la maggior parte dei file di configurazione (.vimrc, .profile, .bashrc, .gitconfig) utilizzano un linguaggio specifico del dominio ampiamente dichiarativo

Le astrazioni perdono

È possibile implementare un sistema dichiarativo in cui si dichiara ciò che si desidera e il compilatore o l'interprete stabilisce un ordine di esecuzione. Il vantaggio teorico è che ti libera dal dover pensare al "come" e non devi dettagliare questa implementazione. Tuttavia, in pratica per il calcolo per scopi generali devi ancora pensare al "come" e scrivere tutti i tipi di trucchi tenendo presente come questo verrà implementato, poiché altrimenti il ​​compilatore può (e spesso sceglierà) un'implementazione che sarà molto, molto, molto lento (es. n! operazioni in cui n sarebbe sufficiente).

Nel tuo esempio particolare, otterrai un algoritmo di ordinamento - non significa che ne otterrai uno buono o addirittura un po 'utilizzabile. La tua definizione data, se implementata letteralmente (come probabilmente farebbe un compilatore) si tradurrà in http://en.wikipedia.org/wiki/Bogosort che è inutilizzabile per set di dati più grandi - è tecnicamente corretto, ma ha bisogno di un'eternità per ordinare mille numeri .

Per alcuni domini limitati puoi scrivere sistemi che quasi sempre fanno bene a capire una buona implementazione, ad esempio SQL. Per il calcolo per scopi generici che non funziona particolarmente bene - puoi scrivere sistemi in, diciamo, Prolog ma devi visualizzare come alla fine le tue dichiarazioni verranno convertite in un ordine di esecuzione imperativo e che perde gran parte del dichiarativo atteso vantaggi di programmazione.

La decidibilità computazionale è il motivo più importante per cui la programmazione dichiarativa non si è dimostrata facile come sembra.

Molti problemi relativamente facili da affermare si sono rivelati indecidibili o hanno una complessità NP-completa da risolvere. Ciò si verifica spesso quando prendiamo in considerazione le classi e la classificazione, la numerabilità e la ricorsione negative.

Vorrei chiarire questo con alcuni domini che sono ben noti.

La decisione sulla classe CSS da utilizzare richiede conoscenza e considerazione di tutte le regole CSS. L'aggiunta di nuove regole potrebbe invalidare tutte le altre decisioni. Le classi CSS negative non vengono aggiunte intenzionalmente al linguaggio, a causa di problemi NP-completi, ma la mancanza di classi negative complica le decisioni di progettazione CSS.

All'interno di un Query Optimizer (SQL), c'è il fastidioso problema di decidere in quale ordine unire, quali indici usare e quale memoria assegnare a quali risultati temporanei. Questo è un problema noto NP completo e complica la progettazione del database e la formulazione di query. Per formularlo in modo diverso: quando si progetta un database o una query, il progettista deve conoscere le azioni e l'ordine delle azioni che è probabile che l'ottimizzatore di query esegua. Un ingegnere esperto necessita della conoscenza dell'euristica utilizzata dai principali fornitori di database.

I file di configurazione sono dichiarativi, ma alcune configurazioni sono difficili da dichiarare. Ad esempio, per configurare correttamente le funzionalità è necessario tenere conto del controllo delle versioni, della distribuzione (e della cronologia delle distribuzioni), delle possibili sostituzioni manuali e dei possibili conflitti con altre impostazioni. Convalidare correttamente una configurazione potrebbe diventare un problema NP-completo.

Il risultato è che queste complicazioni sorprendono i principianti, spezzano la "bellezza" della programmazione dichiarativa e fanno sì che alcuni ingegneri cerchino altre soluzioni. La migrazione di ingegneri inesperti da SQL a NoSQL potrebbe essere stata innescata dalle complessità sottostanti dei database relazionali.

Abbiamo una differenza nella dichiaratività dei linguaggi di programmazione che viene messa a frutto nella verifica della logica digitale.

Normalmente la logica digitale è descritta a livello di trasferimento dei registri (RTL) dove è definito il livello logico dei segnali tra i registri. Per verificare che stiamo aggiungendo sempre più proprietà definite in modo più astratto e dichiarativo.

Uno dei sottoinsiemi linguistici / linguistici più dichiarativi è chiamato PSL per Language Specification Property. Quando si verifica un modello RTL di un moltiplicatore in cui, ad esempio, è necessario specificare tutte le operazioni logiche di spostamento e aggiunta su più cicli di clock; puoi scrivere una proprietà nel modo di assert that when enable is high, this output will equal the multiplication of these two inputs after no more than 8 clock cycles. La descrizione del PSL può quindi essere controllata insieme al RTL in una simulazione, oppure si può dimostrare formalmente al PSL di essere valido per la descrizione del RTL.

Il modello PSL più dichiarativo obbliga a descrivere lo stesso comportamento della descrizione RTL, ma in un modo sufficientemente diverso che può essere verificato automaticamente contro RTL per vedere se sono d'accordo.

Principalmente il problema è come modellare i dati; e la programmazione dichiarativa non aiuta qui. Nelle lingue imperative hai già tonnellate di librerie che fanno un sacco di cose per te, quindi devi solo sapere come chiamare. In un modo particolare si potrebbe considerare questa programmazione dichiarativa (probabilmente il miglior esempio per questo è Stream API in Java 8 ). Detto questo, l'astrazione è già stata risolta e la programmazione dichiarativa non è necessaria.

Inoltre, come è stato detto, i linguaggi di programmazione logica fanno già esattamente quello che vuoi. Si potrebbe dire che il problema è rappresentato dalle prestazioni, ma con l'hardware e la ricerca odierni in questo settore, le cose possono essere migliorate per essere pronte per l'uso in produzione; in realtà Prolog è usato per l'intelligenza artificiale, ma credo solo dal mondo accademico.

Va notato che si applica ai linguaggi di programmazione generici. Per le lingue specifiche del dominio, le lingue dichiarative sono molto migliori; SQL è probabilmente l'esempio migliore.

Sarebbe simile a questo .. {(whatever => leggi un file e chiama un url) | chiama un URL e leggi un file} Tuttavia, si tratta di azioni da eseguire e, di conseguenza, lo stato del sistema cambia, ma ciò non è ovvio dall'origine.

I dichiaranti possono descrivere una macchina a stati finiti e le sue transizioni. L'FSM è come l'opposto dei dichiarativi senza azioni, anche se l'unica azione è cambiare lo stato nello stato successivo.

Il vantaggio di utilizzare questo metodo è che le transizioni e le azioni possono essere specificate dai predicati che si applicano a più transizioni, piuttosto che a una sola.

So che sembra un po 'strano, ma nel 2008 ho scritto un generatore di programmi che utilizza questo metodo e il C ++ generato è da 2 a 15 volte più della fonte. Ora ho oltre 75.000 righe di C ++ da 20.000 righe di input. Due cose vanno con questo: coerenza e completezza.

Coerenza: non esistono due predicati che possono essere veri allo stesso tempo e possono implicare azioni incoerenti, in quanto sia x = 8 che x = 9, né diversi stati successivi.

Completezza: viene specificata la logica per ogni transizione di stato. Questi possono essere difficili da verificare per i sistemi con N sottostati, con> 2 ** N stati, ma esistono interessanti metodi combinatori che possono verificare tutto. Nel 1962 scrissi la fase 1 di un tipo di sistema per le macchine 7070, usando questo tipo di generazione di codice condizionale e debug combinatorio. Delle 8000 righe del genere, il numero di bug dal giorno della prima versione è stato per sempre zero!

La seconda fase del genere, 12.000 linee, ha avuto oltre 60 errori nei primi due mesi. C'è molto altro da dire su questo, ma funziona. Se le case automobilistiche utilizzassero questo metodo per controllare il firmware, non vedremmo gli errori che vediamo ora.

Non tutto può essere rappresentato in modo dichiarativo.

Spesso, si desidera esplicitamente controllare il flusso di esecuzione

Ad esempio il seguente pseudo-codice: if whatever read a file call an URL else call an URL write a file come lo rappresenteresti in modo dichiarativo?

Certo, ci sono probabilmente alcuni modi esotici per farlo. Come monadi . Ma questi di solito sono più ingombranti, complicati e molto meno intuitivi della loro parte procedurale.

Tutto si riduce al fatto che "interagire" con il proprio ambiente / sistema non è dichiarativo. Tutto ciò che riguarda l'I / O è procedurale per essenza. Devi dire esattamente quando e cosa dovrebbe accadere e in quale ordine.

Dichiarativo è ottimo per tutto ciò che è puramente correlato al calcolo. Come una funzione gigante, inserisci X e ottieni Y. Fantastico. Un esempio è HTML, l'input è testo, l'output è quello che vedi nel tuo browser.