一種語言

我們是否應該努力在開發工作中只使用一種語言？

在過去十年的大部分時間裡，企業軟體世界的時尚一直是專注於一種標準語言來進行軟體開發工作。許多開發組織努力在 Java（或 C#/VB）中完成所有工作。

這樣做的理由是開發人員發現很難精通多種語言。堅持使用單一語言可以降低學習負擔，尤其是在雇用新人的時候。

這說法有些道理，但也有很多遺漏之處。程式設計環境部分是語言，但也是關於語言和架構。較大的架構，例如 Hibernate、Struts、ADO，即使您使用單一主機語言對它們進行程式設計，學習起來也像語言一樣具有挑戰性。通常，在主機語言中表達您需要的內容的難度非常尷尬，以至於許多架構訴諸於設定檔，這些設定檔實際上是用 XML 編寫的外部 DomainSpecificLanguage，這為它們增添了一種 80 證明醜陋的混合物。

對於許多開發人員來說，單一語言的概念是缺乏專業精神的象徵。這最好由 實用程式設計師的建議來證明，即每年學習一種新語言。這裡的重點是程式設計語言確實會影響您對程式設計的想法，而學習新語言可以幫助您以不同的方式思考解決問題的方法。（為了獲得此好處，學習差異很大的語言非常重要。Java 和 C# 太相似了，無法計算在內。）

我同意實用主義者的建議，就像在其他事情上一樣。但我也很同情學習新語言的負擔。我個人的腳本幾乎都是用 Ruby 完成的，而且我一直在不願意玩 Python、Groovy 或 PowerShell 等合理的替代方案。這並不是說使用替代方案很困難，而是因為使用 Ruby，我知道太多我必須使用替代方案來尋找的東西。

這裡的重要一點是，當我撰寫這些腳本時，我並非在操作新的抽象概念。我所做的很多事情都在於修補文字、檔案系統以及 XML 或 YAML 塊。如果我需要採用一個相當大的新抽象概念，那麼將其作為函式庫學習的成本並不會比學習一種語言來操作它低多少。如果我想為顯示指定一個有向圖結構，學習 Graphviz 的 Dot 語言幾乎不比學習一個新的 Ruby 函式庫更費力。

使用 DSL 而不是函式庫可以為我們提供更好的方式來操作我們的抽象概念。這使得我們更容易看到我們寫了什麼並揭示我們的意圖。API 就像宣告一個詞彙表，DSL 添加了一個語法，允許您撰寫連貫的句子。

此論點對 DSL 來說很強，但它也適用於通用語言嗎？如果您使用 Java（或不久後的 C#）工作，那麼在您的平台上使用 Ruby 是否有意義？

在過去十年中，記憶體管理的 C 基礎語言興起。人們看到，儘管多年來的懷疑，記憶體管理讓生活變得更好，以至於值得在企業界遠離 C 和 C++。一個通用的平台和語言也將人們從 Powerbuilder 和 Delphi 等專有封閉環境中拉了出來。

現在有一個類似的問題。現代腳本語言是另一項進步嗎？我們是否偏好它們精心選擇的簡潔性？一次又一次地，我聽到經驗豐富的 Java 和 C# 開發人員報告說，他們在 Ruby 中更有效率 - 這是為什麼我一直在鼓勵使用 Ruby。如果在未來幾年中關於其他語言也出現類似的報告，我不會感到驚訝。

十年前，我在 OOPSLA 96 上與我的老朋友湯姆·哈德菲爾德交談。Java 的崛起顯而易見，而 Smalltalk 的未來顯然註定要失敗。儘管我熱愛 Smalltalk，但我還是很樂觀。我覺得 Java 給了人們他們需要的大部分東西；雖然它不如 Smalltalk 那麼好，但它比 C++ 有了足夠的改進，特別是在記憶體管理方面，這讓我很滿意。湯姆不同意，他覺得 Smalltalk 的表達力有根本的不同，你可以直接在程式碼中更好地捕捉你正在做的事情的意圖 - 縮小領域知識和程式設計之間的差距。

在過去的幾年中，我開始認為湯姆畢竟是對的。在花括號世界待了幾年後，Ruby 讓我想起了我錯過了什麼。閱讀 Ruby 程式碼時有一種清晰度，儘管工具較差，但它只是一個更容易使用的媒介。我比當時更同情 Smalltalk 的堅持者，儘管我很久沒有生氣地開啟一個影像了。

那麼我們是否會回到 80 年代末期和 90 年代初期的語言混亂？我想我們會看到多種語言胡言亂語，但會有重要的差異。在 80 年代末期，很難讓語言緊密地相互操作。如今，人們非常重視建立允許不同語言緊密共存的環境。腳本語言傳統上與 C 有著密切的關係。在 JVM 和 CLR 平臺上進行互操作需要付出很多努力。對於一個語言來說，在函式庫上投入太多而忽視它們是不行的。

因此，我的感覺是，我們將看到多種語言用於專案中，人們會根據語言的功能來選擇語言，就像人們現在選擇框架一樣。我同意 Neal 的觀點，我們正在進入多語言程式設計時期。