【问题标题】:Domain-specific languages vs. library of functions特定领域语言与函数库
【发布时间】:2009-09-28 01:19:23
【问题描述】:

这可能是主观的,我不知道:我有这个问题,我有点等同于“这个项目用什么语言?”问题,因为我似乎无法解决它。

我受委托为一个非常精通技术但不是程序员的社区写一本关于某个领域(假设是一个非常具体的物理学分支)的书。这是一本关于他们日常使用的算法子集的书。

为此,考虑到我的听众,我一直在玩弄定义 DSL 的想法,而不是让他们学习语言 X,并从这个角度讨论算法,而不是用给定的语言或伪代码.

那么问题是:有哪些迹象表明您需要的是 DSL,而不是要从成熟的通用语言调用的函数库?

谢谢。

编辑:目前支持 DSL 的建议:

  • 避免通用语言的复杂性。
  • 让“程序员”在他/她的领域更有效率。
  • 使语言概念对于编程新手来说非常直观。 (现在才想到这个)

【问题讨论】:

  • +1 回答一个有趣的问题。
  • 这个领域的人通常用 Fortran 或 Matlab 编程吗?不妨检查一个假设。

标签: programming-languages dsl


【解决方案1】:
  1. 您的听众是 非程序员。
  2. 你是 针对特定领域。
  3. 他们 需要完成工作。

我会选择 DSL 而不是通用语言。

【讨论】:

  • 这些可能是了解 Fortran 和 Matlab 的人,因为许多物理学家似乎都在编写自己的程序,因为许多程序员对领域的理解不足以帮助他们,而 Matlab 只是一个非常有用的工具,也允许他们编写程序。
  • 然而,无论你实现什么 DSL,它都应该有一种机制可以将 DSL 导出为真实语言,以便开发人员可以导出他们的工作并继续,而不必重新开始。
【解决方案2】:

您可以选择一个 DSL 来完全匹配您正在处理的域。程序员可以适应通用语言并在许多情况下应用它。您的非程序员可能会受益于与他们直接相关的语言。他们也更容易理解关键字和概念是否符合他们的专业知识。

像大多数事情一样,这是一种权衡。 DSL 对您的受众来说应该更容易,但对您来说可能更有用。

【讨论】:

    【解决方案3】:

    您可以使用 DSL 将一组相关操作与调用语言解耦。

    如果您想保护您的用户免受通用语言的复杂性(或限制他们对该语言的访问,因为他们可能会滥用它),请设计一个 DSL。

    但是,如果您希望以与调用语言集成的方式使用操作,则使用函数库(或其他运算符)。

    【讨论】:

      【解决方案4】:

      我认为这将取决于编写 DSL 和函数式编程语言,因为根据我的经验,物理学家往往在 Fortan 或 Matlab 方面相当胜任。

      您可能想尝试在示例中使用这些语言,因为它可以让您深入了解算法,因为它可以帮助那些更具技术性的语言。

      正如 Mitch Wheat 所说,当您想向用户隐藏详细信息时,DSL 非常有用。

      【讨论】:

        【解决方案5】:

        我认为 DSL 的目的是抽象出细节并使程序员(或实现者)能够通过保持头脑在领域中来提高生产力。

        如果你想解释一组算法的细节,我会坚持使用常见的嫌疑人之一(C++?)。

        一个重要的考虑因素是您的受众是否已经主要使用一种语言。如果是这样,那么已经为您做出了选择!

        您可能需要考虑的另一件事是,通过选择流行的主流语言,您的书可以适用于更广泛的受众,而无需先“学习”DSL。

        【讨论】:

          【解决方案6】:

          最终我会这样看:DSL(与任何编程语言一样)是一组词汇标记和习语,您可以使用它们来解释如何做某事。在这组标记中隐含的是一组习语。

          任何语言的理念都是选择一种合适的语言,以便更容易表达预期的算法。

          一个很好的例子是报告语言(例如自然)。那是因为报告有常用的成语,如组、中断条件等。任何用通用语言做过这件事的人都会告诉你,做诸如中断条件之类的事情真的很乏味,但它肯定是可能的。

          所以您应该问的问题是:是否有任何常见的习语会用通用语言表达乏味、困难或极其冗长?您还应该问:是否有您最感兴趣的特定功能子集可以通过使其成为语言概念而受益?这可能是线性代数的向量和矩阵(使用适当的运算)或积分/微分或微分方程的相同。

          您最终真正希望 DSL 拥有的是,例如,一个 500 行的程序可以表示为您的 DSL 的 50-100 行,这适用于大多数“预期”算法。我想这有点像数据建模中的规范化,其目标是删除重复组。编写相同的 10 到 20 行代码并稍加改动,这表明了一个常见的习惯用法。

          至于函数库,这是对同一事物的更有限的看法(最终),除了函数库只是不同行为的包。这假设您定义了一个函数库,而不是包含复杂的对象层次结构、闭包等。如果你这样做了,那么“函数库”和 DSL 之间的界限就会变得模糊。

          我会将函数库视为大多数现代语言(sin、cos、平方根等)中存在的一组数学函数。所以我想它归结为:

          • 代码包 -> 函数库
          • 常用成语 -> DSL

          【讨论】:

            【解决方案7】:

            使用伪代码来解释您的算法。这将比使用带有库 API 的通用编程语言更通用。

            您认为您的 DSL 必须有多复杂?读者是否需要很长时间才能熟悉它?

            虽然你会在书的背面填满图书馆的源代码来填满这些页面。

            【讨论】:

              【解决方案8】:

              您必须权衡您可以提供更清晰的符号的程度与没有人会开始知道您使用的符号这一事实。从理论上讲,您可能能够很好地遵循这个小组通常使用的符号,以至于它“直观地明显”——但除非他们与大多数物理学家不同,否则这可能不会很好用。许多人使用典型键盘上不存在的希腊语和/或希伯来语字符。

              如果您确实使用了 DSL,您是否准备好不仅要实施它,而且还要花费大部分时间来维护它?您是否拥有超越语言本身的资源,并提供一种基础设施使其成为有用的开发工具?如果它要用于真正的开发,它可能需要一个调试器。您可能还想考虑一个新的 IDE(如果它真的不同的话)或定制一个现有的产品来工作(例如,为 emacs 创建一个专门的模式或为 Eclipse 创建一个插件)。

              如果您确实发明了 DSL,那么人们真正使用它的可能性有多大?如果已经有某种根深蒂固的东西,要取代它可能会非常困难。创建一种填补真空的新语言比替换已经在使用的语言要容易得多。另一方面,如果真的存在真空,这可能表明市场并不大——您的受众可能对成为软件开发人员并不特别感兴趣。

              【讨论】:

                猜你喜欢
                • 2019-01-05
                • 1970-01-01
                • 2010-09-06
                • 1970-01-01
                • 1970-01-01
                • 1970-01-01
                • 1970-01-01
                • 1970-01-01
                • 1970-01-01
                相关资源
                最近更新 更多