特定于项目的 DSL 是一种责任吗? [英] Are Project-Specific DSLs a Liability?
问题描述
我从一个类似的问题中提出了这个问题，我在对收到的许多很棒的答案之一发表的评论中提出了这个问题.我最初是在询问 AST 宏，它主要引起了 Lispers 非常详细和深思熟虑的回应.谢谢.
I've forked this question from a similar question I made in a comment I made to one of the many great answers I recieved. I was originally asking about AST macros, which mostly provoked very detailed and thoughtful responses from Lispers. Thanks.
我在评论中提出的问题是特定于项目的 DSL 是否真的是一个好主意.当然，这完全是主观的——毕竟，当您使用真正具有表现力的语言进行编写时，您在表现力 API 和实际 DSL 之间的界限在哪里?例如，我认为大多数 Ruby 专家所说的DSL"实际上只是精心设计的 API，仅此而已.
The question I made in a comment was whether project-specific DSLs are actually a good idea. Of course, this is completely subjective -- After all, when you are writing in a really expressive language, where do you draw the line between an expressive API and an actual DSL? For example, I think what most Rubyists call 'DSLs' are actually just well-designed APIs and nothing more.
请注意，我说的是特定于项目的 API.我不认为很多人会反对在有意义的地方使用正则表达式或 SQL.
Note that I say project-specific APIs. I don't think many will argue against using regular expressions or SQL where it makes sense to do so.
尽管如此，我认为我们都可以在 API 和 DSL 之间划出一条模糊不清的界线.当然，它们都是真正的 API，但无论如何.
But despite this, I think we can all draw a vauge, hazy line between an API and a DSL. Of course they're both really APIs, but whatever.
在一个极端情况下，您有 Lisp，其中似乎通过宏积极鼓励 DSL.另一方面，您有 Java 之类的东西，其中 DSL 几乎是不可能的.
On one extreme you have Lisp, where DSLs seem to be actively encouraged via macros. On the other you have the likes of Java where DSLs are pretty much impossible.
DSL 的支持者会争辩说，它们增加了灵活性、表现力和一致性(例如，自定义数字对象使用与语言自己的数字相同的运算符).
Proponents of DSLs would argue that they increase flexibility, expressiveness, and increase consistency (for example, a custom number object using the same operators as the language's own numbers).
批评者会说它们会导致除了 DSL 编写者之外没有人知道的子语言，首先扼杀了拥有不同编程语言的意义，并导致代码没有人可以理解，因为接口的方式与 API 不同.
Detractors would say that they can lead to sub-languages that nobody except the DSL writer knows, kills the point of having different programming languages in the first place, and leads to code nobody can understand because the way of interfacing with API is different.
我得说，我在很多方面都同意双方的意见.由于缺乏表现力，一些 Java API 简直令人讨厌.尽管如此，我通常总是可以在不阅读文档的情况下弄清楚发生了什么——这对于自定义 DSL 来说丝毫不能说.也许 DSL 支持者认为您应该始终阅读 API 文档.我不同意，但我也离题了.
I gotta say, I agree with both sides in many ways. Some Java APIs are just plain nasty due to the lack of expressiveness. Despite this, I can generally always work out what's going on without reading the documentation -- Which can't be said about custom DSLs in the slightest. Maybe DSL proponents argue that you should always read API documentation. I disagree, but I also digress.
但让我们看看目前的一些主要语言.C# 和 Java，即.他们都没有真正做"DSL，但它们非常受欢迎.这是否正是因为他们不允许允许像 DSL 这样的东西，允许平庸的编码人员编写出仍然可以理解的代码?
But let's look at some of the big languages at the moment. C# and Java, namely. Neither of them really 'do' DSLs, yet they're massively popular. Is this precisely because they don't allow things like DSLs, allowing mediocre coders to churn out code that's still comprehensible?
尽管 DSL 在正确的人手中看起来像什么，但 DSL 允许平庸的编码人员产生难以理解的垃圾这一事实是否是 Lisp 没有得到应有的使用的原因?
Is the fact that DSLs allow mediocre coders to produce impenetrable garbage the reason why Lisp is not used as much as it should be, despite what a DSL can look like in the right hands?
推荐答案
当然有赞成和反对 DSL 的争论，当然在库"或API"和一个DSL".你在问题中已经很好地涵盖了这一部分，所以我将避免这些主观观点，而只关注它们是否是一种责任的问题.
There are of course arguments in favor of DSLs and against them, and there's of course a vague line between "a library" or "an API" and "a DSL". That part you've covered well in the question, so I'll avoid those subjective points and focus on just the question of whether they're a liability.
一个值得考虑的好项目是 Racket，它将语言构建作为其主要功能.很容易为一种语言"的任何定义创建一种语言:DSL 与否，通过解释器从头开始，或者(更常见)通过定义新语言的宏和可能的不同语法的解析器完成.因此，Racket 源代码树有很多语言——其中一些具有根本不同的执行语义.一些例子:
A good project to consider for this is Racket which puts language construction as its main feature. It's easy to slap up a language for any definition of "a language": DSL or not, made up from near scratch via an interpreter or (more commonly) done via macros that define the new language and possibly a parser for a different syntax. As a result, the Racket source tree has a bunch of languages -- some of them have fundamentally different execution semantics. Some examples:
Lazy Racket 正是您所期望的名称含义，
Lazy Racket is what you'd expect the name to mean,
Typed Racket 是一种静态类型语言，
Typed Racket is a statically typed language,
Scribble 是一种用于编写文档和其他散文的语言，
Scribble is a language for writing documentation and other prose,
幻灯片是一种用于编写...幻灯片的语言，
Slideshow is a language for writing ... slideshows,
RackLog/DataLog 是在语义和语法上更加不同的语言.
RackLog/DataLog are languages that are even more different in both semantics and syntax.
事实上，在 Racket 中编写语言非常容易，即使它的用途非常有限，甚至只是一种语言，您也可以轻松地使用它.例如，我们有这样的小语言"，用于创建我们的网页、决定哪些文件包含在分布式安装程序中等等.请参阅本教程，了解如何提出一种语言.
In fact, making up languages is so easy in Racket, that you easily slap up a language even if it's something that fits a very limited use, or even just a single one. For example, we have such "small languages" that are used to create our web pages, decide which files are included in distributed installers, and many many more. See this tutorial for a description of how to come up with a language.
确实，许多人可以使用的有用 DSL 和只有一个人使用的 DSL 之间存在细微的界限——但是，仍然存在定义一种语言 而不是 图书馆 是实质性的，以至于它是一个有用的概念，即使它是一种个人语言".其中的一个难题是考虑互操作性——Racket 允许每个模块用它自己的语言编写，这带来了当这些模块中的几个应该相互通信时会发生什么的问题.例如，当惰性语言和默认语言中存在函数交互时，评估如何进行?或者类型化如何确保它可以与默认的非类型化语言交互，并且仍然获得静态类型化语言的通常好处.
It's true that there's a fine line between a useful DSL that many people can use and one that only one person uses -- but still, the kind of abstractions that you can get when you define a language rather than a library are substantial, to the point that it's a useful concept even when it's a "one-man's language". One hard problem in this are is considering interoperability -- Racket allows each module to be written in it's own language, which brings up issues of what happens when several of these modules are supposed to talk to each other. For example, how does evaluation proceeds when there's interaction of functions in the lazy language and in the default one; or how does the typed make sure that it can interact with the default untyped language and still get the usual benefits of a statically typed language.
这篇关于特定于项目的 DSL 是一种责任吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
