Tiền lệ lịch sử tại sao Prolog ít phổ biến hơn SQL trong Lập trình mệnh lệnh? [đóng cửa]


12

Có vẻ như viết Tuyên ngôn SQL rất phổ biến trong Lập trình mệnh lệnh . Tuy nhiên, dường như việc viết Tuyên bố Prolog có thể tiết kiệm rất nhiều sự phức tạp nhưng điều này không phổ biến lắm.

Có tiền lệ lịch sử nào cho ưu tiên rõ ràng này của SQL so với Prolog không?

Nếu lý do là thiếu sự hỗ trợ bản địa của các ngôn ngữ mệnh lệnh , thì có thể trả lời tại sao những người tạo ngôn ngữ không thấy hữu ích khi hỗ trợ Prologban đầu không?


Để cung cấp một số ví dụ cụ thể:

Ví dụ 1
Đánh giá một ứng dụng cho vay có thể chỉ là một vài dòng mã Prolog, giống như SELECT/JOINtruy vấn chỉ là một vài dòng mã SQL, nhưng có vẻ như lợi thế không rõ ràng như SQL.

Ví dụ 2
Đây là một vấn đề ví dụ khác và giải pháp trong Prolog. Chương trình logic ràng buộc sau đây biểu thị một tập dữ liệu đơn giản về lịch sử của john với tư cách là một giáo viên:

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.

Mệnh đề mục tiêu sau đây truy vấn bộ dữ liệu để tìm hiểu khi john vừa dạy logic và là giáo sư :

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

Kết quả:

2010  T, T  2012.

Trong ví dụ trên, sẽ dễ dàng SQLđể có được kết quả tương tự. Nhưng giả sử rằng bạn có dữ liệu này trong một Array. Sau đó, không dễ dàng để có được kết quả tương tự bằng cách sử dụng SQL. Và trong trường hợp dữ liệu được lưu trữ trong một mảng, tôi tin rằng mã Prolog sẽ dễ viết và duy trì hơn.


8
Bạn có thể muốn quay số khía cạnh rant.

4
Hầu hết các văn bản nghe có vẻ như một lời ca ngợi những người không sử dụng Prolog. Có một câu hỏi đáng để hỏi trong đó, nhưng những thứ khác (câu thần chú) thu hút những người hạ thấp và tắt những người có thể đóng góp một câu trả lời. Nói cách khác, tôi khuyên bạn nên thử đặt câu hỏi theo cách từ thiện hơn.

6
"Ví dụ: đánh giá một ứng dụng cho vay có thể chỉ là một vài dòng mã trong Prolog" Tôi không mua cái này, vì lý do tương tự như bất kỳ ứng dụng nào có giá trị, muối sẽ sử dụng hàng tấn truy vấn SQL được tạo tùy chỉnh hoặc được tạo.
Euphoric

7
Có thể tôi đang thiếu một cái gì đó, nhưng tôi nghĩ câu trả lời ở đây là 'mọi người sử dụng SQL vì đó là những gì cơ sở dữ liệu hỗ trợ' .
GrandmasterB

3
Họ làm sử dụng Prolog ... cũng ... thực sự ... họ làm sử dụng Quy định động cơ , đó là "một quảng cáo đặc biệt, không chính thức chỉ định, bug-ridden, thực hiện chậm chạp của một nửa số Prolog" .
Jörg W Mittag

Câu trả lời:


19

Tôi tin rằng đây chủ yếu là điều lịch sử.

SQL chủ yếu được sử dụng trong các doanh nghiệp để tạo các ứng dụng kinh doanh. Một số công ty xây dựng sự sinh động của họ bằng cách bán các giải pháp SQL và họ đã sử dụng tiền của họ để quảng cáo và đẩy SQL vào tâm trí của nhiều người. Điều này đặc biệt được trao quyền bởi cách dữ liệu quan trọng đối với người kinh doanh. Đây là lý do tại sao SQL giành chiến thắng trước nhiều đối thủ cạnh tranh và được biết đến và sử dụng rộng rãi ngay cả ngày nay.

Prolog theo cách khác chủ yếu được biết đến trong lĩnh vực học thuật, thường là trong lĩnh vực trí tuệ nhân tạo. Những người học thuật hiếm khi thúc đẩy các công cụ và ý tưởng của họ về người khác theo cách kinh doanh. Nó thường yêu cầu một số công ty quảng cáo một công nghệ được sinh ra trong giới hàn lâm để nó lan rộng giữa các nhà phát triển phổ biến. Ngoài ra, trong khi dữ liệu là cực kỳ quan trọng, "quy tắc kinh doanh" lại không như vậy. Mặc dù chúng có vẻ quan trọng, nhưng chúng ít quan trọng hơn dữ liệu. Quy tắc kinh doanh thường có thể được sửa chữa dễ dàng. Cố gắng sửa dữ liệu "bị hỏng" thường là vấn đề khó khăn hơn nhiều. Vì vậy, các doanh nghiệp tập trung nhiều vào việc có được các giải pháp dữ liệu của họ hơn là các giải pháp quy tắc kinh doanh của họ.


2
"Nó thường yêu cầu một số công ty quảng cáo một công nghệ được sinh ra trong giới hàn lâm để nó lan rộng giữa các nhà phát triển chung.": Đúng. Rất nhiều ý tưởng hay được phát triển trong giới hàn lâm và sau đó được phổ biến bởi các công ty có sức mạnh tiếp thị để thực hiện. +1
Giorgio

6

Lý do thực sự khá đơn giản. Nó không liên quan gì đến việc ngôn ngữ hữu ích như thế nào đối với một nhiệm vụ nhất định và mọi thứ liên quan đến mức độ duy trì của mã.

Đọc một câu lệnh SQL, nhiều nhà phát triển sẽ có thể xác định hầu hết các truy vấn cơ bản làm gì mà không biết ngôn ngữ. Họ có thể có một thời gian khó khăn hơn trong trường hợp các ví dụ phức tạp nhưng việc điều chỉnh mã hiện có hoặc làm việc từ các mẫu là tương đối dễ dàng. Rào cản để hiểu là khá thấp đối với phần lớn các truy vấn.

Bạn đọc một vài dòng prolog và nhiều nhà phát triển sẽ lác mắt và giao nhiệm vụ cho người khác, và có thể sẽ nói dối. Cú pháp vị ngữ của prolog đơn giản là không cho vay dễ đọc.

Cập nhật:

Dựa trên mẫu mã, các ngôn ngữ triển khai các bộ sưu tập sẽ hoạt động tốt. Tôi đã triển khai một giải pháp trong C # / Linq và nó không lớn hơn đáng kể so với mẫu prolog (một khi bạn đã tính đến việc gõ tĩnh và các định nghĩa cần thiết). Có thêm một bước liên quan đến một số công việc tạm thời để hợp nhất các danh sách để tạo một dòng thời gian duy nhất được tìm kiếm nhưng nó không phải là một lượng công việc đáng kể.


14
Đúng là SQL đã sử dụng cú pháp siêu dài dòng cấp độ COBOL và cú pháp tự nhiên có thể làm cho nó dễ dàng để đọc. Nhưng tôi nghi ngờ nghiêm trọng mà một người không biết SQL sẽ có thể hiểu đúng một tuyên bố vừa phức tạp với một vài joins hoặc count(*)hoặc bất cứ điều gì như thế. Nếu chúng ta hiểu những điều cơ bản về SQL thì đó là vì đôi khi chúng ta phải sử dụng ngôn ngữ đó và do đó phải học những điều cơ bản này. Lưu trữ dữ liệu quan hệ là một nhu cầu phổ biến hơn nhiều so với việc giải quyết các hệ thống logic, do đó không cần phải có sự tương đối mạnh mẽ để học Prolog.
amon

3
@amon Nghe có vẻ như là một khởi đầu của một câu trả lời hay :-)
svick 7/12/14

1
Rào cản học SQL có thể được hạ xuống vì tính dễ đọc, prolog có thể chống đỡ mọi người do cú pháp, tôi hoàn toàn đồng ý về điều đó. Nhưng thực sự, không biết các câu hỏi con hiểu SQL và một vài phép nối không phải là chuyện nhỏ. Nhưng rào cản thấp hơn khi bắt đầu với các truy vấn đơn giản chắc chắn là lý do mọi người sẽ sử dụng SQL thay vì Prolog để bắt đầu. :)
Dylan Meeus

4
@JamesSnell Xin lỗi nhưng -1. Những gì bạn đang tuyên bố không phù hợp với bất kỳ 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 là khó hiểu, khó viết, gỡ lỗi, duy trì và sửa đổi hoặc mở rộng, nhưng chúng cực kỳ phổ biến. Nếu bạn đã đúng thì RegEx sẽ không bao giờ có được sự phổ biến hiện tại giữa các nhà phát triển và người tạo ngôn ngữ.
53777A

4

Có một lý do khác. Thực tế mà nói, SQL rất hữu ích cho dữ liệu tồn tại trên đĩa. Vì vậy, cơ sở dữ liệu được sử dụng để lưu trữ dữ liệu trong một thời gian "dài" (vài tháng). Mọi cơ sở dữ liệu SQL (ví dụ PostgreSQL, MySQL, Oracle, ....) đang quản lý dữ liệu trên đĩa (hoặc SSD, tức là phần cứng có thể giữ dữ liệu nếu được tắt nguồn đúng cách). Tuy nhiên, hầu hết các triển khai Prolog mà tôi biết là đang hoạt động trong bộ nhớ và không thể được sử dụng để giữ dữ liệu một cách đáng tin cậy (dữ liệu vẫn tồn tại sau khi mất điện, ít nhất là được lập trình). Và việc triển khai SQL có thể xử lý hàng terabyte dữ liệu ....

Tất nhiên, một DBMS không ghi ngay vào đĩa (nhưng sau đó). Nhưng các thông dịch viên Prolog mà tôi nghe nói không bao giờ viết (ngầm) cơ sở thực tế & quy tắc của họ để duy trì chúng vào đĩa.

(Một số triển khai ngôn ngữ có khả năng kiên trì, ví dụ SBCL với save-lisp-and-die... nhưng tôi biết không có Prolog làm điều đó).

Nói một cách thực tế, SQL dành cho cơ sở dữ liệu - trên các đĩa- nhưng Prolog là ngôn ngữ lập trình (đối với mã nguồn trong các tệp văn bản).


1
Tôi không nghĩ vậy, vì không có cơ sở dữ liệu SQL nào hoạt động nghiêm ngặt với I / O của đĩa, vì điều đó sẽ rất kém hiệu quả (luôn có một số dữ liệu trong bộ nhớ) và không có trở ngại kỹ thuật nào trong việc nối tiếp các ràng buộc prologue vào đĩa mà tôi có thể nghĩ về lúc này
idoby

3
Về mặt lý thuyết, SQL là ngôn ngữ truy vấn và không quan tâm đến cách lưu trữ dữ liệu, miễn là dữ liệu được mô tả bằng mô hình quan hệ. SQL chỉ là một giao diện, không phải là một mô hình. Có các cơ sở dữ liệu sử dụng SQL hoạt động hoàn toàn hoặc một phần trong bộ nhớ không liên tục. Cơ sở dữ liệu sử dụng SQL thậm chí có thể lưu trữ dữ liệu dưới dạng các sự kiện Prolog! [cần dẫn nguồn] Rốt cuộc, sự thật chỉ mô tả quan hệ. Ngược lại, công cụ Prolog có thể lưu trữ các sự kiện theo kiểu cơ sở dữ liệu trên đĩa thay vì tải mọi thứ vào bộ nhớ.
amon

1
Về mặt lý thuyết là có, nhưng thực tế SQL đang lưu trữ trên đĩa và điều đó thường rất cần thiết
Basile Starynkevitch

1
@BasileStarynkevitch Quy tắc & Sự kiện được viết trên mã nguồn vẫn tồn tại trên đĩa. Tại sao bạn sẽ lưu trữ chúng trên cơ sở dữ liệu thay thế? Bạn có ý nghĩa gì bởi Prolog không thể giữ dữ liệu? Nó không phải là để làm điều đó. Đó là lý do tại sao cơ sở dữ liệu tồn tại. Bạn có thể vui lòng giải thích thêm.
53777A

1
Chính xác, SQL dành cho cơ sở dữ liệu và Prolog là ngôn ngữ lập trình. Đó là quan điểm của tôi.
Basile Starynkevitch

1

Một khía cạnh không được đề cập cho đến nay là sự thúc đẩy cho các hệ thống "mở" trong những năm 1980 và 1990. Ở nhiều nơi, các nhà cung cấp phần mềm sẽ phải cung cấp quyền truy cập tiêu chuẩn công nghiệp vào dữ liệu trong cơ sở dữ liệu của họ. Vào thời điểm đó, SQL là một tiêu chuẩn được thiết lập rõ ràng và được hiểu rõ; Prolog là khá bí truyền và hàn lâm. Khi bạn bắt đầu nhận các giao diện như ODBC để dễ dàng kết nối các hệ thống, không ai quan tâm đến việc xem xét các công nghệ khác.

Tôi đã làm việc tại một nơi vào cuối những năm 80 có cơ sở dữ liệu ISAM khá thành công, bị ép buộc bởi áp lực thị trường / quy định mua sắm để thêm giao diện SQL vào.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.