Xây dựng DSL: Viết kịch bản trên một ngôn ngữ có mục đích chung hay độc lập?

10

Tôi đang tranh luận về việc thiết kế một ngôn ngữ cụ thể cho miền để đơn giản hóa một mô hình lập trình tối nghĩa nhất định. Một phần của cuộc tranh luận là liệu có nên xây dựng nó (dưới dạng tập lệnh) trên một ngôn ngữ / thời gian chạy hiện tại (ví dụ Java) hay để làm cho nó độc lập (trình biên dịch riêng, & c).

Những bạn có kinh nghiệm thiết kế DSL, bạn có ưu / nhược điểm và câu trả lời chắc chắn cho cách tiếp cận phù hợp không?

— Hàng đợi
nguồn

Ai là người tiêu dùng của DSL này? và các máy chủ tiềm năng là gì (bạn đã đề cập đến Java, bạn đang xem xét các khả năng khác)?

— Mauricio Scheffer

Tôi xem xét bất kỳ khả năng cho các máy chủ. Người tiêu dùng sẽ là những người viết chương trình không đồng bộ (tin nhắn có điểm đến).

— Jé Queue

9

Tôi khuyên bạn nên tạo DSL của bạn trên một ngôn ngữ hiện có (DSL nội bộ). Tôi đã thực hiện điều này một vài lần với Python, tạo ra các hệ thống trong đó người tiêu dùng DSL viết một tệp python được sử dụng làm tệp cấu hình cho hệ thống. Tệp cấu hình sử dụng các cấu trúc (lớp, hàm) mà tôi đã xác định. Các cấu trúc này tạo thành DSL.

IMO, một ngôn ngữ như Python (IronPython hoặc Jython nếu hệ thống máy chủ là .NET hoặc Java) hoặc Ruby (IronRuby, JRuby) sẽ tốt hơn cho việc dựa trên DSL của bạn so với Java hoặc C #.

Trong trường hợp của tôi, các hệ thống máy chủ cũng là (C) Python, vì vậy việc chọn Python cho DSL là điều đương nhiên.

Một số ưu điểm:

Chi phí xây dựng thấp hơn. Có rất ít để bạn thực hiện. Bạn có thể tập trung vào vấn đề trong tay thay vì dành thời gian để thực hiện trình phân tích cú pháp / trình biên dịch / trình thông dịch.
Truy cập vào ngôn ngữ máy chủ: Ngôn ngữ của bạn sẽ có quyền truy cập vào toàn bộ sức mạnh của ngôn ngữ / nền tảng hiện có.

— mật mã
nguồn

Tôi không biết ngôn ngữ, nhưng tại sao bạn nghĩ rằng hóa thân Python phù hợp hơn?

— Jé Queue

1

Phù hợp hơn những gì? Tôi đoán Ruby và Python có nhiều lợi ích giống nhau, Ruby thậm chí có thể phù hợp hơn với DSL nội bộ vì cú pháp linh hoạt hơn. Đối với Java và C #, tôi đã thấy nhiều giao diện lưu loát trong các ngôn ngữ đó (và có các cấu trúc trong các phiên bản mới hơn giúp cho việc tạo / sử dụng DSL bên trong dễ dàng hơn, như cú pháp khởi tạo đối tượng) - nhưng IMO là ngôn ngữ "lễ thấp" phù hợp hơn một chút so với ngôn ngữ "lễ cao".

— codeape

1

Tôi đã chọn C # để triển khai DSL chính xác bên trong để tận dụng kiểm tra kiểu tĩnh thời gian biên dịch "miễn phí". DSL ngôn ngữ động không cung cấp quá nhiều lợi thế so với DSL bên ngoài.

— Den

@Den đó chính xác là điều làm tôi thất vọng khi tôi đã thử làm iDSL bằng Python. Trong Java, iDSL của bạn cảm thấy như nó nhận được sự hỗ trợ tức thì từ IDE. Không tìm thấy một IDE sẽ làm điều đó cho Python.

— candied_orange

2

Hãy xem Xtext (http://www.eclipse.org/Xtext/) và Xbase (http://blog.efftinge.de/2010/09/xbase-new-programming-lingu.html). Nếu người dùng không phải là lập trình viên, tôi không nghĩ bạn nên căn cứ DSL của mình vào ngôn ngữ lập trình hiện có. Nó sẽ quá phức tạp đối với họ. DSL "sạch" có thể rất hiệu quả nếu được thực hiện đúng.

— Henrik
nguồn

2

Thay vì đề xuất một cách tiếp cận cụ thể, cho phép tôi đề xuất Ngôn ngữ dành riêng cho miền của Martin Fowler như một nguồn tài nguyên tuyệt vời để đưa ra quyết định. Nó có một cuộc kiểm tra sâu rộng, kích thích tư duy về giá trị tương đối của DSL bên trong và bên ngoài.

— trứng
nguồn

1

Có một tùy chọn thứ ba - xây dựng DSL như một trình biên dịch trên đỉnh của ngôn ngữ mục đích chung. Bất kỳ ngôn ngữ nào có một số mức độ hợp lý của khả năng siêu lập trình sẽ thực hiện công việc, kể cả những thứ cấp thấp như C ++. Tôi thích Lisp và các ngôn ngữ tương tự cho loại điều này, nhưng Template Haskell hoặc Nemerle cũng có thể cung cấp mức độ linh hoạt tương tự.

— SK-logic
nguồn

1

Trong cuốn sách "Ngôn ngữ dành riêng cho miền", Martin Folwer mô tả các DSL bên trong và bên ngoài .
Internal DSL= là tập hợp con của ngôn ngữ lập trình hiện có, ví dụ: Ruby / Java, v.v.
External DSL= bạn xác định cú pháp và từ vựng.
Một DSL bên ngoài có thể biểu cảm hơn nhiều, nhưng có thể yêu cầu phân tích cú pháp bên ngoài và tạo mã.
Mặc dù DSL nội bộ không yêu cầu xử lý bổ sung, nhưng đôi khi khó hiểu đối với các chuyên gia tên miền không lập trình (ví dụ: nhà phân tích kinh doanh, người kiểm tra).

Khi chọn loại DSL của bạn, điều quan trọng là phân tích người dùng của nó là ai. Nếu họ chủ yếu là những người không có kỹ thuật, thì DSL bên ngoài có thể là lựa chọn tốt hơn. Đối với một nhóm nhỏ lập trình viên có kinh nghiệm, có thể chọn DSL nội bộ, nếu ngôn ngữ lập trình họ sử dụng đủ biểu cảm.

— Olha Pavliuk
nguồn