DSL 邊界

當提到 特定領域語言 這個主題時，最常見的困惑之一就是什麼是或什麼不是 DSL。問題在於 DSL 沒有精確的定義，而且 DSL 與其他事物之間有一個很大的灰色地帶。

對我來說，一個關鍵要素是 DSL 在範圍（它們指的是特定領域）和功能（它們缺乏一般用途語言的基本功能）上都是有限的。因此，好的 DSL 通常都很小而且簡單：因此有了「小語言」和「迷你語言」等術語。

對於內部 DSL，模糊的界線在於什麼是 API，什麼是 DSL。從根本上來說，沒有什麼不同，內部 DSL 只是一個具有花俏名稱的 API（正如貝爾實驗室的舊諺語所說：「程式庫設計就是語言設計」）。儘管如此，我認為當您使用以 DSL 感覺編寫的 API 時，感覺還是有所不同。像 流暢介面 之類的東西可以讓使用 API 的體驗產生質的差異。用 DSL 術語思考會讓您以不同的方式思考可讀性，利用主機語言的語法來建立看似獨立的東西——rake 就是一個很好的例子。

當談到外部 DSL 時，問題通常會以 DSL 與一般用途語言 (GPL) 之間的差異是什麼的形式出現。通常一個明確的跡象是當 DSL 不是圖靈完備或缺乏抽象設施時。正規表示式就是這種功能限制的一個很好的例子。SQL 是個更有趣的候選者。它是一種複雜且功能強大的語言，但既缺乏圖靈完備性，也缺乏建立新抽象的能力。

一種語言可以是圖靈完備的，但仍然是 DSL 嗎？Ploticus 的腳本語言是圖靈完備的，但它明確專注於在 Ploticus 中產生圖形，這讓它成為一個 DSL——至少對我來說是這樣。但是 XSLT 呢？它也專注於轉換 XML 文件，但它已經獲得了如此多的功能，以至於人們越來越將它視為 GPL。

Ploticus 的例子引發了一個問題，即嵌入式語言是否是 DSL。當 Excel 的巨集語言與 Visual Basic 幾乎相同時，它是否是一個 DSL？如果您將一種通用腳本語言嵌入到應用程式中，會發生什麼事？

如同內部 DSL 與 API 的問題，我認為意圖是關鍵，無論是語言撰寫者或使用者。如果我只使用 XSLT 來轉換 XML 文件，那麼我將其視為 DSL，即使我進行一些花俏的呼叫來將一些值嵌入輸出文件。然而，如果我使用它來解決八皇后問題，我將它用作 GPL。如果 XSLT 的設計者將其視為 XML 轉換，那麼他們會將其視為 DSL，即使聰明的人對它做了一些不自然的事情。

這是一個有趣的話題，可以在酒吧裡討論，但不應貶低使用 DSL 的好處。DSL 應設計為用於專注於單一問題的受限語言。如果您在設計和使用時最先想到這個想法，它們將很有用。畢竟，真正重要的是它的用處。