Precedenti storici per il motivo per cui Prolog è meno popolare di SQL in Programmazione imperativa? [chiuso]

12

Sembra che scrivere Dichiarativo SQL sia molto popolare in Programmazione Imperativa . Tuttavia, sembra anche che scrivere Dichiarativo Prolog potrebbe risparmiare molta complessità, ma questo non è molto comune.

Esiste un precedente storico per questa apparente preferenza di SQL rispetto a Prolog?

Se la ragione è la mancanza di supporto nativo da parte delle lingue Imperative , allora è possibile rispondere perché i creatori linguistici non hanno trovato utile supportare nativamente Prolog in primo luogo?

Per fornire alcuni esempi specifici:

Esempio 1
La valutazione di un'applicazione di prestito potrebbe essere solo alcune righe di codice in Prolog , come la query SELECT/JOIN che è solo alcune righe di codice in SQL , ma sembra che il vantaggio non sia ovvio come SQL .

Esempio 2
Ecco un altro problema di esempio e la soluzione in Prolog. Il seguente programma di logica dei vincoli rappresenta un set di dati semplificato della storia di john come insegnante:

teaches(john, hardware, T) :- 1990 ≤ T, T < 1999.
teaches(john, software, T) :- 1999 ≤ T, T < 2005.
teaches(john, logic, T) :- 2005 ≤ T, T ≤ 2012.
rank(john, instructor, T) :- 1990 ≤ T, T < 2010.
rank(john, professor, T) :- 2010 ≤ T, T < 2014.

La seguente clausola obiettivo interroga il set di dati per scoprire quando john ha entrambi insegnato logic ed era un professore :

:- teaches(john, logic, T), rank(john, professor, T).

Risultato:

2010 ≤ T, T ≤ 2012.

Nell'esempio precedente sarà facile con SQL ottenere lo stesso risultato. Ma supponiamo che tu abbia questi dati in un Array . Quindi non è così facile ottenere gli stessi risultati usando SQL . E nel caso di dati memorizzati in un array, credo che il codice Prolog sarà più facile da scrivere e mantenere.

    
posta 53777A 07.12.2014 - 16:07
fonte

4 risposte

19

Credo che questa sia principalmente una questione storica.

SQL è stato utilizzato principalmente nelle aziende per la creazione di applicazioni aziendali. Alcune aziende sviluppano la loro vitalità vendendo soluzioni SQL e hanno usato i loro soldi per pubblicizzare e spingere SQL in mente di molti. Ciò è stato particolarmente rafforzato da quanto importanti siano i dati per gli uomini d'affari. Questo è il motivo per cui SQL ha conquistato molti concorrenti ed è così ampiamente conosciuto e utilizzato anche oggi.

Il prologo nell'altro modo era per lo più conosciuto in ambito accademico, di solito nell'area dell'intelligenza artificiale. Le persone accademiche spingono raramente i loro strumenti e le loro idee sugli altri in un modo che il business fa. Di solito, alcune società pubblicizzano una tecnologia nata nel mondo accademico perché si diffonda tra sviluppatori comuni. Inoltre, mentre i dati sono estremamente importanti, le "regole aziendali" non sono così. Sebbene possano sembrare importanti, sono molto meno importanti dei dati. Normalmente le regole aziendali possono essere facilmente risolte. Cercare di sistemare i dati "corrotti" è di solito un problema molto più difficile. Quindi le aziende si sono concentrate molto di più nell'ottenere le proprie soluzioni di dati rispetto alle loro soluzioni di regole aziendali.

    
risposta data 07.12.2014 - 18:42
fonte
6

Il motivo è in realtà piuttosto semplice. Non ha nulla a che fare con quanto sia utile il linguaggio per un determinato compito e tutto ciò che riguarda il modo in cui è gestibile il codice.

Leggendo un'istruzione SQL, molti sviluppatori saranno in grado di determinare cosa fanno le query di base senza conoscere la lingua. Potrebbero avere un tempo più difficile nel caso di esempi complessi ma l'adattamento del codice esistente o il lavoro da campioni è relativamente facile. La barriera alla comprensione è piuttosto bassa per la stragrande maggioranza delle domande.

Leggi alcune righe di prolog e molti sviluppatori saranno leggermente strabici e lasceranno l'incarico a qualcun altro, e probabilmente finiranno per sdraiarsi. La sintassi del predicato del prologo semplicemente non si presta a una lettura facile.

Aggiornamento:

In base all'esempio di codice, le lingue che implementano le raccolte dovrebbero funzionare correttamente. Ho implementato una soluzione in C # / Linq e non era significativamente più grande di quella del prologo (una volta che hai tenuto conto della tipizzazione statica e delle definizioni richieste). C'è stato un ulteriore passo in avanti nel lavoro interinale per unire gli elenchi per fare una singola timeline da cercare, ma non era una quantità significativa di lavoro.

    
risposta data 07.12.2014 - 17:07
fonte
4

C'è un'altra ragione. In pratica, SQL è utile per i dati persistenti su disco. Quindi i database vengono utilizzati per archiviare i dati per un tempo "lungo" (diversi mesi). Ogni database SQL (ad esempio PostgreSQL, MySQL, Oracle, ....) sta gestendo i dati su dischi (o SSD, ovvero hardware che potrebbero mantenere i dati se spenti correttamente). Tuttavia, la maggior parte delle implementazioni Prolog di cui sono a conoscenza funzionano in memoria e non possono essere utilizzate per conservare i dati in modo affidabile (dati persistenti dopo un'interruzione dell'alimentazione, almeno una programmata). E le implementazioni SQL possono gestire terabyte di dati ....

Naturalmente, un DBMS non scrive immediatamente sul disco (ma successivamente). Ma gli interpreti Prolog di cui ho sentito parlare non scrivono mai (implicitamente) il loro fatto & rule bases per persisterli sul disco.

(Alcune implementazioni linguistiche hanno capacità di persistenza, ad esempio SBCL con save-lisp-and-die ... ma non conosco nessun Prolog che lo faccia).

In termini pragmatici, SQL è per i database -on disks-, ma Prolog è un linguaggio di programmazione (per il codice sorgente nei file testuali).

    
risposta data 07.12.2014 - 20:36
fonte
1

Un aspetto non menzionato finora è la spinta per i sistemi "aperti" negli anni '80 e '90. In molti luoghi, i fornitori di software dovrebbero fornire l'accesso standard ai dati nei loro database. A quel tempo, SQL era uno standard consolidato che era ben noto e compreso; Prolog era piuttosto esoterico e accademico. Una volta che hai iniziato a ottenere interfacce come ODBC per connettere facilmente i sistemi, nessuno era interessato a guardare ad altre tecnologie.

Ho lavorato in un luogo alla fine degli anni '80 che aveva un database ISAM di discreto successo, che era stato costretto dalle regole di mercato / appalti ad aggiungere un'interfaccia SQL a.

    
risposta data 09.12.2014 - 06:24
fonte

Leggi altre domande sui tag