讓不會寫程式的人寫程式
2023 年 1 月 24 日，提出 Vibe Coding 這個詞的大大 Andrej Karpathy 發了一則只有一句話的推文：
The hottest new programming language is English.
現在最熱門的新程式語言是英文。
這句話後來到處都看得到，連我自己也講過。不過後來我去翻了一些資料，發現這個「願望」比這句話更早出現，早在 1959 年就有一整個委員會，花了一整個語言的設計成本很認真地做過這件事。最近準備 AI Coding / Vibe Coding 課程，在寫關於需求拆解的教材才想到也有人說過「需求會成為新的程式語言」這樣的講法，考了一下古才發現原來這早就不是新鮮事。我們先看看前面幾次是怎麼收場的，也許會對這個主題有不同的想法。
讓主管讀懂程式？
1959 年五月，美國國防部在五角大廈找了一批人開會。當時許多程式仍以機器語言、組合語言，或綁定特定機型的語言與工具撰寫。IBM 的機器跟 UNIVAC 的機器環境不一樣，所以一套跑得好好的薪資系統，換一台機器往往得大幅轉換甚至重寫，而且還不是改幾行就搬得過去。有份歷史研究轉述的 1959 年調查算過這件事，一個單位開發程式平均花 80 萬美金，把這些程式搬到新機器上得再花 60 萬。
這場會議促成了 CODASYL 這個組織，成員有 IBM 以及 Honeywell 等數家知名企業，任務是做一個能跨機器用的商業運算語言，最後做出來的東西就是大家後來知道的 COBOL。
他們想做的不只是跨機器，而且還想讓這個語言接近英文，讓會計、財務、保險等業務人員能夠讀得懂，讓主管能看懂邏輯。
Grace Hopper 是這條路線最重要的推手，她在 UNIVAC 做的 FLOW-MATIC 是 COBOL 的前身，也是第一個用類英文語句來寫資料處理的語言。她自己講過為什麼要做這件事：
I used to be a mathematics professor... I then was charged with the job of making it easy for businessmen to use our computers. I found it was not a question of whether they could learn mathematics or not, but whether they would. They said, "Throw those symbols out — I do not know what they mean, I have not time to learn symbols."
我以前是數學教授，後來被指派的工作是讓生意人能輕鬆用我們的電腦。我發現問題不在於他們學不學得會數學，而在於他們願不願意學。他們說：「把那些符號丟掉，我不知道那是什麼意思，我沒時間學符號。」
出處是 History of Information 收錄的 Hopper 口述。她另外還提過一件事，說她做出第一個編譯器的時候沒人敢碰，因為當時大家「很仔細地告訴我，電腦只會做算術」。
真的做到了？
COBOL 為了「可讀性」所付出的代價是實打實的，看看這段精美的語法：
IDENTIFICATION DIVISION.
PROGRAM-ID. PAYROLL.
PROCEDURE DIVISION.
MULTIPLY HOURS-WORKED BY HOURLY-RATE GIVING GROSS-PAY.
IF GROSS-PAY IS GREATER THAN 1000
PERFORM CALCULATE-TAX.
沒有 *、 > 或是大括號這些常見的程式語法，動詞全部是英文單字：MOVE、ADD、MULTIPLY、PERFORM。程式被切成 IDENTIFICATION、ENVIRONMENT、DATA、PROCEDURE 四個 DIVISION，念起來像公文的章節。
最能看出設計意圖的是上面那個 IS，這個語法很有趣，它在語法上基本上沒有作用，而且拿掉照樣可以編譯，它存在的理由只是讓句子讀起來像英文。COBOL 規格裡專門有一類叫 optional words，整批都是這種東西，行話叫 noise words。
一個程式語言願意把「這個字可以不寫，但我們還是提供它，因為這樣念起來比較順」寫進規格，可見他們對那個目標還滿認真的。幾年前我因為興趣想自學 COBOL 的時候就覺得這些設計很特別，以為它就只是個程式語言，沒想過為什麼這樣設計。
但在 COBOL 上線之後，讀它、寫它、維護它的主要還是程式設計師！那些為了給不寫程式的人看而多設計出來的冗長語法，最後還是技術人員在打、在讀。
好啦，這不太意外而且原因也不難猜，其實主管讀不懂程式，卡住的地方通常不是 * 這些符號，而是這段程式碼在做什麼判斷、狀態被誰改過、為什麼這裡要特別處理某一種情況。把符號換成英文單字，這件事好像沒有因此變簡單多少。（有沒有有種即視感？）
不過這不代表 COBOL 失敗了，它到今天還在跑銀行核心、保險理賠、政府稅務系統，運轉超過六十年，以一個 1959 年的語言來說是很誇張的成績，只是沒有做到當初講的那一件事。
SQL 也是
這件事我一直到最近才知道。
1974 年，IBM 聖荷西研究中心的 Donald Chamberlin 跟 Raymond Boyce 發表了一篇論文，題目是 SEQUEL: A Structured English Query Language。名字裡的 English 不是裝飾。他們的設計哲學是讓不懂數學的人也能用，用一組英文關鍵字模板，對應人們平常怎麼看表格找資料。SEQUEL 後來因為商標問題改名成 SQL。Chamberlin 在 2024 年接受 DataCamp podcast 訪問，回顧了這件事：
We thought that SQL would be used by what we call casual users who were not computer programmers.
我們原本以為 SQL 會被我們稱為「一般使用者」的人拿去用，那些不是程式設計師的人。
然後他說了結果：
The actual users of SQL turned out to be mostly programmers building database applications.
SQL 實際的使用者最後大多是在做資料庫應用的程式設計師。
他沒有把這件事講成一場失敗，他接著說 SQL 讓這些程式設計師的工作變得更輕鬆也更有效率，所以這仍然是好事。訪談裡還有一句，他說當初設想的那些一般使用者確實存在，只是他們去用了別的東西：
They're using Google and increasingly, I think they're starting to use AI systems like ChatGPT.
他們在用 Google，而且我覺得他們越來越常開始用 ChatGPT 這類的 AI 系統。
一個語言的發明人，五十年後親口說當初設想的使用者跑去用 AI 了 :)
「最後一個」
英國一家叫 D.J. "AI" Systems 的公司在 1981 年推出一套產品，名字是 The Last One。取這個名字的意思是，它是最後一個需要被人寫出來的程式，因為之後所有的軟體都可以由它產生（以結果來看它並不是最後一個）。
實際上它是一個 BASIC 程式碼產生器，使用者從選單裡選一選，最後產出一支 BASIC 程式。能做的是很基本的商業應用，報表、簡單的資料管理那一類。
隔年，James Martin 出了一本書，書名叫做 Application Development Without Programmers。這本書在推廣第四代語言（4GL），主張把工具交給使用者，讓他們自己開發自己要的應用程式，藉此解決當時公司裡積了很久的開發需求。Simon Willison 在 2025 年翻出這本書，引了裡面一段：
Computers have become cheaper than people. The number of programmers available per computer is shrinking so fast that most computers in the future will have to work at least in part without programmers.
電腦已經比人便宜了。每台電腦分配得到的程式設計師數量正在快速減少，未來大多數的電腦將必須在某種程度上，在沒有程式設計師的情況下運作。
這是 1982 年寫的，如果把上面的句子裡的「電腦」換成「AI Agent」之後再讀一次，有沒有覺得有點熟悉？
4GL 這一波之後，同一個訴求換了幾次名字。1990 年代有 Visual Basic、PowerBuilder、Delphi 這些 RAD 工具。2001 年 OMG 推出 MDA（模型驅動架構），主打以 UML 建立平台獨立模型，再由工具自動或半自動轉成平台模型與部分程式碼，如果把 UML 換成 Spec 或 PRD，是不是覺得有點像？
2012 年 Bubble 上線，把不寫程式做應用程式變成一門生意。2014 年 Forrester 的兩位分析師 Clay Richardson 與 John Rymer 在一份報告裡創了 low-code 這個詞，大家可能因為 n8n 之類的工具才認識 low-code，但其實這個詞早就有了。
自然語言寫程式？
這篇文章我以前沒讀過，這次查資料才翻到。編號 EWD667，標題叫〈On the foolishness of "natural language programming"〉，翻成中文大概是「用自然語言寫程式這件事有多蠢」，標題有點兇，他的第一個論點是關於介面成本：
We know in the meantime that the choice of an interface is not just a division of (a fixed amount of) labour, because the work involved in co-operating and communicating across the interface has to be added.
我們現在知道，選擇一個介面並不只是把一份固定的工作量切開分配，因為跨越這個介面去協作與溝通所需要的工作，是要另外加上去的。
換句話說，把工作丟給機器不代表你這邊的工作就變少了，你會多出了「跟它溝通」這件事。第二個論點更直接，他針對的是「自然」這兩個字：
When all is said and told, the "naturalness" with which we use our native tongues boils down to the ease with which we can use them for making statements the nonsense of which is not obvious.
講到底，我們使用母語時的那種「自然」，歸結起來就是：我們可以很輕鬆地用它講出一些「不明顯是廢話的話」。
這句話很有意思，我自己也沒想過這件事，自然語言之所以用起來輕鬆，正是因為它讓你可以說出一堆聽起來沒問題但實際上沒有內容的句子，而且說的人自己不會發現，也就是俗稱的「廢話」。形式語言（或程式語言）之所以難用，是因為每一個沒想清楚的地方，它都會逼你補上。
最後他給了一個預測：
I suspect that machines to be programmed in our native tongues —be it Dutch, English, American, French, German, or Swahili— are as damned difficult to make as they would be to use.
我懷疑那種可以用我們的母語來下指令的機器，不管是荷蘭語、英語、美語、法語、德語還是史瓦希利語，做出來會有多困難，用起來就有多困難。
四十幾年後這種機器真的做出來了，背後仍然很難做，但用起來還算順手，我現在每天都在用。他低估的不是做出這種機器的難度，而是自然語言介面可以變得多順手。
但他說的「自然語言的自然就是可以輕鬆說出沒有內容的話」到今天還是成立，我每天寫 prompt 跟寫規格都會遇到，寫完覺得講得很清楚，丟給模型才發現有幾個地方我根本還沒決定。
誰真的做到了？
前面講了一整串沒做到的，但有一個真的做到了，而且做到的規模大到有點嚇人。所以是誰？
就是大家都用過的試算表。
Christopher Scaffidi、Mary Shaw 與 Brad Myers 在 2005 年發表過一篇論文，Estimating the Numbers of End Users and End User Programmers，用美國勞工統計局的職業推估去算 end-user programmer 的人數。他們對 2012 年的推估是：
- 美國會有大約 9000 萬人在工作上使用電腦
- 其中超過 5500 萬人會用到試算表或資料庫，也就是有機會成為 end-user programmer
- 有 1300 萬人會自稱是 programmer
- 而勞工統計局推估的專業程式設計師人數，不到 300 萬
要注意這是 2005 年做的推估，不是事後的實測，數字要打點折扣。不過就算把數字砍一半，那個量級的差距還是在的。
Microsoft Research 的 Andy Gordon 與 Simon Peyton Jones 有一句說法是，寫 Excel 公式的人比全世界所有 C、C++、C#、Java、Python 程式設計師加起來還多一個數量級。這是微軟在講自己的產品，沒有附計算方式所以這個數字不用太當真，不過方向跟上面那篇論文對得起來。
重點是那些人多半不覺得自己在寫程式。
怎麼做到的？Bonnie Nardi 在 1993 年寫過一本書叫 A Small Matter of Programming，用人類學的方法去觀察試算表跟 CAD 的使用者，想搞清楚這兩個東西為什麼成功。
她其中一個結論是 task-specific programming language，也就是針對特定任務設計的語言。你想加總一欄數字，就給你一個 SUM，不要叫你宣告一個計數器再寫一個 for 迴圈。工具照著任務設計，而不是先給你一套通用的計算模型，再要你自己組出想要的東西。
我自己覺得還有另一件事同樣關鍵，而且是前面那幾輪全都沒有的，就是當你打完公式按下 Enter，數字馬上出現在格子裡。算錯了你當場看得出來，因為你知道那一欄加起來應該差不多是多少。
COBOL 沒有這個，SQL 有一點，你下完查詢馬上看到結果，這也是為什麼 SQL 在「一般使用者」這條路上雖然沒成功卻至少比 COBOL 多走了幾步。The Last One 那種選單式產生器的回饋慢得多，也比較間接。你選一選，最後吐出一份 BASIC 程式碼，再執行、檢查結果，必要時修改設計重新產生；至於生成的程式碼看不看得懂就是另一回事了。
所以試算表真正動到的地方是回饋，前面那幾輪一直在改的都是怎麼把話講給電腦聽，試算表多做的一件事，是讓你在按下 Enter 的那一秒就知道自己有沒有講對。
試算表長成了程式語言
2020 年 12 月，微軟在 Excel 裡加了 LAMBDA，2022 年 2 月正式推出。它讓使用者可以用 Excel 公式自己定義新的函式，而且這些函式可以互相呼叫，可以遞迴。
這件事的效果是，Excel 的公式語言變成圖靈完備（Turing-complete），也就是說原則上任何一種計算都可以用 Excel 公式寫出來。微軟研究院自己的標題就寫著 Making Excel Turing-complete。
換句話說，一個成功讓大量不以程式設計師為職業的人透過公式進行程式化計算的工具，發展了三十幾年之後，被使用者的需求推著長出了自訂函式跟遞迴。那些人一開始只是想加總一欄數字，做著做著就需要更多東西。
我不覺得這是壞事，抽象層是真的往上移了一階，那一階也真的很有價值，只是站上去之後你會發現上面還有事情要做。
現在呢？
這一輪確實跟前面幾輪不一樣。
前面幾輪大多在降低表達、轉換或開發流程的成本，試算表還另外改變了回饋的速度。這一輪不同的地方在於，它讓人不必先把需求翻成形式化語法，就能直接用自然語言跟模型來回溝通。2020 年已經有用英文自然語言生成小型可執行程式的展示，但離今天這種可以用中文溝通、跨檔案修改並反覆驗證的工具還很遠。
也因為語法這一關真的過了，剩下的那幾件事第一次變成主要的問題。你還是得知道自己要做什麼，得看得出來做出來的東西對不對，出問題的時候得知道是哪裡出問題。
Karpathy 自己對這件事講得比多數轉發他那句話的人清楚。2025 年 2 月 2 日，他在一則推文裡創了 vibe coding 這個詞，原文描述的狀態是 fully give in to the vibes, embrace exponentials, and forget that the code even exists，完全交給感覺，忘記程式碼的存在。接受所有修改、不看 diff、有錯就把錯誤訊息貼回去。他在同一則貼文裡寫下這句：
It's not too bad for throwaway weekend projects, but still quite amusing.
拿來做週末隨手丟掉的專案還算可以，不過還是挺好玩的。
發明這個詞的人自己把適用範圍講成「週末隨手丟掉的專案」。Simon Willison 後來補了一個更清楚的定義：vibe coding 指的是不去審查 AI 寫出來的程式碼，如果你有讀、有測、講得出它在做什麼，那不叫 vibe coding，那就是在寫程式。
小結
Alan Perlis 在 1982 年的 Epigrams on Programming 裡有一條，編號 93：
When someone says: "I want a programming language in which I need only say what I wish done," give him a lollipop.
當有人說「我想要一種程式語言，我只需要說出我希望完成什麼」，給他一根棒棒糖。
所以要說「需求正在成為新的程式語言」對不對，我會說抽象層確實又往上移了一階，但如果從這裡推論成站上去之後就不需要專業了，前面幾輪沒有一輪支持這個結論。COBOL 沒有，SQL 沒有，4GL 也沒有，試算表算做到了一半，然後它自己長出了 LAMBDA。
AI 這一輪的結局還沒到，不過如果照前面幾輪的模式，那個會長出來的東西現在應該已經在發生了。我猜就在那幾件以前藏在寫程式裡面、現在被拆出來的事情上，把需求講清楚、把驗收條件寫下來、確認生出來的東西真的是你要的。
Chamberlin 說他當初想服務的那些一般使用者，現在主要在用 Google，也逐漸開始用 ChatGPT 這類的 AI 系統。那些人等了五十年才等到一個真的能用的東西，這樣講我覺得也沒錯。至於十年後回頭看會怎麼樣，我猜寫程式這件事還會在，只是那個位置上的人要會的東西又換了一輪。
人類的歷史總是不斷的重複上演，這一輪會不會不一樣，我們就繼續看下去 :)
