代码之家  ›  专栏  ›  技术社区  ›  Kekoa

我应该何时使用特定于域的语言?

  •  29
  • Kekoa  · 技术社区  · 16 年前

    我想知道什么时候应该使用 Domain Specific Language . 我已经找到了关于优缺点的资源,但是什么样的项目才值得使用呢?

    似乎在创建和维护DSL的时间上有很大的投资,那么在什么应用程序空间中,我可以从我的时间投资中获得生产力回报呢?

    编辑: DSL最常见的用法似乎是用于文件格式以保持数据状态,那么将DSL用于程序逻辑和结构(可能是代码生成)呢?什么时候可行?

    编辑第2页 我主要是问什么时候创建一个特定的DSL是值得的。当然,我们应该尽可能多地使用现有的DSL来节省时间。

    6 回复  |  直到 11 年前
        1
  •  15
  •   pruzoth S.Lott    11 年前

    创建另一个DSL的理由非常少。世界上有许多特殊用途的语言。

    按照这些思路思考。

    1. 用Python、JAVA、C++等通用语言解决这个问题。无论什么。

    2. 优化该解决方案,以分解出常见的特性,并构建一个非常好、非常优雅、真正可扩展的类库。

    3. 优化类库以强调“正交性”。确保所有功能都能正常工作,没有任何问题。

    4. 如果您只需要简化语法,那么就在您的漂亮类库周围创建一个脚本包装器。这是您的DSL。对于Python来说,这很容易——它已经是一种动态语言了。对于Java,有些事情你可以利用。对于C++来说,构建这种灵活的脚本环境可能是一项工作。

    5. 如果仍然需要进一步的优化,可以考虑为DSL编写编译器。

        2
  •  12
  •   Peter S. Housel    11 年前

    ACM计算调查文章 When and How to Develop Domain-Specific Languages 提供关于这个主题的建议,正如马丁·福勒2010年的书一样。 Domain-Specific Languages .

        3
  •  11
  •   Joseph    16 年前

    首先,我会 使用 一个DSL,当你开发的问题域是一个广为人知的领域时,该领域的一些业务专家已经花了很大的时间来构建这样一个DSL,这样你就不必为解决他们已经发现的所有问题而花费自己的时间。

    如果你想 创建 一个DSL,如果您的业务是在一个非常特殊的领域中完成的,并且您将大部分时间集中在一个特定的问题领域中,我会考虑这样做。如果您在为多个问题域执行应用程序时遇到困难,那么我不建议采用这种方法。

    例如,如果您的企业在构建税务应用程序方面独树一帜,那么构建一个税务系统DSL可能是一个好主意。这将使你的语言不仅可以被你在各种税务申请中使用,而且也可以被你所在行业中其他想要做你正在完成的类似事情的企业在市场上使用。

    当然,您必须权衡在现有语言的基础上构建DSL与框架的成本/收益。

        4
  •  3
  •   chakrit Dutchie432    16 年前

    需要考虑的一种情况是,需求需要非常高或不可能的定制/配置级别。 . 因此,您将提供一种针对DSL的脚本模型。

    以汽车装配“ARM”为例,提供一个配置模型来支持各种工厂配置是不可能的。(检测到这个,不要检测到,当发生这种情况时,请执行此操作…等)

    但是,为每个客户编译一个具有专门逻辑的新应用程序可能不是一个好方法。因此,在这种情况下,您创建一个小框架,它将成为一种DSL,然后对于您销售的每个机械臂,您在DSL中编写一个小应用程序,并将其与编译和运行DSL脚本的核心软件一起保存。或者更好的是,编程DSL的工具与机械臂一起提供,这样您的客户就可以在您创建的DSL中“编程”手臂。

    一个现实世界中出现的例子是YahooPipes(您可以将其视为DSL)或Automated Web Crawler的robots.txt指令。它们可能不是一个完整的DSL,但它们展示了DSL在哪里可能有用。

        5
  •  3
  •   Artelius    16 年前

    好吧,必须有人说出来,下面是:

    有些人认为Lisp是 任何 领域。一个支持良好且可扩展性很强的DSL。

    在某些情况下,从Lisp(或类似的语言,如haskell)中设计DSL实际上可以以最少的工作量提供大量的功能,因此非常值得。DSL并不总是需要很大的维护负担。

        6
  •  2
  •   T.E.D.    16 年前

    最明显的是,当语言已经存在并且得到很好的支持时,您应该绝对地使用它们。这方面的主要例子是基于motif的GUI开发和软件构建的uil。

    如果你必须自己做,我会说,寻找领域的大量努力只是在正确地指定事情,在那里你的编译器不能真正找到大多数错误,但一个领域特定的编译器可以。GUI是一个很好的例子,因为大部分的工作都是在建立布局,并且通常有很多方法可以使语法有效的C++调用对你的底层GUI系统毫无意义(例如:试图在按钮中嵌入整个对话小部件)。

    我发现UIL尤其是GUI开发的巨大收益,因为UIL编译器可以在GUI规范中发现错误,它看起来像是C++编译器的好的正常编译代码。它得到了很好的支持,这意味着代码很容易在平台之间移植,甚至在GUI构建器之间移植。