[譯] 編程語言和平臺：對一條推特思路的評論

• 原文地址：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（咱們在實驗室裏構建了一個解釋器做爲試驗牀），等等。若是你能察覺到什麼共性的話，那就是這些語言沒一個得到過商業上的成功。

由於語言如此重要，不少「梗」會被打印出來（在點陣打印的寬條形綠色條形紙上），掛在地下室的機房中。

真正的程序員不用 Pascal

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、前端、後端、區塊鏈、產品、設計、人工智能等領域，想要查看更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。