- 原文地址：Programming Languages and Platforms: an annotated twitter thread
- 原文作者：Steven Sinofsky
- 譯文出自：掘金翻譯計劃
- 本文永久連結：github.com/xitu/gold-m…
- 譯者：cf020031308
- 校對者：pmwangyang
語言和平臺的交織通常源於平臺開發商有意選擇語言。本文基於近期對 Swift 的反饋進行一次簡短的探索。
這條推文串的一個評論。
有見地的帖子，不但細節方面值得一讀，也同樣適用於語言設計和平臺的一般問題。
Apple 開發自己的語言是不可避免的，基因如此。出於各種原因，大多數平臺都希望擁有自己的語言。TODO線索想法...
像大多關於程式語言的文字一樣，@monkeydom 的帖子有些“咋呼”。這個話題是情緒化的，但你若能以平常心讀完，就可以看出一個非常實質的問題：“Swift 解決了什麼問題？又為之付出了什麼？”恕我直言，你會發現這幾乎總是程式語言的實質問題。
最有趣的事情莫過於程式語言和平臺之間的關係。首先提一些歷史。
很久以前，電腦科學等於開發新語言。攻讀博士學位彷彿成了創造程式語言的一道習題，時不時就要用 YACC 和 Lex。
這源於一個高階語言替代組合語言並極大地改善程式設計的大時代。
70 年代和 80 年代“程式語言”深入電腦科學的景象簡直不要太誇張。幾乎每個專業都涉及“語言”和“理論”：理論不是通過程式語言得到表述，就是通過程式語言得到印證與發展。
例如，我在大學時使用的第一種語言稱為 PL/CS，是 IBM 結合 FORTRAN 和 COBOL 開發的專有語言 PL/1 的衍生物。 這個 CS 表示了語言的原理，即通過在編譯時發現未初始化變數和不規範迴圈等失誤來減少程式碼錯誤——這可以說是 lint 之流甚至 IDE 的前身（事實上我們使用的是第一個互動式的編輯器/編譯器，稱為康奈爾程式合成器。
每節計算機理論課都是圍繞不同語言的學習，每次談計算機理論都是聊你使用什麼語言，每份簡歷、每次面試什麼的全是說你編碼用什麼語言。甚至 1989 年我在微軟面試時也是翻來覆去的語言語言，每個面試官都詢問我簡歷上有關不同語言的問題。
我在導彈工廠 Martin Lockheed 的暑期工作最初是編寫 COBOL 程式。但當他們發現我會 C 後（其實不會，只是會用他們的 Lattice C 編譯器），恨不得讓我想寫什麼寫什麼，只求教他們 COBOL 程式設計師 C 語言。這個夏天我寫了個 MS-DOS 版本的檔案複製/重新命名工具，這工具我之前在 CP/M...（啥來著？）上用過，用來製作 Lotus 1-2-3 防拷軟盤的“備份”副本。（譯者注：意指盜版。Lotus 1-2-3 類似 Excel，是當年 IBM 的殺手級應用。）
從大二開始，課上創造語言就很常見了。最流行的初級課是構建一個編譯器。來一次徹底的“龍書”之旅，用上 Unix 的所有工具，全方位構建一個多程編譯器。
“計算機基礎”（雙關語：地下機房）的每一次對話都會發展為哪種語言更好的辯論。四年本科加兩年研究生（程式語言方向!）都在辯論命令式、宣告式、物件、垃圾回收、函式式等。
到我讀研究生的時候，因為程式設計教育的快速推廣，這場辯論達到了高潮，話題轉為什麼語言是學習程式設計的最佳途徑：Pascal 是傳統的教學語言；但 FORTRAN 和 COBOL 好找工作；學院派大多建立在 Unix 上，所以用 C，但 C 又被視為一種“醜陋”的語言。即便 C 已在事實上實現了大多數研究專案，語言界的學術觀點仍是青睞 Lisp、Scheme、M、Algol（在歐洲）、Prolog，當然還有 Smalltalk（我們在實驗室裡構建了一個直譯器作為試驗床），等等。如果你能察覺到什麼共性的話，那就是這些語言沒一個獲得過商業上的成功。
因為語言如此重要，很多“梗”會被列印出來（在點陣列印的寬條形綠色條形紙上），掛在地下室的機房中。
Dilbert 1992 年連環畫
還有這個經典的“程式語言自虐大全”
隨後 C 語言出現了，它似乎打破了抽象、抽象資料型別等所有程式語言的高階規則。對學術界來說，這簡直像組合語言一樣令人生厭。
但它就是成了。
C 語言帶來的是程式設計的廣泛商業化。幾乎每個從暑期工作回來的人（像我一樣）不是暑期用 C 工作過，就是發現他們需要為下個暑期學習 C 語言。Pascal 已無用武之地。PL/1 還可以用在 IBM 的工作中，但連 IBM 也已搖擺不定。另外，我們所有工作都在 Sun 工作站上執行，所以顯然是用 C 語言。我曾花 5 美元購買了我的第一本 K＆R（譯者注：指《C 程式設計語言》一書），然後發現這是一本在印度“非法”印刷的盜版（這成了我的版權法啟蒙）。 C 語言如日中天。大一新生甚至抱怨起 PL/1 以及他們如何在高中被迫使用 Pascal（預修課程試點於 80 年代中期剛剛開始）。
早期的 MS-DOS 和 Mac 完全被組合語言（真™程式設計師）和 Pascal 統治，也有嘗試移植 COBOL 和 FORTRAN 的。大型機則被 PL/1 和一堆老古董佔據，還有 BASIC :-)
但隨後業界爭相轉向 C 語言，大多數商業 PC 都是 C + 彙編。
熱衷 C 語言的主要原因是越來越多的程式設計從大型機轉向了 PC（IBM 的大型機連 C 編譯器都沒有！）。儘管校內還有大量將大型機程式碼移植到 PC 上的兼職工作，大多數人都已意識到這是徒勞的，何況這還遠不如在 PC 上用 Lattice C 特別是 Turbo C 之類低成本的工具探索新的解決方案更令人興奮。Basic 那時的流行不是你能想象的，儘管如今很多地方只是因為無處不在的 PC 而教它。1984 年連微軟都出過 Mac Basic (實際上在康奈爾大學酒店管理學院的新生班中使用過)。
個人電腦（PC）直到 Windows 3.0/i386 都記憶體吃緊，所以還有很多彙編程式存在。編譯器還是不夠好，浮點運算或 I/O 等很多東西必須用匯編來完成。大多數商業程式碼中還常能看到用 C 結構體
_inline{}做系統呼叫或浮點計算。
1984 年的 Mac 真的想成為 Pascal（優雅），Apple 的所有早期工具都是 Pascal。由於支援了 C，最終 C 也開始主導 Mac 開發。
NeXT 上的 Obj-C 能發展到 iOS 上是大勢所趨。
Mac 始終關注優雅、控制、垂直整合，最重要的是一直貫徹“教育”理念。因此它選擇 Pascal 是很自然的，尤其是考慮到當時的時間點。像大多數 1983 年的 Mac 程式設計師一樣，我使用的是 Pascal。第一批工具書和 Apple 工具（Apple 自己的開發環境 Macintosh Programmer’s Workshop 還沒推出）都是基於 Pascal 的。實際上，你要是入行夠早的話，一定會為了開發 Mac 程式而搞到 Apple Lisa，因為它預裝了 Pascal。
這種情況沒有持續太久，因為第三方世界像 Lightspeed 和其他人努力在提供像 C 這樣的“專業”語言。在 Macintosh Programmer's Workshop 或 C 出現之前，我已毅然切換到了 Lightspeed。
Pascal 的關鍵在於它有一個非常清晰的 API 文件，裡面沒有 #define 或其他什麼含糊混亂的東西讓我抓狂。就這方面，堪稱美妙。
出於這些原因，幾年後的 NeXT 隨著“物件導向”和 C++ 的興起必然會選擇用 Objective-C 取代 Pascal，他們因此可以擁有像是帶記憶體管理或垃圾收集的類一樣的物件導向功能，這能解決非虛擬的 Mac OS 中的很多很多頑固的問題。
圖形平臺總是渴望能“擁有”一種語言，因為他們希望儘可能以最一致的方式來控制作業系統。
可能有學究會說這是“平臺獨佔”。
請務必記住，我們今天看到的平臺和語言之間因抽象層而得來的分離在當時並不存在。在圖形介面的世界中，使用 C 加 Pascal 編寫 Mac 程式的能力是非常少有的。當然，圖形介面本身也是平臺獨佔的——是否獨佔對開發商如何實現一切十分關鍵。但這也對消費者的看法產生了負面影響，因為“獨佔 = 繫結”，幾乎所有人都不想再受制於一輪獨佔的“小型計算機”。
開發人員總是希望將程式碼從一個作業系統移植到另一個作業系統。就如這裡談了這麼多的，在平臺發展的早期階段，平臺之間共性多、差異少，這似乎是可行的。
所以那時平臺獨佔的語言被視為“繫結”。
而且實踐上，即使使用標準/公共/官方語言，只要你大部分程式碼都是在呼叫作業系統 API，也一樣算“獨佔”的。
想想專門給一個平臺編碼時有多少交織的程式碼和架構？太多了。
但這並不能減弱一個平臺想要擁有一種語言的強大驅動力。隨著平臺的發展，專注於一種受控制的語言會使其構建優秀工具（特別是符號偵錯程式）變得更加輕鬆。
這種思維方式促使平臺開發商希望擁有自己的語言，也使得從一個圖形使用者介面轉移到另一個更加困難。當然這（甚至早在當時）似乎有點愚蠢，因為只要你的互動程式碼是在一個平臺上編寫的，那它們在其他地方工作的可能性就幾乎為零。
儘管如此，在新的圖形介面大體相同的世界裡（有點像 5 年前的移動端），客戶的確在推動標準語言。這導致開發商“支援” C、Pascal、Basic，甚至 COBOL 來編寫他們的圖形使用者介面。但這麼說有點弄虛作假——其實不過是為這些語言提供標頭檔案/匯入，而不是真正的文件、樣例等，這些都留給了語言或編譯器開發商。
為了加強對 API 和語言的控制，平臺開發商一直在擴充套件其編譯器。他們會新增一些小東西來使他們的庫或API 更易於閱讀或能生成更好的程式碼。有時這些是通過合法的擴充套件機制完成的（比如在 C 中，你可以通過字首 __ 來組成關鍵字，如 __cdecl）。
我一直覺得這很奇怪，既然所有的 GUI 程式碼都無法移植，那麼語言是否“標準”根本無關緊要。如果你是客戶，這無關緊要；如果你是開發商，為什麼要把開發資源用在自己的特殊編譯器上，而不是其他真正緊要的改進上（例如程式碼生成或連結速度）。
說個趣事。我們因內部要求有過一些為 Win/C++ 新增 MFC 的大辯論，就是想自行擴充 C++。
我一直覺得擴充 C++ 的想法是瘋了，你看 ANSI 擴充的一直都是垃圾就沒停過！我始終堅持這個想法。
構建一個 C++ 庫來為 Windows 的編譯器新增擴充套件，我覺得這是瘋了，但壓力大啊：營銷團隊想要，作業系統組想要，NT 團隊確實需要擴充套件（以提高編譯速度！）也想要，連 CEO 都想要 :-) 我花了很多時間參加會議，試圖解釋我們面臨的現實，即 C++ 本身尚未標準化（ANSI XJ316 還沒完成）。
巧的是我們的主要競爭對手 Borland Object Windows Library (OWL) 新增了擴充套件，以便更容易地做 Windows WM_ 訊息處理。我覺得這太蹩腳了。我們的團隊（共三人）花了很多時間確保我們使用沒擴充套件的 C++ 的“訊息對映”沒有額外開銷。關於要不要擴充套件，我和我 Borland 公司的朋友們在USENET新聞組中進行了一場偉大的辯論戰。我們贏了。 :-)
從此以後，我們看到 Android，iOS 和 .net 以及其他平臺都有了自己的語言。哎。
這種控制、表現、試圖集中精力等等的思維方式導致了我們今天在每個平臺上都有自己語言。我只是認為這是平臺自然演變的一部分，而不是什麼陰謀論。歸根結底，只要平臺開發商是工具集的好管家，而不僅僅是兜售語言語義，這就沒有關係。
iOS 有 Objective-C，現在是 Swift；Android 有 Java，現在是 Kotlin；甚至 Azure 也有 .net 和 C#。當然，他們中的所有平臺都支援 C 語言，並且有大量的很多語言的例子。
當然，跨越了所有這些，從程式設計師數量、程式碼行數和程式碼消耗量來看，瀏覽器中的 HTML/JS 才是主要語言。它非常了不起。儘管我從事需要編譯的“專業語言”，但我對該執行時很感興趣，因為它非常易用，並且對於許多人來說都是“正確的”工具。隨著大量框架的出現，指令碼的定義得到延伸，我的信念也久經考驗（儘管很多人會說在呈現意圖的作用上 Office 與 HTML 加 CSS 非常相似）。這個另一篇文章再說 :-)
但是有個大的改變，那就是雲。不僅僅是程式碼的位置，程式型別也根本不同，並且需要其他語言。這些語言，如 Python 等等，得到很大發展。
雲和 API 隱去了程式語言，導致了新語言的復甦。部分原因是大多數人使用的工具開始復古：VI（或 emacs ?）和許多日誌/診斷工具（當然還有一些 A+ 平臺專用工具！）。
擁有平臺獨佔語言的主要驅動力之一是需要投資平臺的工具。工具非常依賴平臺，並且需要大量的工作。事實上，為平臺帶來成功的往往不是平臺或 API 的質量，而是工具。獲勝者不是最好的平臺，而是擁有最好工具的平臺。你可能咒罵 XCode 不如你意，但孩子，它在 8 年前誕生時與 Android 相比是相當不錯的。還有 Visual Studio，已經主宰了企業團隊的開發。
然而，雲帶來了新的場景，並且重要的是不被壟斷。服務和 API 來自各地。因此，今天在雲“語言”中存在巨大的多樣性，Stripe 或 Twilio 之類的服務並不少見，你可以檢視示例程式碼並以多種語言匯入。這都是鉅額資本有意推動的。
雖然您可以從 StackOverflow 中看到語言的用途多種多樣 (https://insights.stackoverflow.com/survey/2018/)，但這些平臺很可能會開始推動語言精減——這跟我們在客戶端看到的原因相同。
語言多樣性很好，但工具要有側重。雖然語言也有創新，但總的來說，是在以“靜態”能力換取表現能力。
這就是我們今天的情況，從 Python、PHP、Ruby、Typescrpt 到 Scalr 的出現，我們看到了語言的多樣。這看起來很棒，但實際上對開發人員或工程經理來說可能是頭痛的事情。許多使用多種語言的創業公司都在面對招聘、負載平衡、管理工具鏈等方面規模過大的挑戰。多樣性是把雙刃劍。
雲確實隱藏了語言，但云平臺也將越來越接近語言。
儘管如此，雲端計算確實隱藏了這些平臺差異。這似乎是積極的。我認為這是一個“時間點”。隨著雲開發商為求勝而“非理性”地往工具中增加投入，語言將強化並極化，受支援的語言會更少。
現在看來這很邪惡：因為大多數人都在平臺之上開發，平臺變得更加豐富而不僅僅是“基礎架構”，在某個雲提供商處寫的程式碼將更加交織在一起；工具、文件甚至樣例的改進將導致客戶對開發商和語言的投入越來越多。這是平臺開發商想要的，它雖然看起來很邪惡，但確實可以幫到客戶。
最終，擁有最佳工具的平臺很可能會勝出，特別是在工具更重要的大企業中（與新兵組成的小公司相比，他們擁有更多不同技能和背景的員工）。
// PS：Paul Graham 在程式語言方面的非常早期的文章閱讀起來非常有趣（令人震驚的是，和 Cornellian 一樣，他使用的是 Lisp！）paulgraham.com/avg.html
這篇文章是一個經典的文章，真正抓住了 80 年代語言辯論的時代精神。總結下！
// PPS：語言的兩個普遍教訓：
1/ 偉大的程式設計師不是“用”語言程式設計，而要“深入”語言程式設計 -> 任何語言都可以用，他們只需要適應風格。
2/ 構建產品不是構建語言測試套件。不要因為酷或新就要用上所有功能。
1/ 是在 Cornell CS 211 的第一天聽著名的 David Gries 教授說的，他是程式設計正確性領域的先驅，也是 PL/CS 專案的領導者之一。他這話對我影響深刻。這就是為什麼我有點誇張地講述在 1984 年夏天時的 C 語言。我想就是因為他曾教過我 PL/CS，我可以很容易地“深入”C。
2/ 是我從 1991 年 USENIX C++ 會議上的 Martin Carrol（當時的 AT&T）發表的談話中學到的，它對我有類似的影響。關於構建 MFC 的歷史說來話長（都可以開個 podcast 了），包括我們如何用諸如多重繼承、運算子過載、虛擬基礎等“物件導向”技巧來構建第一個版本。我們後來拋棄了這套，並宣稱自己團隊為“物件導向程式設計成癮康復中心”。
我所在支撐小組的一部分人去 USENIX 獲取了一些極客對 C++ 的看法。我是那裡最年輕的人，也是唯一的 Windows（和 OS/2）開發者。Martin 的發言幾乎上是打臉所有的 C++ 2.0 定義（模板、異常等）贊同派，我太喜歡了。回來後我們四人碰頭，決定了兩件事：
• 我們正在構建的是一個類庫，不是編譯器測試套件。因此沒有模板、異常、運算子過載、虛擬基類、引用等。我們只關注效能、可讀性、Windows 適配等。
• 我們只使用標準的 C++ 而不對語言做擴充套件。堅決不用仍在 ANSI 委員會討論的語言特徵（這至少要 5 年才會寫進棕皮書）。
這就是 MFC 的平臺架構的由來，是“物件導向程式設計成癮症”的結果。
這也是為什麼我非常喜歡 @monkeydom 的帖子。它讓我想起了我寫過的反對汙染 C++ 的論戰。每個人都對某種語言過於興奮，並忘記了我們真正要做的事情——讓 Windows 程式設計變得更容易。
—— Steven Sinofsky
如果發現譯文存在錯誤或其他需要改進的地方，歡迎到 掘金翻譯計劃 對譯文進行修改並 PR，也可獲得相應獎勵積分。文章開頭的 本文永久連結 即為本文在 GitHub 上的 MarkDown 連結。
掘金翻譯計劃 是一個翻譯優質網際網路技術文章的社群，文章來源為 掘金 上的英文分享文章。內容覆蓋 Android、iOS、前端、後端、區塊鏈、產品、設計、人工智慧等領域，想要檢視更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。