编写关于外部 领域特定语言 的棘手问题之一是，我正在踏入编程语言社区已经深入研究的领域。编程语言研究一直是学术界的一个热门领域，我首先承认，我在这个主题上的深度远不及许多多年来一直在研究这个领域的人。因此，不可避免地会出现这样的问题：为什么像我这样的新手认为自己可以在这个已经被充分探索的领域写一本书？

不久前，我与一位即将走上学术道路的博士后聊天。他问我关于研究课题的问题，希望我能就哪些研究具有实际用途提供意见。我并没有提供太多帮助，但我确实提到，做到这一点的最佳方法是在业界工作一段时间，以了解软件开发在实际中的运作方式，以及哪些问题可以通过一些研究工作来解决。他对这个想法的回答非常令人不安。

DSL 是否允许业务人员在不涉及程序员的情况下编写软件规则？

当人们谈论 DSL 时，通常会提出业务人员自己编写代码的问题。我喜欢将 COBOL 推论应用于这种思路。也就是说，COBOL 的最初目标之一是允许人们在没有程序员的情况下编写软件，我们知道结果如何。因此，当任何计划在没有程序员的情况下编写代码时，我不得不问，这一次有什么特别之处，可以让它在 COBOL（以及许多其他事物）失败的地方取得成功。

技术债务 是一个非常有用的概念，但它提出了如何衡量它的问题？遗憾的是，技术债务不像金融债务，因此很难判断你欠了多少债务（尽管我们最近似乎在衡量金融债务方面遇到了一些麻烦）。

SOA 狂热者宣传的新服务世界的一个特点是注册表的概念。这通常是用自动化系统的术语来描述的，这些系统将允许系统自动在注册表中查找有用的服务，并自行绑定和使用这些服务。

好吧，计算机有时可能看起来很聪明，但我并不特别相信这个想法。虽然可能存在自动服务查找的特殊情况，但我认为二十二次中有二十二次是人类程序员在进行查找。

几年前，我听到编程语言界的人们谈论 Java 造成的语言“核冬天”。当时的感觉是，每个人都如此认同 Java 的计算模型（C# 在当时被视为抄袭品），以至于编程语言的创造力已经消失。这种感觉现在正在消退，但也许更重要的是，关于数据库的思考正在开始解冻，这种冻结的时间更长、更深。

在 2008 年旧金山 QCon 大会上，Rebecca Parsons 和我发表了一个演讲，主题是敏捷方法如何与企业架构团队合作。目前，敏捷项目团队和架构团队之间存在很多不信任和冲突。我们深入探讨了为什么会这样，并探索了这些团队可以合作的方式。

让我们想象一个美好的 SOA 幸福世界，在这个世界中，企业的计算需求被分解成许多小型应用程序，这些应用程序相互提供服务，以实现有效的协作。一个美好的早晨，一个消费者服务需要来自供应商服务的一些信息。问题是，尽管供应商服务具有获取此信息的必要数据和处理逻辑，但它还没有通过服务接口公开该信息。供应商有一个潜在的服务，但它实际上还没有。

几年前，我与一位客户交谈，他告诉我他不喜欢我们正在使用的敏捷方法的一点：“在项目早期就遇到这些困难，感觉不太对劲”。与他的反应相反，在我看来，这种早期的痛苦是敏捷或任何迭代开发过程的巨大*优势*之一。

Oslo 是微软的一个项目，关于它的各种传闻很多，但直到本周的 PDC 大会才有一些细节。我们所知道的是，它与 模型驱动软件开发 和 领域特定语言 有关。

微软 Channel 9 对我、我的同事 Neal Ford 和 Jeffery Snover（PowerShell 的创建者）的采访。主题是 DSL - Neal 和我刚刚在 JAOO 2008 上完成了一个关于该主题的教程，并与 Jeffery 进行了一些很好的对话。

Thoughtworks 经常组织“季度技术简报” - 在我们设有办事处的城市为社区举办公开讲座。在多伦多的这次 QTB 中，Scott Shaw 和我谈论了如何建立 IT 和业务之间的新关系。它解释了为什么我们认为应该解散 IT 部门。

需求是在开始构建产品之前应该发现的东西。在构建过程中，或者更糟糕的是，当客户开始使用您的产品时才发现需求，这是非常昂贵和低效的，以至于我们假设任何头脑清醒的人都不会这样做，并且不会再提它。

-- Suzanne 和 James Robertson

敏捷方法违反了这一基本假设，因为它打算在构建过程中和交付后发现“需求”。但即使是对上述明智建议的这种漫不经心的漠视，与当今许多领先网站的做法相比也微不足道。这些网站通过观察用户在其网站上的行为来探索需求，并使用这些信息来生成新功能的想法，如下所示

SOA 可以用敏捷方法来做吗？

我被要求为非技术人员整理一份关于 DSL 的讨论。也许我读了太多 Stephen O'Grady 的文章，但我有一种无法抗拒的冲动，想以问答的方式来做这件事。所以它来了。

语言工作台是我在 2005 年创造的一个术语，用来描述一类新的软件开发工具，旨在通过一个由多个集成的 领域特定语言 组成的丰富环境来构建软件。这些工具距离成为主流还有一段距离，但它们的开发仍在继续，并且仍然很有趣。我认为它们是少数几个能够显著改变编程格局的东西之一。

模型驱动软件开发 (MDSD) 和 领域特定语言 (DSL) 之间有什么联系？

在 MDSD 的上下文中看到“DSL”这个词是很常见的。事实上，一些 MDSD 人士似乎认为 DSL 只存在于 MDSD 世界中。最近我一直在为我的书写很多关于 DSL 的内容，但到目前为止，我还没有真正触及 MDSD 的角度。相反，我一直在关注 DSL 在更传统的编程中的作用。DSL 存在于文本语言和 MDSD 世界中，并且在这两个世界中扮演着几乎相同的作用。

模型驱动软件开发 (MDSD) 是一种软件开发风格，它认为自己是传统编程风格的替代方案。这种方法的核心是构建软件系统的模型。这些模型通常通过图表设计符号来体现 - UML 就是一种选择。其理念是，您使用这些图表来向建模工具指定您的系统，然后用传统的编程语言生成代码。

与任何行业一样，软件开发也有其经常被遗忘的活动，这些活动通常被忽视，但有一种习惯，即在错误的时刻反咬一口。其中之一是数据迁移。

我正在考虑使用敏捷软件开发 - 但我应该改用精益软件开发吗？

媒体网站面临的最大问题之一是如何处理大量的流量。媒体的全部意义在于吸引眼球，但如果同时访问量过大，性能缓慢会导致问题并损害您的声誉。网络流量的突发性加剧了这个问题。您可能以可管理的速度运行，然后突然出现一条重大新闻，导致流量激增。我们的一位客户在几分钟内就经历了两倍的流量峰值。

在谈论 领域特定语言（或任何计算机语言）时，一个常见的词是语法噪音。人们可能会说 Ruby 比 Java 的噪音小，或者外部 DSL 比内部 DSL 的噪音小。语法噪音是指那些不是我们真正需要表达的意思的一部分，而是为了满足语言定义而存在的无关字符。噪音字符是不好的，因为它们会掩盖我们程序的含义，迫使我们去费解它在做什么。

这些天，我与人们进行了很多关于领域特定语言的讨论，对于外部 DSL，一个常见的反应是编写解析器很困难。的确，使用 XML 作为外部 DSL 的载体语法的一个理由是“你可以免费获得解析器”。这与我的经验不符——我认为解析器比大多数人想象的要容易编写得多，而且它们并不比解析 XML 更难。

领域特定语言 (DSL) 的基本概念是一种针对特定类型问题的计算机语言，而不是针对任何类型的软件问题的通用语言。领域特定语言的讨论和使用几乎与计算的历史一样悠久。

我记不清这是第几次了，我又一次陷入了关于定义实践的对话，将其中一些标记为“最佳”，可能还有那个以 C 开头的词（认证）。这是一个熟悉的讨论，尽管我们才刚刚开始，但我可以预测它将走向何方。它是由一种完全合理的愿望驱动的，即确定谁是更优秀的软件开发人员，以及现有开发人员如何提高他们的能力。

我的同事 Jim Webber 以其在企业集成中采用轻量级和面向业务的方法而闻名。他还以其健谈和有趣的演讲风格而闻名。因此，当我要在 2008 年 QCon 大会上与他一起做主题演讲时，我既紧张又兴奋。他准备了一场非常有趣的演讲，其中穿插着一些严肃的内容。然后我们就开始了——可能是演讲前的啤酒起了作用。我们谈到了企业集成的历史、那些自以为强大但实际上只是臃肿的系统的增长、敏捷思维的作用、网络的影响（包括 Jim 关于网络发明原因的独特理论），以及这如何导致游击 SOA。

软件界普遍接受的观点之一是有才华的程序员效率更高。由于我们无法衡量生产力，这是一个无法证实的信念，但它似乎是合理的。毕竟，几乎所有的人类活动都表明，有些人比其他人做得更好，而且往往明显更好。程序员自己也普遍观察到这一点，尽管似乎总是那些认为自己属于更有才华的人才会这么说。

基于源代码的编程环境将系统的定义保存在一组源文件中，这些源文件既是系统定义的可编辑表示，也是其存储表示。然后，这些源代码被转换为实际运行的可执行表示。与投影编辑（我在其中更详细地讨论了这两种编辑方式）相比，基于源代码的代码是当今最常见的形式。

想象一下招聘场景。有两名候选人，都有几年的工作经验。在蓝色角落，我们有一位在您喜欢的设计风格方面拥有良好且广泛的设计技能的人（对我来说，这将是 DRY、明智地使用模式、TDD、沟通代码等，但实际列表并不重要——重要的是这是您喜欢的）。然而，她对你正在使用的特定平台技术一无所知。在红色角落，我们有一位对这些问题知之甚少（或不感兴趣）的人，但他非常了解你的平台——语言的边缘情况、可用的库、手指在工具上自然地移动。假设他们其他方面都相同（除了像这样的思想实验外，这永远不会发生），并且你的团队没有任何这个候选人可以填补的明显空白。你会更喜欢哪一个？

源代码编辑的一种替代方法是，系统的核心定义应该保存在模型中，并通过投影进行编辑。