說明性程式設計

世界上最常見的程式設計語言是什麼？

我不確定如何衡量這個問題，但你必須考慮的一件事是我們對程式設計的定義。我的候選答案認為最受歡迎的程式設計語言是一種被不認為自己是程式設計師的人廣泛使用的語言。這種語言是 Excel，或更普遍的試算表。

試算表很容易用於小型任務，但也用於令人驚訝的複雜且重要的事情。我經常看到專業程式設計師在意識到某些重要的業務功能是由他們認為太複雜而無法處理的試算表執行時，會感到驚訝。

一般來說，對於這些類型的LayProgrammers，我們在程式設計語言方面沒有太大的成功。每當有人談論某個新環境，它將允許人們在「不編寫程式」的情況下指定複雜的行為時，我都會提到 COBOL，它最初的設計目的是為了擺脫程式設計師。因此，考慮 Excel 可以教我們有關程式設計環境的知識非常重要。

試算表的一個特性，我認為很重要，是它將程式的執行與其定義融合在一起的能力。當你查看試算表時，試算表的公式並不明顯，相反，你看到的是計算出的數字 - 程式執行結果的說明。

將範例用作程式設計環境的一等元素出現在其他地方 - 使用者介面設計師也有這個問題。提供程式輸出具體說明有助於人們了解程式定義的作用，以便他們可以更輕鬆地推論行為。

那麼，為什麼我覺得我們需要這個特定的Neologism？基本上是因為我認為它值得更多思考。我們在沒有真正思考它們或它們的特殊之處 - 甚至它們在某些方面是特殊的 - 的情況下，就通過說明性程式設計範例。我們已經使用說明性程式設計多年，但我們沒有給予它足夠的關注。我們沒有足夠思考它的基本品質是什麼，它的優點和缺點是什麼。

我選擇「說明性程式設計」一詞來描述這個概念，部分原因是「範例」一詞已被大量使用（而說明則否），但「說明」一詞也強化了範例執行說明的性質。說明旨在透過提供不同的觀點來協助說明概念，類似地，說明性執行旨在協助您在變更程式時了解程式的運作方式。

當嘗試明確說明概念時，思考邊界情況會很有幫助。一個邊界是使用程式資訊的投影，例如在您處理程式碼時向您顯示類別階層的 IDE。在某些方面，這很類似，因為當您修改程式時，階層顯示會持續更新，但關鍵的差異在於階層可以從程式的靜態資訊中衍生。說明性程式設計需要來自程式實際執行的資訊。

我也將說明性程式設計視為超越動態語言的經典 REPL 迴圈的概念。REPL 迴圈讓您可以探索執行，但它們不會像試算表處理其值那樣將範例放在最顯眼的位置。說明性程式設計技術將說明放在您編輯體驗的最前線。程式退居幕後，只有當我們想要探索說明的一部分時才會出現。

我不認為說明性程式設計都是好的。我從試算表和 GUI 設計器中看到的一個問題是，它們很擅長揭示程式的運作方式，但會淡化程式結構。因此，複雜的試算表和 UI 面板通常難以理解和修改。它們經常充滿不受控的複製貼上程式設計。

這讓我想起一個後果，那就是程式會為了說明而被淡化。因此，程式設計師不會想到要處理它。即使在一般程式設計中，我們也因為缺乏對程式的關注而受苦，因此，由非專業程式設計師撰寫的說明性程式會出現這種情況也就不足為奇了。但這個問題會導致我們建立的程式在成長後很快地變得難以維護。未來說明性程式設計環境的挑戰在於，協助在說明的背後開發一個結構良好的程式，儘管說明也可能使我們重新思考什麼是一個結構良好的程式。

這部分最困難的地方可能是輕鬆建立新抽象化。我對豐富的客戶端 UI 軟體的觀察之一是，它們會變得複雜，因為 UI 建構器只會從螢幕和控制項的角度思考。我這裡的實驗向我表明，您需要為程式找到適當的抽象化，這將採取不同的形式。但這些抽象化不會受到螢幕建構器的支援，因為它只能說明它所知道的抽象化。

我的同事 Rebecca Parsons 和 Neal Ford 也花費很多時間思考這些方向。以下是 Neal 在電子郵件交流中提出的一些想法

• 我認為這些工具最適合一般人（因此，您連結到 LayProgrammers）。然而，一般來說，此類工具會讓有經驗/能力的使用者速度變慢。當您提到 UI 面板時，Mac 充滿了這類型的控制項。我在 Keynote 花了很多時間，擺弄檢查器。至少所有這些控制項都放在同一個地方（不像新的功能區）。我更喜歡一種標記語言，我可以使用它直接定義內容，並使用巨集、片段，以及我作為開發人員習慣的所有其他內容。
• 隨著這些工具的發展，它們變得難以使用（也許是因為它們不再足夠特定於領域？）看看 Word、Excel 和 PowerPoint。他們必須發明新的 UI 比喻來公開這些工具的所有功能。程式語言中的 API 具有更好的擴充性，在難以導覽之前，密度會增加幾個數量級。
• 所有最佳實務和工具都不存在：重構、測試層級等。此外，您會失去與文字的連結，這表示巨集功能不存在或複雜的一次性功能。我認為一個很好的比較可以凸顯說明性程式設計的限制，就是 bash（龐大、深奧、強大、古怪）與 Automator 的比較。我幾乎從不使用 Automator，因為它會受到 Dietzler 定律 的影響：它總是缺少我需要功能的 10%。我願意處理 bash 粗糙的表面區域，因為它提供了更多功能。
• 我與您分享對這類工具的看漲情緒，但它們距離對全面敏捷開發有用的時間還很長。我希望它們能快速成熟。

-- Neal Ford

少數認真看待說明性程式設計的人之一是 Jonathan Edwards。他提出了許多非常有想像力的想法，說明此類環境應該是什麼樣子。他對說明性程式設計的願景也與投影式編輯和受控複製貼上的概念緊密相關。

促使我想在此創造一個術語的觸發因素，是 IntentionalSoftware 等人使用語言工作台中說明性程式設計。這些語言工作台鼓勵您建立說明性 DSL。在此情況下，使用說明很重要，因為這應有助於吸引一般程式設計師，這是使用 DSL 的目標之一。挑戰在於做到這一點，同時不會陷入程式結構不佳的陷阱。