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

這是我的常規 DSL 簡介演講，但由於我對著比平常更了解 DSL 的聽眾說話，所以加入了一些變化。因此，我基本上把它改成關於我如何向人們介紹 DSL 的演講。

Microsoft Channel 9 對我、我的同事 Neal Ford 和 Jeffery Snover (PowerShell 的創建者) 的訪談。一般主題是 DSL，Neal 和我剛在 JAOO 2008 完成關於這個主題的教學課程，並與 Jeffery 進行了一些良好的對話。

當我參加 DSL DevCon 時，Microsoft 的 Channel 9 將我拉走接受 Chris Sells 的訪談。

我和 Neal Ford 共同為伺服器端 Java 研討會所做的重點演講。我們探討了特定領域語言的發展趨勢、現有的語言類型，以及它們為何有趣。如果你想找一場關於此主題的演講，我首推 JAOO 影片，但這場演講擴展了一些主題，而且由於 Neal 的參與而更具娛樂性。如果你能找到方法擷取音訊串流，僅使用音訊也能達到良好的效果。

我與 Thoughtworks 的技術長 Rebecca Parsons 共同參與了 DSL 書籍的撰寫，並與 Markus Völter 討論 DSL。我們討論了 DSL 的定義、內部和外部 DSL 的差異，以及你應該（或不應該）使用 DSL 的時機。

DSL 能否讓企業人員在不涉及程式設計師的情況下撰寫軟體規則？

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

我經常遇到聲稱某些技術將允許使用者撰寫自己的軟體，而不再需要程式設計師的說法。當我聽到這句話時，我喜歡記住 COBOL 的目標，而我們知道結果如何。

有人請我為非技術人員整理一份關於 DSL 的討論。也許我讀了太多 Stephen O'Grady 的文章，但我感到一股無法抗拒的衝動，想要以問與答的方式進行。因此，它來了。

特定領域語言 (DSL) 的基本概念是一種電腦語言，它針對特定類型的問題，而不是一種針對任何類型的軟體問題的通用語言。特定領域語言已經被討論，並且使用時間幾乎和電腦一樣長。

當 DomainSpecificLanguage 的主題出現時，其中一個常見的謎題就是什麼是或不是 DSL。問題在於 DSL 沒有精確的定義，而且 DSL 與其他事物之間存在著大片灰色地帶。

撰寫關於外部 DomainSpecificLanguages 的棘手之處之一，在於我正在穿梭於程式語言社群已經深入踏查過的領域。程式語言研究一直是學術活動的熱門領域，而我首先承認，我在這個主題上的深度遠不及許多在這方面研究多年的人。因此，難免會出現疑問，為什麼像我這樣的新手認為自己可以在這片踏實的土地上寫一本書？

DSL 倡導者需要防範的一個危險觀念是，首先設計一個 DSL，然後人們使用它。就像任何其他軟體設備一樣，成功的 DSL 會演變。這表示使用 DSL 早期版本撰寫的腳本，在使用後續版本執行時可能會失敗。

最近幾週，我一直在玩弄和查看編譯器編譯器工具。這些工具的共同特點是，它們有一個語法檔案，其核心是語言語法的產生規則描述。除了描述語法之外，檔案還向剖析器提供有關如何處理語言的資訊，因為它辨識語言元素。在大部分編譯器編譯器工具中，這些指令表示為語法中的動作，通常這些動作編碼為高級語言中的程式碼片段。

FluentInterface 的問題之一，在於它會產生一些看起來很奇怪的方法。考慮這個範例

我一直在探索各種替代語言和語法，用於外部 DSL。我的主要工具之一是 Antlr。有了這種探索，我有一個專案，其中有多個類似的語法檔案，我想使用不同的語法來執行本質上相同的事情。雖然我目前只有幾個語法檔案，但我可能會得到幾十個。

幾個月前，我參加了 Eric Evans 的研討會，他談到某種介面風格，我們決定將其命名為流暢介面。這不是一種常見的風格，但我們認為應該更廣為人知。也許最好的描述方法是舉例說明。

給定、何時、然後是一種表示測試的風格，或者正如其倡導者所說，使用 SpecificationByExample 指定系統的行為。這是 Daniel Terhorst-North 和 Chris Matts 作為 行為驅動開發 (BDD) 的一部分開發的一種方法。它作為許多測試架構（例如 Cucumber）的結構化方法出現。您也可以將其視為 四階段測試 模式的重新表述。

幾年前，我當時的同事 Matt Foemmel 對我們用來建構軟體的工具不滿意，設法與 Charles Simonyi 取得聯繫，以進一步瞭解神秘的 意向軟體。他所看到的讓他印象深刻，並說服我和其他 ThoughtWorkers 也參與其中。我們看到的是一個具有驚人潛力的工具，但我們仍然對保密和缺乏發布的緊迫性感到沮喪。這種沮喪在上週結束了。

內部 DSL（通常稱為嵌入式 DSL）是一種寫在現有主機語言中的 特定領域語言。這是許多程式語言社群（特別是 Lisp 社群）中常見的思考方式。隨著 DSL 成為快速成長的 Ruby 社群中常見的思考方式，它現在正受到很多關注。

語言工作台是我在 2005 年創造的一個術語，用來描述一種新型的軟體開發工具，旨在透過豐富的多元整合 特定領域語言環境來建構軟體。這些工具距離主流還有一段距離，但開發工作仍持續進行，而且持續引起興趣。它們是我認為少數幾個能大幅改變程式設計領域的事物之一。

當我撰寫最近一篇關於 語言工作台 的文章時，我決定將進一步閱讀的章節分開到我的 bliki，以便在有新資訊出現時更容易回報更新。

我使用非專業程式設計師這個術語，是指那些在程式設計時不認為自己是程式設計師的人。每天花大量時間處理試算表的人就是在進行程式設計，而且通常是非常密集的程式設計。然而，她通常不會稱自己為程式設計師，也不會花太多時間學習如何更有效率地進行程式設計。

模型驅動軟體開發 (MDSD) 和 特定領域語言 (DSL) 之間有什麼關聯？

在 MDSD 的背景下看到「DSL」這個術語出現是很常見的。事實上，一些 MDSD 人士似乎認為 DSL 只存在於 MDSD 世界中。我最近為我的書寫了很多關於 DSL 的內容，但到目前為止，我還沒有真正觸及 MDSD 的角度。相反地，我專注於 DSL 在更傳統程式設計中的角色。DSL 存在於文字語言和 MDSD 世界中，並且在兩者中扮演著幾乎相同的角色。

Sergey Dmitriev 是 JetBrains 的領導者之一，這家公司為我們提供了 IntelliJ Idea 和 ReSharper 等絕佳工具。他最近發表了一篇 文章，介紹了他所做的探索性開發，稱為元程式設計系統。他將這個系統視為一個更廣泛運動的範例，他稱之為面向語言程式設計。

模型驅動軟體開發 (MDSD) 是一種軟體開發風格，被視為傳統程式設計風格的替代方案。這種方法以建立軟體系統模型為中心。這些模型通常透過圖示設計符號來表現出來，UML 是一個選項。這個想法是使用這些圖表，將您的系統指定給建模工具，然後再用傳統程式語言產生程式碼。

Oslo 是 Microsoft 的一個專案，本週的 PDC 會議之前，我們已聽聞許多關於它的傳聞，但細節卻所知甚少。我們所知道的是，它與 模型驅動軟體開發 和 特定領域語言 有關。

最近我與許多人討論 特定領域語言，而對於外部 DSL，我常聽到的反應是，撰寫解析器很困難。的確，使用 XML 作為外部 DSL 的載體語法的原因之一，就是「你可以免費取得解析器」。這與我的經驗不符 - 我認為解析器比大多數人想像的容易撰寫，而且並不比解析 XML 困難。

Ruby 最受歡迎的功能之一，就是它支援 元程式設計，也就是說，這些功能就像改變語言本身一樣，引入了類似新關鍵字之類的東西。

我是否應該使用規則引擎？

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

XML 已經存在一段時間了，而且被廣泛使用 - 確實比它應該被使用的還要多。與大多數工具一樣，XML 適用於某些事情，但不適用於其他事情