我想要一些关于何时应该使用Domain Specific Language 的实用指导。我找到了有关优缺点的资源，但什么样的项目值得使用？
创建和维护 DSL 似乎需要大量时间投资，那么在哪些应用程序空间中，我的时间投资可以获得生产力回报？
编辑： 似乎 DSL 最常见的用途是用于保存数据状态的文件格式，那么将 DSL 用于程序逻辑和结构（可能是代码生成）呢？什么时候可行？
Edit #2 我主要是问什么时候创建一个特定的 DSL 是值得的。当然，我们应该尽可能地使用现有的 DSL 以节省时间。
【问题讨论】：
创建另一个 DSL 的充分理由很少。这个世界充满了特殊用途的语言。
按照这些思路思考。
用 Python、Java、C++ 等通用语言解决问题。
优化该解决方案以排除通用功能并构建一个非常漂亮、非常优雅、非常可扩展的类库。
优化该类库以强调“正交性”。确保所有功能都能很好地协同工作，没有任何问题。
如果您只需要简化语法，请围绕您漂亮的类库创建一个脚本包装器。这是你的 DSL。对于 Python，这很容易——它已经是一种动态语言。对于 Java，您可以利用一些东西。对于 C++ 来说，构建这种灵活的脚本环境可能需要一些工作。
如果您仍需要进一步优化，请考虑为您的 DSL 编写编译器。
【讨论】：
ACM Computing Surveys 文章 When and How to Develop Domain-Specific Languages 提供了关于这个主题的建议，Martin Fowler 的 2010 年书籍 Domain-Specific Languages 也提供了建议。
【讨论】：
首先，当您开发的问题领域是广为人知的领域，并且该领域的一些业务专家已经经历了很好的研究时，我会使用 DSL构建这样一个 DSL 的长度，这样您就不必自己费力地解决他们已经解决的所有问题。
如果您正在考虑创建 DSL，如果您的业务是在非常特定的领域完成的，并且您将大部分时间用于时间专注于特定的问题领域。如果你在为多个问题领域做申请时跳来跳去，那么我不建议采用这种方法。
例如，如果您的企业专注于构建税务应用程序，那么构建税务系统 DSL 可能是一个好主意。这将使您的语言不仅可以在您的各种税务申请中被您使用，而且还可以被您所在行业中想要做与您正在完成的类似事情的其他企业销售（可用）。
当然，您必须权衡在现有语言之上构建 DSL 与构建框架的成本/收益。
【讨论】：
想到的一种情况是当需求需要非常高或不可能的自定义/配置级别时。因此，您将提供一种针对 DSL 的脚本模型。
以汽车装配“手臂”为例，提供配置模型来支持各种工厂配置是不可能的。 （检测到这个，不要检测到那个，当这种情况发生时这样做......等等）
但是为每个客户编译一个具有专门逻辑的新应用程序可能不是一个好方法。所以在这种情况下，你创建了一个小框架，它将成为一种 DSL，然后对于你销售的每个机械臂，你在你的 DSL 中编写一个小应用程序，并将它与编译和运行你的 DSL 的核心软件一起保存脚本代替。或者更好的是，用于对 DSL 进行编程的工具与机械臂一起包含在内，因此您的客户可以在您创建的 DSL 中自己“编程”机械臂。
想到的一个真实世界的例子是 Yahoo Pipes（您可以将其视为 DSL）或用于自动网络爬虫的 robots.txt 指令。它们可能不是成熟的 DSL，但它们展示了 DSL 可能有用的地方。
【讨论】：
嗯，总得有人说吧，所以就这样吧：
Lisp 被一些人认为是 any 领域的领域特定语言。一个得到良好支持且非常可扩展的 DSL。
在某些情况下，从 Lisp（或类似的语言，如 Haskell）构建 DSL 实际上可以用最少的努力提供很多功能，因此非常值得。 DSL 并不总是需要很大的维护负担。
【讨论】：
最明显的是，当语言已经存在并且得到很好的支持时，您绝对应该使用它们。这方面的主要示例是用于基于 Motif 的 GUI 开发和软件构建的 UIL。
如果你必须自己做，我想说寻找域的大量工作就是正确地指定事物，而你的编译器无法真正找到大多数错误，但特定于域的编译器可以. GUI 就是一个很好的例子，因为大部分工作是设置布局，并且通常有很多方法可以进行语法上有效的 C++ 调用，这些调用对你的底层 GUI 系统没有任何意义（例如：尝试嵌入整个对话框按钮内的小部件）。
我发现 UIL 对 GUI 开发来说尤其是一个巨大的收获，因为 UIL 编译器可以在 GUI 规范中发现错误，这些错误对于 C++ 编译器来说就像是不错的正常可编译代码。它得到良好支持的事实意味着代码很容易在平台之间移植，甚至在 GUI 构建器之间移植。
【讨论】：