Khi nào thì hợp lý để tạo ngôn ngữ lập trình của riêng tôi?

Có các loại ứng dụng sát thủ, các lớp vấn đề thuật toán, v.v., về lâu dài, nơi nào tốt hơn để tạo ra ngôn ngữ của riêng tôi?

PS: Để chắc chắn, ý tôi là một ngôn ngữ lập trình mới và một trình biên dịch, không phải là một trình biên dịch mới cho một ngôn ngữ hiện có.

EDIT : Cảm ơn bạn đã trả lời. Bạn có thể cung cấp một số ví dụ, nơi hoàn toàn không cần thiết để tạo DSL hoặc các trường hợp trong đó DSL có thể là một ý tưởng tốt?

Nó chắc chắn có liên quan đến một người để viết ngôn ngữ của họ cho mục đích giáo dục. Để tìm hiểu về thiết kế ngôn ngữ lập trình và về thiết kế trình biên dịch. Nhưng sử dụng trong thế giới thực là rất ít và xa.

Trong việc viết ngôn ngữ của riêng bạn, bạn là:

• Thêm một số lượng lớn phức tạp cho vấn đề của bạn
• Thêm một lượng công việc đáng kể bằng văn bản và duy trì ngôn ngữ và trình biên dịch mới

Vì vậy, nếu bạn có kế hoạch viết ngôn ngữ của riêng bạn cho dự án của bạn thì các tính năng mà nó cung cấp mà các ngôn ngữ khác không cần phải bù đắp chi phí trên.

Lấy trò chơi phát triển chẳng hạn. Họ thường cần các ngôn ngữ nhỏ trong các trò chơi hoặc ngôn ngữ kịch bản của họ. Họ sử dụng các ngôn ngữ này để viết ra một số lượng lớn các sự kiện trong trò chơi xảy ra. Tuy nhiên, ngay cả trong trường hợp này, họ hầu như luôn chọn các ngôn ngữ kịch bản lệnh hiện có và điều chỉnh chúng theo nhu cầu của họ.

Hãy để tôi chỉ trích dẫn Paul Vick, cựu nhà phát triển của trình biên dịch VB và hiện đang làm việc trên Project Oslo và ngôn ngữ M:

Thật khó khăn để xây dựng một ngôn ngữ mới, thậm chí rất khó để xây dựng một ngôn ngữ mới, thậm chí một ngôn ngữ chủ yếu dựa trên ngôn ngữ hiện có. Tuy nhiên, nhiều lập trình viên nghĩ rằng, thì hey, tôi sử dụng các ngôn ngữ, điều này có thể khó đến mức nào? Có lẽ hơn 98% trong số họ không đạt được bất kỳ lực kéo nào, nhưng chúa phù hộ cho những người lạc quan bởi vì không có họ, chúng tôi sẽ không bao giờ có được 2% ngôn ngữ thành công. Cá nhân tôi sẵn sàng hy sinh hàng triệu đô la và hàng giờ lãng phí cho các ngôn ngữ không bao giờ làm cho nó trở nên đơn giản để chúng tôi có thể có được các ngôn ngữ như C # và Java và Ruby và Python, v.v.

Vì vậy, việc đưa ra một ngôn ngữ mới là một ý tưởng tồi không nên ngăn cản mọi người phát triển DSL mới, nó chỉ nên cho họ tạm dừng và hy vọng một chút khiêm tốn. Chìa khóa, tôi nghĩ, là bắt đầu nhỏ và giữ nhỏ.

DSL: Chắc chắn là một ý tưởng tồi!

Khi nào thì hợp lý?

Khi bạn cảm thấy thích nó!

Đừng nghe những người có những bình luận ngớ ngẩn mà về cơ bản nói:

"Đừng làm điều đó bởi vì nó quá khó và ngôn ngữ X tốt hơn bất kỳ ngôn ngữ nào bạn có thể nghĩ ra".

Vấn đề là, tạo DSL luôn luôn xảy ra. Một khung là DSL. Một macro là một DSL. Mỗi khi bạn viết một chức năng cho chương trình của mình, đó là một phần của DSL. Chắc chắn, nó nằm trong giới hạn của ngữ pháp, nhưng từ vựng là một phần của ngôn ngữ. Đây là lý do tại sao các ngành công nghiệp thường tạo ra tiếng địa phương của riêng họ: hiệu quả hơn!

Nếu "không làm điều đó" là câu trả lời đúng, tất cả chúng ta sẽ viết COBOL và Fortran.

Bạn có thể muốn đọc các phần của cuốn sách DSL sắp ra mắt của Martin Fowler , nếu bạn đang nghĩ đến việc viết ngôn ngữ của riêng bạn.

Tôi thực sự không thể nghĩ ra một trường hợp kinh doanh để tạo ra một ngôn ngữ từ đầu ngoài việc nó là một kinh nghiệm học tập tuyệt vời.

Chỉnh sửa: đối với DSL có rất nhiều trường hợp kinh doanh, nhưng chìa khóa ở đây không phải là mang đi và Giữ cho nó đơn giản.

Tôi đề nghị rằng các câu hỏi chính là "Tôi đang cố gắng giải quyết vấn đề gì?" và "Ai có được ROI?"

Nếu bạn đang cố gắng xây dựng các kỹ năng và kinh nghiệm của riêng mình, thì hãy tăng tốc hết mức, nhưng không phải trong một hệ thống sản xuất được cho là để giải quyết vấn đề của người khác.

Có vẻ như lý do chính mà bạn muốn có một ngôn ngữ mới là bạn bắt đầu khám phá các mẫu trong mã của mình mà các ngôn ngữ hiện tại không xử lý tốt. Nhưng có một loạt các vấn đề với việc tạo ngôn ngữ của riêng bạn. Bạn sẽ bỏ lỡ tất cả các thư viện và khung được xây dựng cho các ngôn ngữ hiện có. Bạn sẽ dành nhiều thời gian để thiết kế và thực hiện ngôn ngữ mới, đó là tất cả thời gian bạn không phải dành cho nhiệm vụ lập trình thực sự. Bạn sẽ dành rất nhiều nỗ lực để thuyết phục các nhà phát triển khác rằng họ nên sử dụng ngôn ngữ của bạn. Và, bạn sẽ có một thời gian khó khăn để tuyển dụng và đào tạo các nhà phát triển mới.

Tại sao không viết bằng một ngôn ngữ như Lisp cho phép bạn mở rộng ngôn ngữ khi bạn khám phá các mẫu mới? Sau đó, bạn có được tất cả sức mạnh của một ngôn ngữ mới với tất cả những lợi ích của một ngôn ngữ đã được thiết lập.

Một lý do có thể là tạo ra nó như một thử nghiệm để tìm hiểu về thiết kế ngôn ngữ và xây dựng trình biên dịch.

Một lý do khác có thể là xây dựng ngôn ngữ kịch bản thành ứng dụng khi bạn không có tùy chọn để thêm API của bên thứ ba.

Tôi không nghĩ bạn có thể lập trình mà không tạo ra một ngôn ngữ mới, vì vậy thật tốt khi nhận ra đó là những gì bạn đang làm và hiểu vấn đề.

• Một ngôn ngữ là gì?
  Từ vựng, cú pháp và ngữ nghĩa.

Một ngôn ngữ ngoài luồng như VB, Java, C #, v.v. chỉ là ngôn ngữ cơ bản . Ngay khi bạn thêm các lớp học, phương thức, v.v. vào đó, bạn đã thêm từ vựng và ngữ nghĩa. Có nhiều cách để thực hiện các ngôn ngữ - phân tích cú pháp & dịch, phân tích cú pháp & phiên dịch, macro trên đầu ngôn ngữ hiện có, thêm các lớp & phương thức vào ngôn ngữ hiện có.

• Bạn muốn một ngôn ngữ để làm gì?
  Hãy tốt để thể hiện vấn đề chính xác.

Làm thế nào để bạn biết nếu bạn đã làm điều này? Các biện pháp tôi sử dụng là số lượng chỉnh sửa . Nếu yêu cầu một câu A xuất hiện, tôi tiến hành thực hiện yêu cầu trong mã. Khi tôi hoàn thành và nhận được tất cả các lỗi, tôi kiểm tra mã và kho lưu trữ mã cung cấp cho tôi danh sách các thay đổi tôi đã thực hiện, B. B càng nhỏ, ngôn ngữ càng tốt. Tính trung bình trên không gian của các yêu cầu thực tế & có thể, biện pháp đó cho tôi biết ngôn ngữ "cụ thể theo miền" như thế nào.

• Tại sao sự đồng nhất là tốt?
  Bởi vì nó giảm thiểu lỗi.

Nếu phải thay đổi mã N để thực hiện 1 yêu cầu và đôi khi bạn mắc lỗi, thì số lỗi bạn giới thiệu gần như tỷ lệ với N. Trong giới hạn mà N = 1, gần như không thể đưa ra lỗi mà không cố gắng.

Lưu ý rằng đây là một thách thức trực tiếp đối với "sự phình to mã" mà chúng ta thấy ngày nay.

THÊM: Để đáp ứng yêu cầu của bạn cho một ví dụ, xem thực hiện khác biệt . Tôi sẽ không nói nó có thể được hiểu một cách nhanh chóng, nhưng nó làm giảm đáng kể mã UI.

Luôn luôn là "khả thi", để sử dụng từ trong câu hỏi (bản gốc) của bạn, nhưng nó không thường rất hữu ích và rất hiếm khi tối ưu với sự phong phú của các ngôn ngữ và khung được hỗ trợ tốt và trưởng thành tồn tại.

Đó là một thách thức trí tuệ thú vị, tuy nhiên.

Chỉ khi hoạt động kinh doanh cốt lõi của nhóm bạn là ngôn ngữ lập trình.

Tôi đã làm việc trên một ngôn ngữ lập trình được tạo ra trong một công ty tài chính.

Rõ ràng, đối với bản thân kiến ​​trúc sư, đây là một thách thức lớn và cải thiện kỹ năng của chính mình.

Chắc chắn, ngôn ngữ không thể phát triển hoặc cải thiện ở bất cứ nơi nào gần với tốc độ mà một thứ như C # hoặc Java có thể - họ có các nhóm chuyên làm việc đó.

Ngôn ngữ sớm bị đình trệ vì không ai mới muốn nhận nhiệm vụ cải thiện dự án thú cưng của người khác.

Kiến trúc sư ban đầu rời đi. Ngôn ngữ khô héo và chết sau 10 năm.

10 năm đó là địa ngục đối với bất cứ ai gặp bất hạnh khi làm việc với ngôn ngữ bế tắc.

Vì vậy, hãy tiếp tục, tạo ngôn ngữ của riêng bạn nhưng vui lòng không yêu cầu bất kỳ ai khác thực sự sử dụng ngôn ngữ đó. Xin đừng mong đợi bất cứ ai khác cảm ơn bạn cho nó.

Thiết kế ngôn ngữ có thể thú vị. Nhưng bạn không cần phải tự giới hạn ngôn ngữ lập trình.

Nếu tôi xây dựng một ứng dụng phức tạp vừa phải, tôi muốn thêm một loại ngôn ngữ macro / script để giúp thực hiện các tác vụ lặp đi lặp lại phức tạp dễ dàng hơn. Hầu hết người dùng sẽ không sử dụng chức năng này, nhưng một số ít sử dụng nó rất biết ơn. Bên cạnh đó, tôi chắc chắn rằng nó có giá trị cho những người hỗ trợ để giúp họ khắc phục các vấn đề của khách hàng.

Hoàn toàn hợp lý nếu được thực hiện để mở rộng các kỹ năng của bạn và học hỏi.

Ngoài ra, nếu bạn phải đặt câu hỏi, thì không. Nếu bạn đang cố gắng tìm hiểu xem bạn có thể đối phó với một loại thuật toán nhất định hoặc một miền vấn đề nhất định tốt hơn các ngôn ngữ hiện có hay không, trước tiên bạn cần phải là một chuyên gia trong lĩnh vực bạn đang giải quyết. Bạn sẽ biết nó phù hợp khi kỹ năng và kinh nghiệm của bạn nói với bạn như vậy.

Và bạn cũng có thể sai về điều đó, nhưng bạn cần một chuyên gia khác để thuyết phục bạn về điều đó (hoặc để cho bạn thấy rằng bạn không phải là chuyên gia mà bạn nghĩ là bạn). Một cuộc thảo luận sôi nổi, không phải là một câu hỏi và trả lời đơn giản như bạn sẽ tìm thấy ở đây.

Ngoại trừ mục đích tự giáo dục, tôi muốn khẳng định rằng ngày nay không cần bất cứ điều gì để tạo ra ngôn ngữ của riêng bạn. Trong mọi hoàn cảnh. Không bao giờ. Bất kể những gì bạn muốn làm, có rất nhiều ngôn ngữ hiện có bạn có thể sử dụng / thích ứng với nhu cầu của bạn.

Nó chắc chắn phụ thuộc vào tình hình. Như nosklo đã nói - Nếu bạn có một ý tưởng hay, một khái niệm hoàn toàn mới hoặc một cái gì đó tương tự tôi rất khuyên bạn nên làm điều đó.

Nói chung tôi sẽ đề nghị dựa vào công nghệ được thiết lập.

Nhưng nếu bạn quan tâm đến việc tạo ra "ngôn ngữ" của riêng mình, bạn nên xem: YACC & Lex

Bạn có thể, đừng bắt mình trong mô hình chống "Tái tạo bánh xe vuông".

Có nghĩa là bạn đang tạo lại những gì đã được thực hiện, chỉ kém hơn so với (các) bản gốc.

Wouter được biết đến với việc tạo ra một ngôn ngữ mới cho bất kỳ ý tưởng mới nào. Bạn có thể lấy cảm hứng từ công việc của anh ấy: trang ngôn ngữ lập trình của Wouter .

Khi nào tạo ngôn ngữ của riêng bạn?

Khi bạn muốn, như một dự án sở thích lớn.

Đối với một ngôn ngữ cụ thể miền. Đây có thể là khá phức tạp; nhìn vào những gì diễn ra trong cộng đồng Tiểu thuyết tương tác (hoặc phiêu lưu văn bản) bằng cách xem kho lưu trữ .

Khi mục tiêu của bạn rất tham vọng, và bạn nghĩ rằng bạn có thể tiến bộ thực sự, như dự án Arc của Paul Graham .

Ngoài ra, trong bất kỳ ngôn ngữ nào có thể thích ứng đủ (có lẽ là C ++, chắc chắn là Lisp chung) trong quá trình phát triển các cấu trúc cấp thấp.

Khi nào nên tránh nó như bạn, tôi hy vọng, tránh một sáo ngữ như tránh nó như bệnh dịch hạch?

Khi đó là cơ sở để tiếp tục phát triển cho các dự án thực sự. Nó sẽ luôn luôn bị tụt hậu nghiêm trọng đằng sau những gì thương mại có sẵn với giá rẻ, và sẽ làm tê liệt sự phát triển hơn nữa. Tôi đã làm việc cho một công ty với phiên bản COBOL của riêng mình và không bao giờ muốn làm việc tại một công ty khác duy trì ngôn ngữ của riêng mình. Chúng tôi đã xem các phiên bản khác của COBOL có các khả năng tốt hơn và các công cụ tốt hơn, trong khi chúng tôi bị mắc kẹt với các vấn đề tương tự. (Tôi không muốn làm việc với COBOL một lần nữa, nhưng đó là một câu chuyện khác.)

Các tình huống trong đó bạn có thể tạo ngôn ngữ của riêng mình không rơi vào trường hợp này. Dự án sở thích không được sử dụng để phát triển thực sự. Một cái gì đó như Arc sẽ thành công (và nhận được nhiều triển khai và tiến hóa và phát triển hơn nữa) hoặc thất bại (và không ai khác sẽ sử dụng nó). Một ngôn ngữ dành riêng cho tên miền nhỏ chỉ là một phần của dự án và vì nó nhỏ nên nó có thể được cải thiện theo thời gian. Một ngôn ngữ phiêu lưu văn bản được sử dụng để viết các trò chơi riêng lẻ và những trò chơi đó, ngoài việc là các dự án sở thích, gần như không bao giờ được sử dụng để tiếp tục phát triển.

Quan điểm của tôi là DSL nói chung là một "ý tưởng yếu" và về lâu dài sẽ hiệu quả hơn khi sử dụng ngôn ngữ tiêu chuẩn và xây dựng các nhu cầu cụ thể theo tên miền của bạn như một thư viện của "không phải DSL".

Tuy nhiên, có thể hóa ra là nhu cầu của bạn đủ tùy chỉnh để có DSL (không chỉ là triển khai gcc hoặc lisp được sửa đổi một chút) cho công ty của bạn. Nhiều công ty sử dụng các ngôn ngữ hiện tại nhắm vào những gì họ đang làm mà không cần viết / duy trì ngôn ngữ của họ. Ví dụ, tôi đã nghe nói rằng PHP có một trình quản lý tốt; Lua được thiết kế xung quanh là một phần thả xuống, ModelView sử dụng Python và AutoCAD có AutoLISP làm tập lệnh của nó.

Không có gì sai khi viết ngôn ngữ lập trình của riêng bạn nếu bạn có thể tận dụng các công cụ hiện có. Trong thế giới ngày nay, điều này có nghĩa là bạn xác định nó theo cú pháp có thể sử dụng được bằng ngôn ngữ hiện có (như Java hoặc C #) hoặc viết một hệ thống chuyển đổi nhỏ (bộ mở rộng macro) tạo mã bằng ngôn ngữ hiện có.

Đi tất cả các cách để mã máy đang phát minh lại rất nhiều bánh xe ...

Một lý do rất chính đáng cho DSL là thể hiện dữ liệu miền theo cách cô đọng. Điều này cho phép các chuyên gia tên miền làm việc trực tiếp với dữ liệu thay vì phải thông qua người khác. Bí quyết sau đó là có các chương trình kết quả ở dạng dễ xử lý.

Nói chung, câu trả lời sẽ là KHÔNG lớn. Trong số hàng trăm ngôn ngữ ngoài kia thường có một ngôn ngữ sẽ phù hợp với vấn đề của bạn.

Tuy nhiên, có một số trường hợp là một lựa chọn hợp lý để phát triển một ngôn ngữ mới: -

• Khi một trong những đối thủ của bạn hiện đang sở hữu một trong những nền tảng phát triển chính của bạn. Tôi đang nghĩ về sự phụ thuộc hiện tại của Googles vào Java và sự phát triển "đi" của họ, (nó giúp nếu bạn có một tác giả của ngôn ngữ thành công nhất từng có trong bảng lương!).
• Khi bạn phải viết một tấn mã cho một nền tảng mới và các ngôn ngữ hiện tại là dài dòng và dễ bị lỗi - ví dụ: php để phát triển web.
• Khi bạn gặp phải các vấn đề về quy mô và song song chưa từng gặp trước đây bởi vì chưa ai từng có phần cứng này để xử lý nhiều dữ liệu này trước đây - ví dụ Scala và (ở một mức độ nhất định GO).

Ngôn ngữ nào tốt là thành phần hoặc đặt các thành phần giống nhau theo những cách khác nhau.

Nếu vấn đề tên miền của bạn chỉ cần bạn thiết lập một loạt các công tắc trực giao, một ngôn ngữ có thể không thêm nhiều biểu mẫu, giao diện người dùng đồ họa hoặc cấu hình văn bản thẳng. tập tin. (Tôi giả sử ở đây rằng một tệp chứa đầy các khóa, các cặp giá trị không phải là "ngôn ngữ" của bạn.)

OTOH, nếu cấu hình của bạn giống như ngôn ngữ thực, vd. động từ và danh từ có thể được kết hợp thành nhiều cách kết hợp khác nhau (và tiểu thuyết) với bất kỳ mức độ phức tạp nào, sau đó một ngôn ngữ sẽ trở nên gần như không thể tránh khỏi, bởi vì sự bùng nổ kết hợp của việc cố gắng chỉ định những gì bạn muốn bằng bất kỳ phương pháp nào khác.

Học các bài tập sang một bên, thật hợp lý khi chỉ tạo ngôn ngữ lập trình của riêng bạn khi bạn hiểu các ngôn ngữ khác, miền vấn đề cụ thể của bạn và cách ngôn ngữ hiện tại giải quyết miền vấn đề đó và sự hiểu biết này đủ kỹ lưỡng để bạn biết một ngôn ngữ mới là hợp lý Giải pháp mà không cần đặt câu hỏi.

Lần cuối cùng tôi bắt đầu thực hiện điều đó trong một dự án sở thích, tôi bắt đầu chỉ định những gì tôi muốn cú pháp trông giống như thế nào và nhận ra giữa chừng tôi đang phát minh lại prolog. Các ngôn ngữ khác có thể phù hợp khi bạn nghĩ rằng bạn cần phát minh ra một ngôn ngữ là lisp, lua hoặc một cái gì đó như Haskell. Về cơ bản, tất cả những ngôn ngữ bạn bỏ qua ở trường đại học bởi vì bạn nghĩ rằng chúng sẽ không bao giờ hữu ích.

Một lý do là cho mục đích giáo dục, như đã nêu. Nhưng có nhiều hơn nữa. Ví dụ: có nhiều ngôn ngữ nghiên cứu như Sing#trên hệ điều hành Singularity và BitCtrên Coyotos đã được thiết kế vì các ngôn ngữ hiện tại không cung cấp các tính năng cần thiết (ví dụ: xác minh ở cấp độ ngôn ngữ).

Tom Van Cutsem gần đây đã viết một câu trả lời cho bài luận này:

http://soft.vub.ac.be/~tvcutsem/whypls.html

Tóm tắt Bullet (từ trang đó):

• Ngôn ngữ như cơ chế trừu tượng cú pháp: để giảm mã "soạn sẵn" lặp đi lặp lại mà không thể được trừu tượng hóa bằng cách sử dụng các cơ chế trừu tượng tích hợp sẵn của ngôn ngữ khác.
• Ngôn ngữ như người suy nghĩ: tạo ra một sự thay đổi mô hình trong cách người ta nên cấu trúc phần mềm (thay đổi "con đường ít kháng cự nhất").
• Ngôn ngữ như một trình mô phỏng: để đưa ra một mô hình hiện có đến những phần thiết yếu của nó, thường là để tăng sự hiểu biết và hiểu biết sâu sắc.
• Ngôn ngữ như người thực thi pháp luật: để thực thi các thuộc tính quan trọng hoặc bất biến, có thể giúp dễ dàng suy ra các thuộc tính hữu ích hơn từ các chương trình.

Có lẽ không bao giờ.

Lua là lựa chọn tốt nhất bạn có thể nhận được nếu bạn muốn nhúng ngôn ngữ vào bất kỳ ngôn ngữ nào khác.

Các ngôn ngữ Specifc tên miền nhỏ hiện đang được sử dụng và nó có ý nghĩa trong một số ứng dụng.

Khác sau đó, lý do chủ yếu là học tập.

Tạo một ngôn ngữ khi không cần thiết, thực sự là một điều tồi tệ do sự phức tạp liên quan đến việc phát triển và duy trì nó. Tôi đã thấy nhiều dự án giới thiệu một số loại ngôn ngữ kịch bản chỉ dành riêng cho chương trình đó, và đó là điều làm chậm sự phát triển của điều cơ bản với số lượng rất lớn. Ví dụ điển hình là các ngôn ngữ tự động hóa như Phantom, AutoHotKey, AutoIt. Những công cụ đó sẽ là IMO tốt hơn nhiều nếu họ sử dụng một số ngôn ngữ nổi tiếng như Lua.

'Chỉnh sửa' của bạn dường như là một câu hỏi khác biệt đáng kể ("khi nào tôi nên xây dựng DSL?" Thay vì câu hỏi ban đầu mà mọi người hiểu là "khi nào tôi nên xây dựng một ngôn ngữ lập trình mục đích chung mới"). Có vẻ như mọi người đã trả lời kỹ lưỡng câu hỏi 'gốc' nhưng có rất ít câu trả lời đưa ra tiêu chí cụ thể khi nào nên sử dụng DSL. Vì vậy, tôi đề xuất một danh sách kiểm tra:

1. Cơ sở người dùng của bạn lớn hơn một vài người, thường không có kỹ thuật và / hoặc có quyền truy cập hệ thống bị hạn chế (do đó không hợp lý khi mong họ học / sử dụng ngôn ngữ cho mục đích chung hiện có). Nếu nó nằm trong nhóm nhà phát triển hoặc tổ chức phần mềm của bạn, bạn có thể nói "chỉ cần viết một tập lệnh".
2. Người dùng của bạn cần sử dụng nó đủ thường xuyên, với các hành vi thay đổi và thay đổi đủ cần thiết (nghĩa là bạn không thể chỉ cung cấp một thư viện chức năng cố định do bạn duy trì)
3. Hành vi mà người dùng có thể chỉ định quá phức tạp để chỉ định là dữ liệu (ví dụ: bạn không thể đạt được bằng cách sử dụng bảng cơ sở dữ liệu hoặc ma trận đầu vào của người dùng hoặc danh sách các tác vụ hoặc bộ sưu tập giá trị khóa ... hãy suy nghĩ cẩn thận bởi vì bạn có thể đạt được rất nhiều phức tạp với những điều này). Nếu bạn có thể đạt được hành vi bằng cách sử dụng dữ liệu đầu vào hoặc cấu hình thay vì DSL thì có lẽ bạn nên làm việc đó vì công việc sẽ ít hơn nhiều. Một số loại điều kiện, hoặc khả năng kết hợp / kết hợp với nhau hoặc mô hình hóa một vài trừu tượng khác nhau có thể là dấu hiệu cho thấy hành vi bạn cần quá phức tạp đối với dữ liệu / cấu hình đơn giản
4. Nhưng hành vi vẫn bị hạn chế đủ để bạn có thể chỉ định nó trong DSL ngắn gọn. Một mối nguy hiểm lớn là 'sự phình to nền tảng', ví dụ nếu người dùng bắt đầu yêu cầu "bạn có thể thêm ...?". Nếu họ cần kết nối với internet, hoặc đọc và ghi từ hệ thống tệp hoặc mở và đóng các quy trình - thì đây không còn là DSL. (Tôi đã thấy điều này xảy ra đối với ... người dùng thực sự được phép nhúng các cuộc gọi python nhỏ, dần dần phát triển thành các kịch bản python và cuối cùng phá hủy mọi giới hạn / mô đun / hiệu suất)

Nếu tất cả những điều này là đúng thì DSL có thể phù hợp.

Có các loại ứng dụng sát thủ, các lớp vấn đề thuật toán, v.v., về lâu dài, nơi nào tốt hơn để tạo ra ngôn ngữ của riêng tôi?

Nó phụ thuộc.

Hãy lấy bộ não của chúng ta. Nó dường như là một mớ hỗn độn phức tạp đến nỗi chúng ta gặp phải biên giới với bất kỳ ngôn ngữ lập trình nào (ít nhất là bây giờ). Vì vậy, có thể để thực sự ảo hóa bộ não của chúng ta, chúng ta cần các cách tiếp cận khác và theo đó các ngữ nghĩa và cú pháp khác.

Nói chung, có những chủ đề phức tạp như vậy có thể dẫn đến các chiến lược khác cũng bao gồm ngôn ngữ 'tốt hơn' cho một kịch bản nhất định.