Ước mơ lập trình khai báo [đóng]

Tại sao giấc mơ lập trình khai báo không được thực hiện? Một số trở ngại cụ thể nhận được trên đường là gì? Cho một ví dụ đơn giản tại sao tôi không thể nói

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

và tự động lấy một thuật toán sắp xếp ra khỏi nó. permcó nghĩa là hoán vị và asccó nghĩa là tăng dần.

Có một số câu trả lời rất tốt. Tôi sẽ cố gắng đóng góp cho cuộc thảo luận.

Về chủ đề khai báo, lập trình logic trong Prolog, có cuốn sách tuyệt vời "The Craft of Prolog" của Richard O'Keefe . Đó là về việc viết các chương trình hiệu quả bằng ngôn ngữ lập trình cho phép bạn viết các chương trình rất kém hiệu quả. Trong cuốn sách này, trong khi thảo luận về việc triển khai hiệu quả một số thuật toán (trong chương "Phương pháp lập trình"), tác giả đã thực hiện cách tiếp cận sau:

• xác định vấn đề bằng tiếng Anh
• viết một giải pháp làm việc càng khai báo càng tốt; thông thường, điều đó có nghĩa khá chính xác những gì bạn có trong câu hỏi của mình, chỉ cần sửa Prolog
• từ đó, thực hiện các bước để tinh chỉnh việc thực hiện để làm cho nó nhanh hơn

Quan sát giác ngộ nhất (đối với tôi) tôi có thể thực hiện trong khi thực hiện theo cách này:

Có, phiên bản cuối cùng của việc triển khai hiệu quả hơn nhiều so với thông số kỹ thuật "khai báo" mà tác giả bắt đầu. Nó vẫn rất khai báo, cô đọng và dễ hiểu. Điều đã xảy ra ở giữa là giải pháp cuối cùng nắm bắt được các thuộc tính của vấn đề mà giải pháp ban đầu bị lãng quên.

Nói cách khác, trong khi thực hiện một giải pháp, chúng tôi đã sử dụng càng nhiều kiến ​​thức về vấn đề càng tốt. Đối chiếu:

Tìm một hoán vị của một danh sách sao cho tất cả các phần tử theo thứ tự tăng dần

đến:

Hợp nhất hai danh sách được sắp xếp sẽ dẫn đến một danh sách được sắp xếp. Vì có thể có các danh sách con đã được sắp xếp, hãy sử dụng chúng làm điểm bắt đầu, thay vì danh sách phụ có độ dài 1.

Một khía cạnh nhỏ: một định nghĩa giống như định nghĩa bạn đã đưa ra là hấp dẫn bởi vì nó rất chung chung. Tuy nhiên, tôi không thể thoát khỏi cảm giác rằng nó cố tình bỏ qua thực tế là hoán vị là một vấn đề tổ hợp. Đây là điều chúng ta đã biết ! Đây không phải là một lời chỉ trích, chỉ là một quan sát.

Như câu hỏi thực sự: làm thế nào để tiến về phía trước? Vâng, có một cách là cung cấp càng nhiều kiến ​​thức về vấn đề chúng ta đang tuyên bố với máy tính.

Nỗ lực tốt nhất mà tôi biết để thực sự giải quyết vấn đề được trình bày trong các cuốn sách do Alexander Stepanov đồng tác giả, "Các yếu tố lập trình" và "Từ toán học đến lập trình chung" . Đáng buồn là tôi không theo kịp nhiệm vụ tóm tắt (hoặc thậm chí hiểu đầy đủ) mọi thứ trong những cuốn sách này. Tuy nhiên, cách tiếp cận là xác định các thuật toán thư viện và cấu trúc dữ liệu hiệu quả (hoặc thậm chí tối ưu), theo quy định rằng tất cả các thuộc tính có liên quan của đầu vào đều được biết trước. Kết quả cuối cùng là:

• Mỗi phép biến đổi được xác định rõ là một sự tinh chỉnh các ràng buộc đã có (các thuộc tính đã biết);
• Chúng tôi để máy tính quyết định chuyển đổi nào là tối ưu dựa trên các ràng buộc hiện có.

Về lý do tại sao nó chưa xảy ra, khoa học máy tính là một lĩnh vực rất trẻ và chúng tôi vẫn đang đối phó với việc thực sự đánh giá cao sự mới lạ của hầu hết nó.

PS

Để cung cấp cho bạn một ý nghĩa của những gì tôi muốn nói bằng cách "tinh chỉnh việc thực hiện": ví dụ như vấn đề dễ dàng để có được yếu tố cuối cùng của danh sách, trong Prolog. Các giải pháp khai báo chính tắc là để nói:

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

Ở đây, ý nghĩa khai báo append/3là:

List1AndList2là sự kết hợp của List1vàList2

Vì trong đối số thứ hai append/3chúng ta có một danh sách chỉ có một phần tử và đối số thứ nhất bị bỏ qua (dấu gạch dưới), chúng ta có một phần của danh sách gốc loại bỏ phần trước của danh sách ( List1trong ngữ cảnh append/3) và yêu cầu mặt sau ( List2trong bối cảnh append/3) thực sự là một danh sách chỉ có một yếu tố: vì vậy, nó là yếu tố cuối cùng.

Các thực hiện thực tế được cung cấp bởi SWI-Prolog , tuy nhiên, nói:

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

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

Đây vẫn là tuyên bố độc đáo. Đọc từ trên xuống dưới, nó nói:

Phần tử cuối cùng của danh sách chỉ có ý nghĩa đối với danh sách ít nhất một phần tử. Phần tử cuối cùng cho một cặp đuôi và phần đầu của danh sách, sau đó là: phần đầu, khi phần đuôi trống hoặc phần cuối của phần đuôi không trống.

Lý do tại sao việc triển khai này được cung cấp là để giải quyết các vấn đề thực tế xung quanh mô hình thực thi của Prolog. Lý tưởng nhất, nó không nên tạo ra sự khác biệt mà việc thực hiện được sử dụng. Tương tự như vậy, chúng ta có thể nói:

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

Phần tử cuối cùng của danh sách là phần tử đầu tiên của danh sách đảo ngược.

Nếu bạn muốn nhận được đầy đủ các cuộc thảo luận không có hồi kết về những gì tốt, Prolog khai báo, chỉ cần xem qua một số câu hỏi và câu trả lời trong thẻ Prolog trên Stack Overflow .

Ngôn ngữ logic đã làm điều này. Bạn có thể định nghĩa sắp xếp tương tự như bạn đang làm điều đó.

Vấn đề chính là hiệu suất. Máy tính có thể rất giỏi trong việc tính toán rất nhiều thứ, nhưng chúng vốn đã bị câm. Mọi quyết định "thông minh" mà máy tính có thể đưa ra được lập trình viên đưa vào. Và quyết định này thường được mô tả không phải bằng cách kết quả cuối cùng trông như thế nào, mà bằng cách đạt được, từng bước, kết quả cuối cùng này.

Hãy tưởng tượng câu chuyện về một con Golem . Nếu bạn cố gắng đưa cho anh ta một mệnh lệnh trừu tượng, thì tốt nhất, anh ta sẽ làm điều đó không hiệu quả và tệ nhất, sẽ làm tổn thương chính anh ta, bạn hoặc người khác. Nhưng nếu bạn mô tả những gì bạn muốn một cách chi tiết nhất có thể, bạn được đảm bảo rằng nhiệm vụ sẽ được hoàn thành một cách hiệu quả và hiệu quả.

Công việc của lập trình viên là quyết định mức độ trừu tượng sẽ sử dụng. Đối với ứng dụng bạn đang thực hiện, bạn sẽ đi đến cấp độ cao và mô tả nó theo cách trừu tượng và đạt hiệu suất thấp hoặc bẩn, dành nhiều thời gian hơn cho nó, nhưng có được thuật toán hiệu suất cao hơn 1000 lần?

Ngoài điểm tuyệt vời của Euphoric , tôi muốn nói thêm rằng chúng tôi đã sử dụng ngôn ngữ khai báo ở nhiều nơi chúng hoạt động tốt, tức là mô tả trạng thái không có khả năng thay đổi hoặc yêu cầu thứ gì đó mà máy tính thực sự có thể tạo mã hiệu quả tự nó

• HTML tuyên bố nội dung của một trang web là gì.

• CSS tuyên bố các loại yếu tố khác nhau trong một trang web sẽ trông như thế nào.

• Mỗi cơ sở dữ liệu quan hệ có một ngôn ngữ định nghĩa dữ liệu khai báo cấu trúc của cơ sở dữ liệu là gì.

• SQL gần với khai báo hơn là bắt buộc, vì bạn nói với nó những gì bạn muốn thấy và trình hoạch định truy vấn của cơ sở dữ liệu tìm ra cách thực sự làm cho nó xảy ra.

• Người ta có thể lập luận rằng hầu hết các tệp cấu hình (.vimrc, .profile, .bashrc, .gitconfig) đang sử dụng ngôn ngữ dành riêng cho tên miền mà phần lớn là khai báo

Trừu tượng bị rò rỉ

Bạn có thể thực hiện một hệ thống khai báo nơi bạn khai báo những gì bạn muốn và trình biên dịch hoặc trình thông dịch chỉ ra một thứ tự thực hiện. Lợi ích về mặt lý thuyết là nó giải phóng bạn khỏi phải suy nghĩ về 'làm thế nào' và bạn không phải chi tiết hóa việc thực hiện này. Tuy nhiên, trong thực tế cho tính toán cho mục đích chung, bạn vẫn phải suy nghĩ về 'cách thức' và viết tất cả các loại thủ thuật trong khi ghi nhớ cách thực hiện này, vì nếu không trình biên dịch có thể (và thường sẽ) chọn một triển khai sẽ rất, rất, rất chậm (ví dụ n! hoạt động trong đó n sẽ đủ).

Trong ví dụ cụ thể của bạn, bạn sẽ nhận được một thuật toán sắp xếp - điều đó không có nghĩa là bạn sẽ có được một thuật toán tốt hoặc thậm chí có thể sử dụng được. Định nghĩa đã cho của bạn, nếu được triển khai theo nghĩa đen (như một trình biên dịch có thể sẽ dẫn đến http://en.wikipedia.org/wiki/Bogosort , không thể sử dụng cho các bộ dữ liệu lớn hơn - nó đúng về mặt kỹ thuật, nhưng cần một số vĩnh viễn để sắp xếp hàng nghìn số .

Đối với một số miền hạn chế, bạn có thể viết các hệ thống hầu như luôn hoạt động tốt để tìm ra một triển khai tốt, ví dụ: SQL. Đối với điện toán cho mục đích chung không hoạt động đặc biệt tốt - bạn có thể viết các hệ thống, giả sử, Prolog nhưng bạn phải hình dung chính xác cách khai báo của bạn sẽ được chuyển đổi thành lệnh thực thi bắt buộc và cuối cùng sẽ mất phần lớn khai báo dự kiến lợi ích lập trình.

Tính quyết định tính toán là lý do quan trọng nhất lập trình khai báo chưa được chứng minh là dễ dàng như nó có vẻ.

Nhiều vấn đề tương đối dễ nêu ra đã được chứng minh là không thể giải quyết được hoặc có độ phức tạp hoàn toàn NP để giải quyết. Điều này thường xảy ra khi chúng ta tính đến các lớp phủ định và phân loại, tính đếm và đệ quy.

Tôi muốn kiểm tra điều này với một số tên miền nổi tiếng.

Quyết định sử dụng lớp CSS nào cần có kiến ​​thức và xem xét tất cả các quy tắc CSS. Thêm quy tắc mới có thể làm mất hiệu lực tất cả các quyết định khác. Các lớp CSS phủ định không được thêm vào ngôn ngữ, vì các vấn đề hoàn thành NP, nhưng việc thiếu các lớp phủ định làm phức tạp các quyết định thiết kế CSS.

Trong trình tối ưu hóa truy vấn (SQL), có một vấn đề khó khăn khi quyết định nên tham gia vào thứ tự nào, chỉ số nào sẽ sử dụng và bộ nhớ nào sẽ phân bổ cho kết quả tạm thời nào. Đây là một vấn đề NP-đầy đủ đã biết và làm phức tạp việc thiết kế cơ sở dữ liệu và xây dựng truy vấn. Để hình thành nó một cách khác nhau: khi thiết kế cơ sở dữ liệu hoặc truy vấn, người thiết kế cần biết các hành động và thứ tự các hành động mà trình tối ưu hóa truy vấn có thể thực hiện. Một kỹ sư giàu kinh nghiệm cần kiến ​​thức về các heuristic được sử dụng bởi các nhà cung cấp cơ sở dữ liệu lớn.

Các tệp cấu hình là khai báo, nhưng các cấu hình nhất định khó khai báo. Ví dụ: để định cấu hình đúng các tính năng, người ta cần tính đến phiên bản tài khoản, triển khai (và lịch sử triển khai), có thể ghi đè thủ công và có thể xung đột với các cài đặt khác. Để xác thực hợp lệ một cấu hình có thể trở thành một vấn đề hoàn chỉnh NP.

Kết quả là những sự phức tạp này khiến người mới bắt đầu ngạc nhiên, chúng phá vỡ 'vẻ đẹp' của lập trình khai báo và chúng khiến một số kỹ sư tìm kiếm các giải pháp khác. Việc di chuyển các kỹ sư thiếu kinh nghiệm từ SQL sang NoQuery có thể đã được kích hoạt bởi sự phức tạp tiềm ẩn của cơ sở dữ liệu quan hệ.

Chúng tôi có một sự khác biệt về tính khử của các ngôn ngữ lập trình được sử dụng tốt trong việc xác minh logic kỹ thuật số.

Thông thường logic kỹ thuật số được mô tả ở mức truyền thanh ghi (RTL) trong đó mức logic của các tín hiệu giữa các thanh ghi được xác định. Để kiểm tra xem chúng ta đang ngày càng thêm các thuộc tính được định nghĩa theo cách trừu tượng và khai báo hơn.

Một trong những ngôn ngữ khai báo / tập hợp ngôn ngữ được gọi là PSL cho Ngôn ngữ Đặc tả Thuộc tính. Khi kiểm tra một mô hình RTL của một số nhân, trong đó, ví dụ, tất cả các hoạt động logic của sự thay đổi và thêm vào nhiều chu kỳ xung nhịp cần phải được chỉ định; bạn có thể viết một tài sản theo cách assert that when enable is high, this output will equal the multiplication of these two inputs after no more than 8 clock cycles. Mô tả PSL sau đó có thể được kiểm tra cùng với RTL trong một mô phỏng hoặc PSL có thể được chứng minh chính thức để giữ cho mô tả RTL.

Mô hình PSL khai báo nhiều hơn buộc người ta phải mô tả hành vi tương tự như mô tả RTL nhưng theo một cách đủ khác nhau có thể được kiểm tra tự động đối với RTL để xem họ có đồng ý hay không.

Chủ yếu là vấn đề là làm thế nào bạn mô hình hóa dữ liệu; và lập trình khai báo không giúp được gì ở đây. Trong các ngôn ngữ bắt buộc, bạn đã có hàng tấn thư viện cung cấp rất nhiều thứ cho bạn, vì vậy bạn chỉ cần biết phải gọi gì. Theo một cách cụ thể, người ta có thể xem xét lập trình khai báo này (có lẽ là ví dụ tốt nhất cho điều này là Stream API trong Java 8 ). Có điều này, sự trừu tượng đã được giải quyết và lập trình khai báo là không cần thiết.

Ngoài ra, như đã nói, các ngôn ngữ lập trình logic đã làm chính xác những gì bạn muốn. Người ta có thể nói vấn đề là hiệu suất, nhưng với phần cứng và nghiên cứu ngày nay trong lĩnh vực này, mọi thứ có thể được cải thiện để sẵn sàng cho việc sử dụng sản xuất; Thật ra Prolog được sử dụng cho công cụ AI, nhưng tôi chỉ tin vào giới hàn lâm.

Cần lưu ý rằng nó áp dụng cho các ngôn ngữ lập trình có mục đích chung. Đối với các ngôn ngữ cụ thể của miền, ngôn ngữ khai báo là cách tốt hơn; SQL có lẽ là ví dụ tốt nhất.

Nó sẽ trông giống như thế này .. {(bất cứ điều gì => đọc một tệp và gọi một url) | gọi một url và đọc một tệp} Tuy nhiên, đây là những hành động để thực thi và trạng thái của hệ thống thay đổi do kết quả, nhưng điều đó không rõ ràng từ nguồn.

Tuyên bố có thể mô tả một máy trạng thái hữu hạn và quá trình chuyển đổi của nó. FSM giống như đối nghịch với các tuyên bố không có hành động, ngay cả khi hành động duy nhất là thay đổi trạng thái sang trạng thái tiếp theo.

Ưu điểm của việc sử dụng phương thức này là các hiệu ứng chuyển tiếp và hành động có thể được chỉ định bởi các vị từ áp dụng cho nhiều chuyển đổi, thay vì chỉ một.

Tôi biết điều này nghe có vẻ hơi lạ, nhưng vào năm 2008 tôi đã viết một trình tạo chương trình sử dụng phương thức này và C ++ được tạo ra gấp từ 2 đến 15 lần so với nguồn. Bây giờ tôi có hơn 75.000 dòng C ++ từ 20.000 dòng đầu vào. Hai điều đi với điều này: tính nhất quán và đầy đủ.

Tính nhất quán: Không có hai vị từ có thể đúng cùng một lúc có thể ngụ ý các hành động không nhất quán, vì cả x = 8 và x = 9, cũng không khác nhau về các trạng thái tiếp theo.

Tính đầy đủ: Logic cho mọi chuyển đổi trạng thái được chỉ định. Chúng có thể khó kiểm tra các hệ thống có N trạm, với các trạng thái> 2 ** N, nhưng có các phương pháp tổ hợp thú vị có thể xác minh mọi thứ. Vào năm 1962, tôi đã viết giai đoạn 1 của một loại hệ thống cho 7070 máy, sử dụng loại tạo mã có điều kiện và gỡ lỗi tổ hợp này. Trong số 8.000 dòng trong số đó, số lượng lỗi từ ngày phát hành đầu tiên mãi mãi là con số không!

Giai đoạn hai của loại, 12.000 dòng, đã có hơn 60 lỗi trong hai tháng đầu tiên. Có nhiều hơn để nói về điều này, nhưng nó hoạt động. Nếu các nhà sản xuất ô tô sử dụng phương pháp này để kiểm tra phần sụn, chúng ta sẽ không thấy những lỗi mà chúng ta thấy bây giờ.

Không phải tất cả mọi thứ có thể được đại diện theo một cách khai báo.

Thông thường, bạn rõ ràng muốn kiểm soát luồng thực thi

Ví dụ sau mã giả: if whatever read a file call an URL else call an URL write a file Làm thế nào bạn đại diện cho nó khai báo?

Chắc chắn, có lẽ có một số cách kỳ lạ để làm điều đó. Giống như monads . Nhưng những thứ này thường cồng kềnh, phức tạp và ít trực quan hơn nhiều so với phần thủ tục của chúng.

Tất cả tập trung vào thực tế là "tương tác" với môi trường / hệ thống của bạn không phải là khai báo. Tất cả mọi thứ liên quan đến I / O đều mang tính thủ tục. Bạn phải nói chính xác khi nào và điều gì sẽ xảy ra, và theo thứ tự nào.

Tuyên bố là tuyệt vời cho tất cả mọi thứ hoàn toàn liên quan đến tính toán. Giống như một hàm khổng lồ, bạn đặt X vào và bạn nhận được Y. Thật tuyệt vời. Một ví dụ cho điều này là HTML, đầu vào là văn bản, đầu ra là những gì bạn thấy trong trình duyệt của mình.