关闭。这个问题是off-topic .它目前不接受答案。
想改进这个问题？ Update the question所以它是on-topic对于堆栈溢出。
10年前关闭。
Improve this question
我已经从一个类似的问题中分出了这个问题，我在对我收到的许多很好的答案之一发表的评论中提出了这个问题。我最初询问的是 AST 宏，这主要引起了 Lispers 非常详细和深思熟虑的回应。谢谢。
Lazy Evaluation vs Macros
我在评论中提出的问题是特定于项目的 DSL 是否真的是一个好主意。当然，这完全是主观的——毕竟，当您使用一种真正富有表现力的语言编写代码时，您在哪里划定了富有表现力的 API 和实际的 DSL 之间的界限？例如，我认为大多数 Ruby 主义者所说的“DSL”实际上只是精心设计的 API，仅此而已。
请注意，我说 特定项目蜜蜂。我不认为很多人会反对在有意义的地方使用正则表达式或 SQL。
但尽管如此，我认为我们都可以在 API 和 DSL 之间划出一条模糊的、模糊的界线。当然，它们都是真正的 API，但无论如何。
在一个极端，你有 Lisp，其中似乎通过宏积极鼓励 DSL。另一方面，你有 Java 之类的东西，DSL 几乎是不可能的。
DSL 的支持者会争辩说，它们增加了灵 active 、表现力和一致性(例如，使用与语言自己的数字相同的运算符的自定义数字对象)。
批评者会说它们会导致除了 DSL 编写者之外没有人知道的子语言，首先扼杀了使用不同编程语言的意义，并导致没有人可以理解的代码，因为 的方式接口(interface) 与 API 不同。
我得说，我在很多方面都同意双方的观点。由于缺乏表现力，一些 Java API 简直就是令人讨厌。尽管如此，我通常可以在不阅读文档的情况下弄清楚发生了什么——这对于自定义 DSL 一点也不能说。也许 DSL 的支持者认为你应该 总是 阅读 API 文档。我不同意，但我也离题了。
但是，让我们看看目前的一些大语言。 C#和Java，即。它们都没有真正“做” DSL，但它们非常受欢迎。这是否正是因为他们不要允许 DSL 之类的东西，允许平庸的编码人员编写仍然可以理解的代码？
DSL 允许平庸的编码人员产生难以理解的垃圾这一事实是否是 Lisp 没有得到应有的使用的原因，尽管 DSL 在右手中看起来会是什么样子？
最佳答案
当然有支持和反对 DSL 的争论，当然在“库”或“API”和“DSL”之间有一条模糊的界限。您在问题中已经很好地涵盖了那部分，因此我将避免这些主观观点，而只关注它们是否是责任的问题。
一个值得考虑的好项目是Racket以语言建构为主要特征。很容易为“一种语言”的任何定义添加一种语言:DSL 与否，通过解释器从头开始构建，或者(更常见)通过定义新语言的宏以及可能用于不同语法的解析器来完成。因此，Racket 源代码树有一堆语言——其中一些具有根本不同的执行语义。一些例子:
事实上，在 Racket 中编写语言非常容易，即使它适合非常有限的用途，甚至只是一种语言，您也可以轻松地拼凑出一种语言。例如，我们有这样的“小语言”用于创建我们的网页，决定哪些文件包含在分布式安装程序中，等等。见 this tutorial有关如何提出一种语言的描述。
确实，在许多人可以使用的有用 DSL 和只有一个人使用的 DSL 之间有一条细线——但是，当你定义一种语言而不是库时，你可以获得的那种抽象对于指出即使它是“一个人的语言”，它也是一个有用的概念。其中一个难题是考虑互操作性——Racket 允许每个模块用它自己的语言编写，这带来了当这些模块中的几个应该相互通信时会发生什么的问题。例如，当惰性语言和默认语言中的函数交互时，评估如何进行？或者类型化如何确保它可以与默认的无类型语言交互，并且仍然可以获得静态类型语言的通常好处。
关于java - 特定于项目的 DSL 是一种责任吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/7052963/