我最近一直在研究F＃和新的DSL内容，就像在Microsoft SQL Server建模CTP中一样，并且有一些顾虑。
对于熟练的程序员来说，这个新想法是否会变坏？
代码会变得愚蠢吗？
我知道我听起来像个luddite，但这确实让我担心，经过多年的时间练习我的手艺，现在可能会被天才从内部凿沉。
我很害怕，非常害怕。
现在我是否会被困在一个只针对DSL的程序工作，因此我工作的每一份工作，我必须学习一个基于框架（.net Java）的全新DSL，我只会被允许触摸的某些部分。
我不认为这个世界已经为DSL做好了准备，但销售宣传却震耳欲聋！
答案 0 :(得分：8)
DSL将解放程序员从做非编程的东西。更清洁的责任分离始终是一个好主意。程序员应该编程（例如，实施DSL），其他领域的专家应该做他们擅长的事情。我个人正在竭尽所能将这个行业转向更广泛的DSL使用。我不想编写业务逻辑。我喜欢实现编译器。所以我不害怕。我期待着每一项小任务都需要自己的小DSL的时候。
答案 1 :(得分：3)
我不担心，DSL需要很长很长时间才能被普通的企业IT部门所接受。
答案 2 :(得分：3)
总是需要真正的，知识渊博的程序员来构建这些DSL，并在需求变化时为他们添加新功能。没问题域是静态的。
答案 3 :(得分：2)
我是开发人员，我经常设计自己的DSL和DSL2Text转换，以加快我工作中许多无聊的部分。为此，我使用Eclipse插件（即EMF，XText，ACceleo等），如本网站http://lowcoupling.com/dslengineering中所述
答案 4 :(得分：1)
我认为现实中的DSL将提升软件工程的水平。原因如下：
想想ORM或SQL DSL。它以您的本机编程语言模拟SQL访问。它降低了复杂性，允许更高级别的构造，更易读，并且不易出错（比SQL字符串操作）。一个好的SQL DSL是可组合的。尝试实现SQL DSL在运行中使用Ad Hoc代码所做的事情太困难且容易出错。在这种情况下，DSL可以降低普通复杂性并将代码级别提升到更高级别的抽象。 （与我们每次打开TCP连接时都不想对每个TCP / IP握手进行编码的概念相同）。
许多DSL不适合软件程序员。当我们设计DSL时，通常会将它们交给域专家（非程序员）使用。这些更简单的DSL不需要程序员，因此您不会被困在使用它们。软件领域目前正在瘫痪，因为我们有学校培养出编写简单ASP.Net页面的程序员。将这些平凡的工作转移给非程序员将迫使学校培养出更高素质的工程师。
良好的DSL隐藏了复杂性，但它们非常灵活，允许用户在需要时自定义/微调行为。这意味着他们不会将程序员限制在严格/普通的编码行为中。
当问题非常复杂时，通常最好将其降低为特定于域的问题并为其构建迷你DSL。 DSL代码更具相关性，更易于维护，业务逻辑更短，更易于验证，更容易推理。