寻找使用 DSL 好处的科学证据
格雷格·威尔逊 (Greg Wilson) 的演讲“证据片段” ( http://www.slideshare.net /gvwilson/bits-of-evidence-2338367 ）讨论了 Martin Fowler 提出的使用 DSL 的好处的以下主张背后缺乏证据：
“[使用特定领域的语言]带来两个主要好处第一个也是最简单的就是提高程序员的生产力。第二个是……与领域专家的沟通。” -- Martin Fowler，IEEE Software 2009 年 7 月/8 月
问题：是否有任何实证研究提供证据证明使用 DSL 可以提高程序员的工作效率或改善与领域专家的沟通？
许多构建 DSL 的人无法对“为什么要构建 DSL？”提供合理的答案。以及“为什么 DSL 比精心设计的对象模型更能帮助您？”
我听到很多人说“我这样做是因为它很酷，而且其他人都在这样做”——这不是一个理性的答案。
我相信 DSL 至少在某些时候是有帮助的，但它们不太可能成为不加区别地使用的“灵丹妙药”。我希望看到一些基于实证研究的科学著作，描述何时应该使用 DSL，何时不应该使用 DSL。
Greg Wilson's talk "bits of evidence" ( http://www.slideshare.net/gvwilson/bits-of-evidence-2338367 ) discusses the lack of evidence behind the following claims that Martin Fowler has advanced as benefits of using a DSL:
"[using a domain-sepcific language] lead to two primary benefits. The first, and simplest is improved programmer productivity. The second ...is... communication with domain experts."
-- Martin Fowler in IEEE Software July/August 2009
Question: Are there any empirical studies providing evidence of either improved programmer productivity or improved communication with domain experts from using a DSL?
Lots of people building DSLs are unable to provide a reasoned answer to "why are you building a DSL?" and "why would a DSL help you more than a well-factored object model?"
I hear a lot of "I'm doing it because it's cool and everybody else is doing it" - which is not a rational answer.
I believe that DSLs are helpful at least some of the time but that they're not likely to be a "silver bullet" that should be used indiscriminately. I would like to see some scientific work that describes when DSLs should and should not be used - based on empirical research.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
只是谷歌搜索，我发现了一些有趣的论文：
实践中的特定领域语言：成功因素的用户研究
特定领域语言与面向对象框架：金融工程案例研究
设计后领域特定语言嵌入：软件工程领域的案例研究
而且我想您可以从 Google Scholar 开始找到一些更好的参考...
Just Googling about, I found a couple interesting papers:
Domain-Specific Languages in Practice: A User Study on the Success Factors
Domain-Specific Languages versus Object-Oriented Frameworks: A Financial Engineering Case Study
Post-design Domain-Specific Language Embedding: A Case Study in the Software Engineering Domain
And I imagine you could find some better references starting from Google Scholar...
这取决于您认为 DSL 是什么。
例如，css是DSL吗？我想是的，那么它显然可以使页面样式变得更容易，因为在 HTML 3 中我们使用表格进行排列，并且没有我们现在所做的灵活性。
如果您有 DSL，以便学生可以仅使用原子符号 (H20) 来设计分子，那么它会比您自己进行编码更简单，因为如果您给出符号和键合类型，您可以快速查看分子构型，例如例子。
我不知道有哪篇论文展示了这种或那种方式，但是，如果您的目标受众不是程序员，那么 DSL 就有意义，因此我们可以让会计师使用他们的术语编写他们的应用程序，而不是让他们向开发商。
DSL 已经存在很长时间了，但现在变得越来越流行，所以时间会告诉我们什么时候有更多好的和坏的使用例子，什么时候最好使用它，什么时候它实际上是有害的。例如，我不会使用任何 DSL 来编写医疗监控软件。
It depends on what you consider a DSL to be.
For example, is css a DSL? I would think so, then it obviously can make it easier to style a page, as, in HTML 3 we used tables for arrangements, and didn't have the flexibility we do now.
If you have a DSL so students can design molecules using just the atomic symbols (H20), then it would be simpler than doing the coding yourself, as you can quickly look at the molecular configuration if you give the symbols and types of bonding, for example.
I don't know of a paper showing one way or another, but, if your target audience is not programmers, then a DSL makes sense, so we can have accountants writing their application, using their terminology, rather than having them give requirements to developers.
DSLs have been around for a long time, but are now becoming more popular, so time will tell when there are more examples of good and bad uses as to when it is best to use it and when it actually is detrimental. I wouldn't write medical monitoring software with any DSL, for example.
这是一个明智的问题，我认为存在定义问题，例如“什么是 DSL”？当一个流行语变得“热门”时，它就变成了一个营销机会，并且脱离了基础科学（如果有的话）。
几年前，我写了一本书（构建更好的应用程序，ISBN 0-442-01740-5，早已绝版），我试图研究性能，不仅是程序的性能，而且是程序员的性能。我尝试用信息论来研究它。
我提出了一个粗略的可维护性衡量标准，其中问题作为某人头脑中的知识结构存在（人工智能人员这么说没有问题），而其解决方案作为机器处理的文本结构存在。我看的是这两个结构之间的关系。例如，如果心理问题描述发生变化，需要更改多少源代码才能将其正确转移到程序文本中？衡量这一点的一个简单方法是区分之前和之后的代码。现在，平均值衡量可能发生的变化的空间，平均值越低，源代码就越容易维护。
我的论点是，通过这种衡量标准，代码的可维护性越高，它就越类似于该领域的心理模型，因此可以合理地称其更“面向问题”或更“特定于领域”。
我注意到此类代码的一个特点是，它往往更多的是问题的陈述，而不是问题的解决方案。解决方案不在于语言，而在于语言的实现、子结构。
这是对“声明式”与“命令式”语言概念的呼应，尽管不是直接一致。
因此，在尝试回答您的问题时，我想说，让我们摆脱人们可能希望“DSL”表示的含义，而看一个至少相当明确的定义。
作为发展这个想法的一部分，我偶然发现了许多技术，其中之一是差异执行，这似乎为 UI 编码提供了良好的可维护性，并且还减少了大约一个数量级的源代码大小。我的理论是，这是 DSL 的一个成功示例。
我并不是说维护者无需攀爬学习曲线就可以实现可维护性。我认为真正的可维护性是以程序员必须学习一些可能不容易掌握的东西为代价的，但一旦掌握就会产生所需的价值。
This is a sensible question, and I think there are definitional problems, such as "what is a DSL"? When a buzword becomes "hot" it becomes a marketing opportunity and gets divorced from underlying science, if there is any.
Some years ago, I wrote a book (Building Better Applications, ISBN 0-442-01740-5, long out of print) where I tried to look into performance, not only of programs, but of programmers. I tried to look at it using information theory.
I came up with a crude measure of maintainability, where a problem exists as a knowledge structure in somebody's head (no problem for an AI guy to say so), and its solution exists as a textual structure processed by a machine. What I look at is the relationship between these two structures. For example, if a change occurs in the mental problem description, how many source code changes are required to transfer that to the program text correctly? A simple way to measure that is to diff the code between before and after. Now, average that measure over the space of changes that are likely, and the lower the average is, the more maintainable is the source code.
My thesis was that the more maintainable code is, by that measure, the more it comes to resemble the mental model of the domain, so it is reasonable to call it more "problem-oriented" or more "domain-specific".
One characteristic I noticed of such code is that it tends to be more a statement of the problem, rather than a solution of the problem. The solution lies not in the language, but in the implementation of the language, the sub-structure.
This is an echo, though not a direct agreement, with the concept of "declarative" vs. "imperative" language.
So in trying to answer your question, I would say let's get away from what people might want "DSL" to mean and instead look at a definition that's at least moderately unambiguous.
As part of developing that idea, I had stumbled on a number of techniques, one of which is Differential Execution, which seems to give good maintainability for coding UIs, and also reduces source code size by roughly an order of magnitude. My theory is that that's a successful example of what a DSL might be.
I do not claim that maintainability can be achieved without the maintainer having to climb a learning curve. I think real maintainability comes at a price of programmers having to learn things that might not be easy to grasp, but once grasped have the desired value.
在这种情况下，“科学”的整个前提是值得怀疑的。根本没有办法保证实证研究所需的“可重复”、“控制（组）”标准。
The whole premise of "scientific" in this case is dubious. There is simply no way to guarantee the criterions of "reproducible", "control (group)" required for an empirical study.
总的来说，在商业编程中，在使用某种东西之前，并没有对其好处进行认真的实证研究。无论是SQL、面向对象语言、函数式语言、垃圾收集等等。
这些东西往往会随着时间的推移由市场决定。
为什么会出现这种情况，可能是两个原因的结合。一是获得良好的实证研究非常昂贵，而从经济角度来看，尝试一下要便宜得多。另一个是每种情况都是不同的，因此实证研究必须从非常狭窄地限制所研究的问题开始，以便对使用 DSL 和不使用 DSL 之间进行适当的比较，并且研究的最终结果不会非常好。超出所选特定类型问题的有用性。
我认为我们可以根据经验有把握地说，没有什么是灵丹妙药，坚持某种方法的充分理由将使任何解决方案变得更好，因为即使 DSL 可以帮助某种情况，如果您不知道自己为什么这样做如果这样做，您将不知道自己做得是否正确，并且最终可能会错过全部好处。
By and large in business programming there are no serious empirical studies on the benefits of something prior to its being used. Whether that is SQL, object oriented languages, functional languages, garbage collection, etc.
These things tend to be decided by the market over time.
Why this is the case is probably a combination of two reasons. One is that it is very expensive to get a good empirical study and it is much cheaper from an economical point of view to just try it. The other is that each situation is different, so an empirical study would have to start with limiting the problem under study very narrowly to have a proper comparison between using a DSL and not using one, and the end result of the study would not be very useful beyond the specific type of problem that was chosen.
I think we can safely say from experience that nothing is a silver bullet, and insisting on a good reason for an approach will make any solution better, because even if a DSL would help a situation, if you don't know why you are doing it, you won't know if you are doing it right and may end up missing the whole benifit.
从语言学家 Saphir 和 Worf 那里，我们可以了解到，语言的语法特征会影响我们的思维 = 如果您创建 DSL，您将思考更多特定领域的问题，而可能不太通用。这都是关于抽象的，就像通用编程语言倾向于从机器中抽象一样，因此我们能够更多地关注算法、结构和设计，而不是指令集、寻址模式、寄存器大小等。
From linguists Saphir and Worf, we can learn, that grammatical features of a language influence our thinking = if you create a DSL, you will be thinking more domain-specific and probably less general-purpose. It is all about abstraction, just like general purpose programming languages tend to abstract from the machine, so we are able to focus more on algorithms, structures and design than on instruction set, addressing modes, register sizes etc.
不太确定是否有人已经完成了您需要的任何研究。
但我的经验是，首先创建 DSL 的成本可能很高（做同样的事情可能比更简单的对象模型需要 2 倍或更多的工作量）。
然而，一旦创建，开发人员将立即受益，因为能够使用 DSL 比使用模型更快地完成工作。
这个问题的问题在于它对所有 DSL 都一视同仁。有些更容易实现，另一些则更难——无论是使用 Fluent Interfaces/Internal DSL 还是外部 DSL，都会导致不同的实施时间/成本。
此类研究可能未涵盖的一个主要好处是 DSL 可以轻松表达和实现代码。它还可以帮助其他人更容易地理解代码的意图 - 并且由于软件开发生命周期的维护阶段是 SDLC 的一个重要组成部分，这可能会带来比最初创建 DSL 时损失的更大的好处（从长远来看） 。
Not so sure anyone has done any studies to the extent that you need.
My experience though is that a DSL can be costly to create in the first place (possibly 2X or more effort than a simpler object model to do the same thing).
However once created the developers would get immediate benefit by being able to do things quicker with the DSL than with the model.
The problem with the question is it's treating all DSLs as equal. Some would be easier to implement, others harder - whether one is doing Fluent Interfaces/Internal DSLs or external DSLs would lead to different times/cost to implement.
The one main benefit that might not be covered by such studies is the ease that a DSL can lead to expressing and implementing code. It can also help others understand the intent of the code possibly easier - and since maintenance phase of software development lifecycle is such a big component of the SDLC this could lead to far bigger benefits (in the long term) than initially lost in creating the DSL.