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

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.

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.

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.

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).

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.