Historyczny precedens, dlaczego Prolog jest mniej popularny niż SQL w programowaniu imperatywnym? [Zamknięte]


12

Wygląda na to, że pisanie deklaratywne SQL jest bardzo popularne w programowaniu imperatywnym . Wydaje się jednak również, że pisanie deklaratywne Prolog może zaoszczędzić wiele złożoności, ale nie jest to zbyt powszechne.

Czy istnieje historyczny precedens dla tej pozornej preferencji SQL nad Prologiem?

Jeśli przyczyną jest brak natywnego wsparcia przez języki imperatywne , to czy można odpowiedzieć, dlaczego twórcy języków nie uznali za przydatne natywnego wsparcia Prolog?


Aby podać konkretne przykłady:

Przykład 1
Ocena wniosku o pożyczkę może składać się tylko z kilku wierszy kodu Prolog, podobnie jak SELECT/JOINzapytanie zawierające tylko kilka wierszy kodu SQL, ale wydaje się, że przewaga nie jest tak oczywista jak SQL.

Przykład 2
Oto kolejny przykładowy problem i rozwiązanie w Prologu. Poniższy program logiczny z ograniczeniami reprezentuje uproszczony zestaw danych z historii Johna jako nauczyciela:

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.

Następująca klauzula celu wysyła zapytanie do zestawu danych, aby dowiedzieć się, kiedy John zarówno uczył logiki, jak i był profesorem :

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

Wynik:

2010  T, T  2012.

W powyższym przykładzie SQLuzyskanie tego samego wyniku będzie łatwe . Załóżmy jednak, że masz te dane w pliku Array. Wtedy nie jest tak łatwo uzyskać takie same wyniki przy użyciu SQL. A w przypadku danych przechowywanych w tablicy uważam, że kod Prolog będzie łatwiejszy do napisania i utrzymania.


8
Możesz chcieć zmniejszyć aspekt rant.

4
Większość tekstu brzmi jak obelga przeciwko ludziom, którzy nie używają Prologu. Jest w nim pytanie, które warto zadać, ale inne rzeczy (rant) przyciągają głosy negatywne i wyłączają ludzi, którzy mogliby udzielić odpowiedzi. Innymi słowy, sugeruję, abyś spróbował sformułować swoje pytanie w sposób bardziej charytatywny.

6
„Na przykład ocena wniosku o pożyczkę może być tylko kilkoma wierszami kodu w Prologu”. Nie kupuję tego, z tego samego powodu, dla którego każda aplikacja warta jego soli użyje ton niestandardowych lub wygenerowanych zapytań SQL.
Euforia

7
Może czegoś mi brakuje, ale myślę, że odpowiedź brzmi „ludzie używają SQL, ponieważ to właśnie obsługuje bazy danych” .
GrandmasterB,

3
Oni zrobić użycie Prolog ... no ... właściwie ... to zrobić użytku Rules Silniki , które są „ad hoc, nieformalnie-podano, bug jeździł, powolne wdrażanie połowie Prolog” .
Jörg W Mittag,

Odpowiedzi:


19

Uważam, że jest to przede wszystkim rzecz historyczna.

SQL był używany głównie w firmach do tworzenia aplikacji biznesowych. Niektóre firmy czerpią zyski ze sprzedaży rozwiązań SQL i wykorzystują swoje pieniądze do reklamowania i popychania SQL do wielu osób. Zostało to szczególnie wzmocnione przez to, jak ważne są dane dla ludzi biznesu. Właśnie dlatego SQL przekonał wielu konkurentów i jest tak powszechnie znany i używany nawet dziś.

Z drugiej strony Prolog był znany głównie w sferze akademickiej, zwykle w obszarze sztucznej inteligencji. Ludzie akademiccy rzadko narzucają swoje narzędzia i pomysły innym, jak robi to biznes. Zwykle wymaga od firmy reklamowania technologii, która narodziła się w środowisku akademickim, aby rozpowszechniła się wśród zwykłych programistów. Ponadto, chociaż dane są niezwykle ważne, „reguły biznesowe” nie są takie. Choć mogą wydawać się ważne, są znacznie mniej ważne niż dane. Reguły biznesowe można zazwyczaj łatwo naprawić. Próba naprawienia „uszkodzonych” danych jest zwykle o wiele trudniejszym problemem. Firmy skoncentrowały się więc bardziej na zdobywaniu rozwiązań w zakresie danych niż na swoich regułach biznesowych.


2
„Zwykle wymaga od firmy reklamowania technologii, która narodziła się w środowisku akademickim, aby rozpowszechniła się wśród zwykłych programistów.”: Prawda. Wiele dobrych pomysłów jest opracowywanych w środowisku akademickim, a później upowszechnianych przez firmy, które mają do tego siłę marketingową. +1
Giorgio

6

Powód jest właściwie bardzo prosty. Nie ma to nic wspólnego z tym, jak użyteczny jest język dla danego zadania, i wszystko, co ma związek z utrzymywalnością kodu.

Czytając instrukcję SQL, wielu programistów będzie w stanie określić, co robią najbardziej podstawowe zapytania, nie znając języka. Mogą mieć trudniejszy czas w przypadku złożonych przykładów, ale dostosowanie istniejącego kodu lub praca z próbkami jest stosunkowo łatwa. Bariera dla zrozumienia jest dość niska w przypadku większości zapytań.

Przeczytałeś kilka linijek prologu, a wielu programistów podniosło lekko oczy i pozostawiło to zadanie komuś innemu, a być może położyło się. Predykatowa składnia prologu po prostu nie nadaje się do łatwego czytania.

Aktualizacja:

Na podstawie przykładu kodu języki, które implementują kolekcje, powinny mieć się dobrze. Zaimplementowałem rozwiązanie w języku C # / Linq i nie było ono znacznie większe niż próbka prologu (po uwzględnieniu wymaganego pisania statycznego i definicji). Dodatkowy krok polegał na niektórych pracach tymczasowych w celu scalenia list w celu utworzenia pojedynczej osi czasu do przeszukania, ale nie było to znaczące.


14
To prawda, że ​​SQL wybrał ultra-verbose klasy „COBOL” i „naturalną” składnię, która sprawia, że ​​jest „łatwa” do odczytania. Ale poważnie wątpię, aby ktoś, kto nie zna SQL, byłby w stanie poprawnie zrozumieć średnio skomplikowane zdanie z kilkoma joins count(*)lub czymkolwiek podobnym. Jeśli rozumiemy podstawy SQL, to dlatego, że czasami musimy używać tego języka i dlatego musieliśmy się go uczyć. Relacyjne przechowywanie danych jest znacznie bardziej powszechną potrzebą niż rozwiązywanie systemów logicznych, więc nie pojawia się żadna porównywalnie silna konieczność uczenia się Prologu.
amon

3
@amon To brzmi jak początek dobrej odpowiedzi :-)
svick

1
Bariera w nauce SQL może zostać obniżona z powodu czytelności, prolog może odeprzeć ludzi z powodu składni, całkowicie się z tym zgadzam. Ale w rzeczywistości bez znajomości SQL rozumienia podkwerend i kilku złączeń nie jest tak trywialne. Ale dolna bariera przy rozpoczynaniu od prostych zapytań jest z pewnością powodem, dla którego ludzie używaliby SQLa zamiast Prologa. :)
Dylan Meeus,

4
@JamesSnell Przepraszamy, ale -1. To, co twierdzisz, nie pasuje do żadnego RegEx . ^(?:(?:(?:0?[13578]|1[02])(\/|-|\.)31)\1|(?:(?:0?[13-9]|1[0-2])(\/|-|\.)(?:29|30)\2))(?:(?:1[6-9]|[2-9]\d)?\d{2})$|^(?:0?2(\/|-|\.)29\3(?:(?:(?:1[6-9]|[2-9]\d)?(?:0[48]|[2468][048]|[13579][26])|(?:(?:16|[2468][048]|[3579][26])00))))$|^(?:(?:0?[1-9])|(?:1[0-2]))(\/|-|\.)(?:0?[1-9]|1\d|2[0-8])\4(?:(?:1[6-9]|[2-9]\d)?\d{2})$.
53777A,

1
@JamesSnell RegEx są tajemnicze, trudne do napisania, debugowania, konserwacji i modyfikacji lub rozszerzenia, ale są niezwykle popularne. Jeśli miałeś rację, RegEx nigdy nie powinien był zyskać swojej popularności wśród programistów i twórców języków.
53777A,

4

Jest inny powód. W praktyce SQL jest przydatny w przypadku danych utrwalonych na dysku. Bazy danych są więc używane do przechowywania danych przez „długi” czas (kilka miesięcy). Każda baza danych SQL (np. PostgreSQL, MySQL, Oracle, ....) zarządza danymi na dyskach (lub dyskach SSD, tj. Sprzęcie, który może przechowywać dane, jeśli zostanie odpowiednio wyłączony). Jednak większość implementacji Prolog, o których wiem, działa w pamięci i nie można ich używać do niezawodnego przechowywania danych (dane trwałe po awarii zasilania, przynajmniej zaprogramowane). A implementacje SQL radzą sobie z terabajtami danych ....

Oczywiście DBMS nie zapisuje natychmiast na dysku (ale później). Ale tłumacze Prologu, o których słyszałem, nigdy nie piszą (domyślnie) swoich faktów i zasad, aby utrwalić je na dysku.

(Niektóre implementacje językowe mają zdolność trwałości, np. SBCL z save-lisp-and-die... ale nie znam Prologa, który to robi).

Pragmatycznie rzecz biorąc, SQL jest przeznaczony dla baz danych na dyskach, ale Prolog jest językiem programowania (dla kodu źródłowego w plikach tekstowych).


1
Nie sądzę, ponieważ żadna baza danych SQL nie działa ściśle z dyskowymi operacjami wejścia / wyjścia, ponieważ byłoby to bardzo nieefektywne (w pamięci są zawsze jakieś dane) i nie ma technicznej przeszkody w szeregowaniu ograniczeń prologu na dysk, który ja mogą myśleć w tej chwili.
idoby

3
Teoretycznie SQL jest językiem zapytań i nie obchodzi go, jak przechowywane są dane, o ile dane są opisywane przez model relacyjny. SQL to tylko interfejs, a nie paradygmat. Istnieją bazy danych korzystające z SQL, które działają wyłącznie lub częściowo w nietrwałej pamięci. Baza danych korzystająca z SQL mogłaby nawet przechowywać dane w postaci faktów Prolog! [potrzebne źródło] W końcu fakty opisują jedynie relacje. I odwrotnie, prawdopodobnie silnik Prolog mógłby przechowywać fakty w sposób podobny do bazy danych na dysku zamiast ładować wszystko do pamięci.
amon

1
Teoretycznie tak, ale praktycznie SQL jest przechowywany na dysku, i to często jest niezbędne
Basile Starynkevitch

1
@BasileStarynkevitch Reguły i fakty są zapisane w kodzie źródłowym, który utrzymuje się na dysku. Dlaczego zamiast tego miałbyś przechowywać je w bazie danych? Co rozumiesz przez Prolog nie może przechowywać danych? Nie należy tego robić. Właśnie dlatego istnieją bazy danych. Czy mógłbyś proszę opracować więcej.
53777A,

1
Dokładnie, SQL jest dla baz danych, a Prolog to język programowania. O to mi chodzi.
Basile Starynkevitch,

1

Jednym z dotychczas nie wspomnianych aspektów jest nacisk na „otwarte” systemy w latach 80. i 90. W wielu miejscach dostawcy oprogramowania musieliby zapewnić standardowy w branży dostęp do danych w swoich bazach danych. W tym czasie SQL był uznanym standardem, który był dobrze znany i rozumiany; Prolog był dość ezoteryczny i akademicki. Kiedy już zacząłeś otrzymywać interfejsy takie jak ODBC do łatwego łączenia systemów, nikt nie był zainteresowany spojrzeniem na inne technologie.

Pod koniec lat 80. pracowałem w miejscu, które miało całkiem udaną bazę danych ISAM, która została zmuszona przez presję rynku / przepisy dotyczące zamówień do dodania interfejsu SQL.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.