特定領域語言指南

在 00 年代的最後幾年，我對 DSL 的復興產生了濃厚的興趣，這得益於 Ruby 社群的努力、建立流暢介面的渴望，以及語言工作台誘人但模糊的前景。我看到很多專案使用 DSL 的想法，但大多數人對在建構和使用它們時如何選擇並無明確的概念。因此，我決定透過撰寫一本模式書來解決這個問題，以用於簡單的內部和外部文字 DSL。儘管在過去幾年中，這方面的興趣已經消退了很多，但我仍然認為這本書很好地掌握了這些技術。特別是，它闡明了使用適應性模型來擷取替代運算模型，例如規則引擎、決策表格和狀態機。

有人請我為非技術人員整理一份關於 DSL 的討論。也許我讀了太多 史蒂芬·奧格雷迪 的文章，但我感到一股不可抗拒的衝動，想用問答的方式來做。所以，它來了。

當 特定領域語言 的主題出現時，常見的謎題之一就是什麼是或不是 DSL。問題在於 DSL 沒有明確的定義，DSL 與其他事物之間存在很大的灰色地帶。

軟體開發中的大多數新想法實際上都是舊想法的新變種。本文描述了其中一種，即我稱之為語言工作台的一類工具的興起概念，其中包括 Intentional Software、JetBrains 的 Meta Programming System 和 Microsoft 的 Software Factories。這些工具採用一種舊式的開發方式，我稱之為語言導向程式設計，並使用 IDE 工具來嘗試使語言導向程式設計成為一種可行的途徑。雖然我還不足以預測它們是否會實現自己的目標，但我確實認為這些工具是軟體開發領域最有趣的事情之一。足夠有趣，可以寫這篇文章來嘗試解釋它們是如何運作的，以及它們未來用途的主要問題，至少要概述一下。

我們的軟體邏輯大部分都是用程式語言寫的，這些語言提供了最佳的環境來撰寫和演化此類邏輯。但有些情況下，將此邏輯移到我們的命令式程式碼可以詮釋的資料結構中會很有用，也就是我所稱的適應性模型。以下我將展示 JavaScript 中的一些產品選擇邏輯，並說明如何將其重構為編碼在 JSON 中的簡單產生式規則系統。此 JSON 資料讓我們可以使用不同的程式語言在裝置之間共用此選擇邏輯，並在不更新這些裝置上的程式碼情況下更新此邏輯。

DSL 是否允許商業人士在不涉及程式設計師的情況下撰寫軟體規則？

當人們談論 DSL 時，通常會提出商業人士自行撰寫程式碼的問題。我喜歡將 COBOL 推論套用在此一思維中。也就是說，COBOL 最初的目標之一是讓人們在沒有程式設計師的情況下撰寫軟體，而我們知道結果如何。因此，當任何計畫都是為了在沒有程式設計師的情況下撰寫程式碼時，我必須詢問這次有什麼特別之處，可以讓它成功，而 COBOL（以及許多其他事物）都失敗了。

在討論 特定領域語言（或任何電腦語言）時，一個常見的片語是雜訊語法。人們可能會說 Ruby 比 Java 雜訊少，或外部 DSL 比內部 DSL 雜訊少。在語法雜訊中，人們指的是不屬於我們真正需要表達內容的一部份，但卻存在於滿足語言定義的額外字元。雜訊字元很糟糕，因為它們會模糊我們程式的意義，迫使我們找出它在做什麼。

我在特定領域語言的書中使用模式結構來組織我用來描述 DSL 的概念。此目錄是該書中模式的清單。每個模式都連結到每個模式的頁面。雖然這些頁面沒有包含太多詳細資訊，但它們確實為每個模式提供參考 URI。