Lập trình hướng ngôn ngữ có thực tế không?

Tôi đọc bài viết này về Lập trình hướng ngôn ngữ. Ông chỉ ra một số điểm yếu trong cách tiếp cận thủ tục / OOP hiện đại đối với lập trình và gợi ý một mô hình lập trình mới sẽ giải quyết chúng

Tôi hoàn toàn dành cho các phần chương trình nhỏ, kết hợp lỏng lẻo: Sẽ tốt hơn nhiều nếu học được nhiều điều nhỏ, tất cả những gì bạn sẽ sử dụng, hơn là một vài điều lớn, mà bạn chỉ sử dụng các bit và phần.

Đọc bài báo, tôi có ấn tượng rằng tác giả đang quảng bá một trong hai điều:

• Vô số ngôn ngữ kịch bản dễ tạo
• Một ngôn ngữ duy nhất, dễ mở rộng có thể tự viết lại để đáp ứng nhu cầu của lập trình viên

Nếu anh ấy gợi ý lần thứ hai, tôi sẽ trả lời "Đã xong!" và đưa Lisp làm ví dụ. Như Paul Graham gợi ý, các ngôn ngữ dường như vẫn đang tiếp tục di chuyển về phía này .

Theo như những gì đầu tiên có liên quan, tôi nghĩ rằng đây là một ý tưởng tốt, nếu có một ngôn ngữ cơ bản gắn kết tất cả chúng lại với nhau. Đó dường như là điểm yếu của tôi: giao tiếp giữa các ngôn ngữ. Bạn có sử dụng các cuộc gọi, đó là một khái niệm thủ tục hoặc truyền tin nhắn, nhắc nhở tôi về giao tiếp giữa các quá trình không? Tôi sẽ hoan nghênh cơ hội làm việc với các ngôn ngữ cụ thể của tên miền nhỏ, nếu việc sử dụng tất cả chúng cùng một lúc dễ dàng. Cách tiếp cận này (LOP) sẽ thực tế?

Tôi đã ủng hộ DSL trong một thời gian dài, nhưng tôi lo lắng về những gì xảy ra với Ý tưởng tốt khi chúng trở thành băng thông. Các sản phẩm được xây dựng để quảng cáo Ý tưởng tốt, hứa hẹn tất cả những gì bạn phải làm là có được một sản phẩm và bạn sẽ ở trong nhóm, mà không phải suy nghĩ rất kỹ về ý nghĩa của nó.

Ngôn ngữ là gì? Đó là một từ vựng và cú pháp trong đó ý nghĩa có thể được truyền đạt, phải không? Mỗi khi bạn khai báo một biến, viết một hàm, định nghĩa một lớp, bạn đang xây dựng một ngôn ngữ mới, bằng cách thêm các danh từ và động từ vào một ngôn ngữ hiện có. Bây giờ bạn có thể nói những điều trong đó mà bạn không thể trước đây.

Tôi nghĩ điều làm cho một ngôn ngữ cụ thể là một phạm vi mà nó thể hiện một cách tự nhiên các khái niệm tinh thần đang được truyền đạt và tôi nghĩ rằng có một biện pháp đơn giản về điều đó. Về cơ bản, nếu có một yêu cầu độc lập X độc lập đơn giản, có thể được bao gồm trong chương trình hay không, thì việc thực hiện chính xác của nó đòi hỏi một số bộ chèn mã, xóa và thay thế Y. Một khác biệt trước và sau đơn giản có thể hiển thị Y. Số N của những thay đổi đó là thước đo mức độ cụ thể của ngôn ngữ. N càng nhỏ, đối với các yêu cầu điển hình, càng tốt.

Nó không nhất thiết phụ thuộc vào cú pháp ưa thích, cấu trúc điều khiển, truyền tin nhắn hoặc những gì có bạn. Những gì nó phụ thuộc vào là làm thế nào chính xác nó thực hiện các yêu cầu. Nhiều công cụ sẽ yêu cầu thực hiện việc này, nhưng yêu cầu không thực tế. Nó phải là thật .

Đôi khi một công nghệ bất thường là cần thiết. Đây là ví dụ yêu thích của tôi. Khi đó, nó minh họa điểm mà nó có thể đòi hỏi nỗ lực từ phía các lập trình viên để hiểu nó. Vì vậy, tính đặc hiệu của miền (và khả năng bảo trì) hoàn toàn không giống với khả năng đọc .

Vì vậy, tôi đồng ý với cách tiếp cận thứ hai, rằng một ngôn ngữ tốt là ngôn ngữ dễ dàng cho phép người ta xây dựng các ngôn ngữ cần thiết trên đầu trang. (Đó là những gì tôi thích về Lisp.) Nhưng điều quan trọng hơn nữa là các lập trình viên cần biết cách xây dựng ngôn ngữ để phù hợp với lĩnh vực họ đang làm việc và sẵn sàng leo lên các đường cong học tập của các ngôn ngữ đó.

Tôi không thực sự thấy điều đó xảy ra. Thay vào đó, họ bị mắc kẹt trong "chương trình = thuật toán + cấu trúc dữ liệu" hoặc "danh từ trở thành lớp và động từ trở thành phương thức" phương thức suy nghĩ xoay vòng. Họ không làm việc về cách lấy các miền suy nghĩ và ngôn ngữ hóa chúng để có sự điều chỉnh tối đa.

Đó hoàn toàn là cách tiếp cận của Ruby.

• Giữ ngôn ngữ cốt lõi đơn giản và mở rộng thông qua đá quý
• Tạo phương ngữ của Ruby cho các miền cụ thể thông qua việc vá khỉ. ig Ruby trên đường ray.

Tôi không biết nếu điều này tốt hơn, nhưng tôi đoán là rất thực dụng.

Cách tiếp cận LOP là vô cùng thiết thực. Hãy nhớ rằng bạn không nhất thiết phải thực hiện "ngôn ngữ kịch bản" - phương pháp này cũng có thể áp dụng cho eDSL và chúng thường được biên dịch một cách hiệu quả. Tôi đang sử dụng phương pháp này trong tất cả các công việc phát triển của tôi.

Chúng ta sẽ thấy nhiều hơn về Ngôn ngữ cụ thể của miền trong tương lai, được đánh giá bởi những người đang nói về chúng bây giờ - Tôi đã nhận thấy Martin Fowler cũng nói về chúng rất nhiều và một vài bài viết thú vị qua Lambda The Ultimate về chủ đề này, trong số những người khác.

Điều đó cho tôi thấy rằng đây chắc chắn là một hướng mà gió thổi vào liên quan đến thiết kế ngôn ngữ lập trình và nền tảng lập trình. Theo một số cách, nó đã được một thời gian rồi - một trong những lợi thế của Ruby (như một số người đã quan sát) là nó giúp tạo ra DSL dễ dàng nhưng thực sự có rất nhiều chúng xung quanh trong các ứng dụng và thư viện lập trình mà chúng ta đã sử dụng.

Tôi đang sử dụng LOP bất cứ khi nào lập trình solo. Tôi thấy rằng trong một số dự án, không có cách nào khác để đáp ứng lịch trình. Trong một câu chuyện ngụ ngôn đơn giản, người ta có thể đánh đồng việc sử dụng LOP cho các công cụ quyền lực. Nếu bạn đang làm việc một mình trong xưởng, bạn không thể làm mọi thứ thủ công và đáp ứng thời hạn. Nếu có những người khác đi cùng bạn, việc phối hợp sử dụng các công cụ quyền lực đó là điều cần thiết cho hiệu quả và an toàn.
Trong chế độ nhóm, LOP yêu cầu chuẩn bị tổ chức để tránh thảm họa Tháp Babel.