特定于域的语言(DSL)对普通程序员有害吗?[关闭]

总是需要真正的、知识渊博的程序员构造这些DSL,并随着需求的变化向它们添加新的功能。没有问题域是静态的。

DSL将使程序员从非编程工作中解放出来。责任的明确分离总是一个好主意。程序员应该编程(例如,实现DSL),其他领域专家应该做他们擅长的事情。我个人正在尽我所能将这个行业转向更广泛地使用DSL。我不想编写业务逻辑代码。我喜欢实现编译器。所以我不害怕。我期待着每一个小任务都需要自己的DSL。

我不担心,DSL与普通的企业IT部门相比,还有很长的路要走。

我是开发人员,经常设计自己的DSL和DSL2Text转换,以加速我工作中许多无聊的部分。为此,我使用Eclipse插件(即emf、xtext、acceleo等),如本站点中所述。 http://lowcoupling.com/dslengineering

我认为DSL在现实中会提高软件工程工作的水平。原因如下:

1. 想想ORM或SQL DSL。它以您的本地编程语言为SQL访问建模。它降低了复杂性,允许更高级别的构造,更具可读性,并且不易出错(与SQL字符串操作相比)。一个好的SQL DSL是可组合的。试图通过即时的特殊代码实现SQL DSL所做的工作是非常困难的,而且容易出错。在这种情况下,DSL减少了普通的复杂性,并将代码级别提升到更高的抽象级别。(与我们不希望每次打开TCP连接时都对每个TCP/IP握手进行编码的概念相同)。

2. 许多DSL并不适用于软件程序员。当我们设计DSL时,通常会将它们交给领域专家(非程序员)使用。这些更简单的DSL不需要程序员,因此您不必一直使用它们。软件领域目前被缩小了,因为我们的学校大量生产编写简单ASP.NET页面代码的程序员。把这些平凡的工作转移到非程序员身上,将迫使学校培养出更高质量的工程师。

3. 好的DSL隐藏了复杂性,但它们是灵活的,允许用户在需要时自定义/微调行为。这意味着它们不会将程序员限制在严格的/普通的编码行为中。

当一个问题非常复杂时,通常最好将其简化为一个特定于领域的问题,并为其构造一个小型DSL。DSL代码只是更相关和更容易维护,业务逻辑将更短、更容易验证和更容易推理。