Delphi 25歲了！盡管它不再是很多 Windows 開發(fā)的明顯選擇，但它的“長壽”證明了其性能之高。回想起來，為什么 Delphi 當初未能占領(lǐng) Windows 開發(fā)市場的更多份額呢？本文細數(shù)以 Delphi 為首的編程語言以及軟件創(chuàng)作系統(tǒng)所經(jīng)歷的 25 年風雨，以此祭奠老 Delphi 程序員們已逝的青春。
作者 | Jon Lennart Aasenden
譯者 | 彎月，責編 | 郭芮
出品 | CSDN（ID：CSDNnews）
以下為譯文：
我想通過本文細數(shù)以Delphi為首的編程語言以及軟件創(chuàng)作系統(tǒng)所經(jīng)歷的25年風雨。我應該從哪里開始呢？史無前例的面向?qū)ο螅渴录?qū)動架構(gòu)？蓬勃發(fā)展的組件市場？還是從x86匯編語言擴展到高性能ARM移動應用程序的技術(shù)？
我不想簡單地列出各項技術(shù)，而是想以一種更加個人化的方式來撰寫這篇Delphi的文章。畢竟Delphi 25周歲了，人們喜歡在生日這天舉行演講和反思：回顧過往的一切，同時堅定地展望未來。
簡而言之，我只能通過本文傳達在我作為軟件開發(fā)人員的一生中Delphi給予我的寶貴價值，而且我相信數(shù)百萬的Delphi開發(fā)人員感同身受。
我希望通過這篇文章，將我的想法傳給現(xiàn)在剛開始學習Delphi的許多學生。希望為你們的學習提供一些有營養(yǎng)的見解，并希望你們能和我一樣深愛Delphi。
Delphi 的起源
1990年初，計算機市場與今天相比有著截然不同的格局。在斯堪的納維亞半島和北歐，Commodore和IBM等公司仍然占據(jù)著家用臺式機的市場。但是在短短的三年之內(nèi)，IBM的OS/2就被微軟的Windows淘汰了，而曾經(jīng)的巨頭Commodore也陷入了其不可避免的痛苦局面，這兩家都無法或不愿意適應當時興起的新業(yè)務(wù)模式。在同樣動蕩的1993年，微軟和IBM正式分道揚鑣，IBM轉(zhuǎn)向了大型機及其PPC芯片組體系結(jié)構(gòu)，后者在接下來的十年甚至更長的時間里一直是Macintosh計算機的核心。
我提到這些公司的原因是為了讓你了解當時市場的混亂狀況。對于像我這樣的年輕學生來說，根本不可能知道應該在哪種技術(shù)上投入精力。我的編碼生涯是從Commodore Amiga版本的Turbo Pascal開始的，該版本由英國公司Hi-Soft發(fā)布，稱為High-Speed Pascal。當時，我還是工程系的新生，在學校里，我們主要使用Turbo Pascal和DBase。可惜當時的PC機非常昂貴，我沒錢花4000美元購買PC，于是花了700美元買了一臺Commodore Amiga。我覺得，Pascal編譯器的價格約為，這對于一個努力維持生計的窮學生來說，可以省不少錢。
1994年的時候，我使用的編譯器不能用了，很明顯Commodore再也未能東山再起。值得慶幸的是，我忍無可忍，終于下血本買了第一臺帶有Turbo Pascal的PC機。我很高興買了這臺機器，因為第二年Delphi就發(fā)布了。
每當我提到Delphi曾經(jīng)以及將來對我的影響，我一點都沒有夸張。Delphi自問世以來，對整個軟件開發(fā)行業(yè)的影響是巨大的。Delphi以及在此之前的Turbo Pascal，開創(chuàng)了許多當今開發(fā)人員認為理所當然的技術(shù)，甚至包括快速應用程序開發(fā)（Rapid Application Development，即RAD）周期本身。在Delphi之前，人們的目光都聚焦在投資回報率（ROI）和上市時間（TTM）上，編程語言帶來的變化微乎其微。但是，當Delphi出現(xiàn)以后，時間和金錢的投入都非常清晰明確了，因為Delphi帶來了顛覆性的變革（對于其競爭對手來說）。
因此，在90年代初期技術(shù)的戰(zhàn)國時代，Delphi成為了最大的贏家。當之無愧。
飛躍發(fā)展
思想和觀念的進化概念一直讓我十分著迷。我經(jīng)常在文章中提到這個概念。
我們總是認為進化是一個緩慢、漸進和線性的過程。但是當涉及到想法，尤其是技術(shù)時，我的經(jīng)驗是，好的技術(shù)會以快速、出乎意料的飛躍向前發(fā)展。孵化時間可能會有所不同，但最終在某種力量的推動下就會飛速向前。
1995年，Delphi進入市場時遠遠領(lǐng)先于競爭對手，人們發(fā)現(xiàn)Delphi很難學。但事件驅(qū)動編程的概念已經(jīng)出現(xiàn)很長時間了（例如Visual Basic），因此Delphi并不是在真空中孵化的。雖然有一些C/C ++編譯器也發(fā)展出了Delphi帶進大眾視野的語言功能，但是它們都缺乏Delphi的簡單性和優(yōu)雅性。
在伴隨我長大的Commodore機器上，有很多軟件支持拖放式表單設(shè)計，而且在某種程度上編程也采用了類似的方法（盡管處于更原始的狀態(tài)）。但是，Delph的獨特之處在于，沒有公司將這些想法融合為一個連貫的整體。我從未見過VCL框架之類的東西，或能夠與你的代碼如此緊密地集成的IDE。
一款功能強大的編譯器將所有這些元素組合在一起，比其他的編譯器要早很多年。如今的C/C++編譯器（從Pascal開發(fā)人員的角度來看）絕對非常強大，但是視覺設(shè)計在很大程度上需要獨立完成（Borland C/C++具有類似OWL的框架，因此UI可以通過代碼完成） 。因此，在競爭產(chǎn)品中，例如Wacom（1984～2010）或Storm C++（1995～2016），你需要在一個程序中創(chuàng)建UI，然后將這些設(shè)計作為資源文件導入到C/C ++項目中，與如今的蘋果.nib文件沒有什么不同。只有完成這些，你才可以開始構(gòu)建程序。有的代碼可能只需5分鐘，而有的代碼中該過程很容易超過5個小時。即使是很小的UI改動，也需要花幾分鐘才能生成代碼和做鏈接。
Delphi強大的編譯器和智能鏈接器可以將這個過程減少到幾秒鐘。這是十多年來世界上最快的編譯器。它的速度如此之快，以至于大多數(shù)開發(fā)人員將編譯功能當作一種快速檢查繁瑣的語法的方式。這對于其他語言來說都是不可想象的。
面向?qū)ο?/strong>
毫無疑問，Delphi邁入了一個更高層的領(lǐng)域，即真正意義上的面向?qū)ο缶幊獭Ｔ谶@之前，Pascal對面向?qū)ο筮€有點三心二意。Turbo Pascal 5.5是一流的DOS工具包（市場上稱為“帶對象的Turbo Pascal”），但其實它的對象只不過是帶有程序的記錄類型。除非你精通C++，否則你必須使用Modula II或Smalltalk之類的語言，才能獲得Delphi提供的那種對象模型。但是，它們都缺乏Delphi擅長的RAD（快速應用程序開發(fā)）層。
整個80年代和90年代初期，在Delphi的推動下，所有播種和孵化的技術(shù)都飛躍發(fā)展成了系統(tǒng)，面向?qū)ο蟪闪苏Z言本身基本的特征，而不是作為附加功能使用。由于Delphi程序在完整的VMT（虛擬方法表）下運行，因此開發(fā)人員可以享受繼承、虛擬和抽象方法以及可靠的數(shù)據(jù)封裝——所有這些均來自于易學、易用和競爭激烈的語言。
錦上添花的是Delphi注重視覺編程。你可以將一個按鈕拽到窗體上，然后雙擊填寫事件處理程序，這個過程無需離開IDE或切換選項卡。之前已有其他編譯器做到了這一點，但Delphi是真正的本地編譯器，而不是通過字節(jié)碼或托管系統(tǒng)讓IDE按照自己的規(guī)則進行操作（以性能為代價）。Delphi是首個達到C/C ++級別的性能和深度（多虧了Object Pascal的易學和優(yōu)雅）的語言。你還可以與Pascal并排編寫機器代碼，所以說Delphi與Visual Basic或SmallTalk是完全不同的級別。一夜之間Visual Basic從英雄變成了無名小卒。
現(xiàn)代Delphi與C/C++并肩，但仍非常重視可視化OOP編程
關(guān)于這一點，Object Pascal擁有與C/C++并駕齊驅(qū)的深度和功能，這是因為Delphi的視覺和非視覺組件庫都是由Delphi制作的。換句話說，你沒有強制依賴第三方提供的組件（這是競爭解決方案的慣用方法）。任何人都可以坐下來編寫自己的組件；然后以可執(zhí)行文件或源代碼的形式打包出售。因此，組件市場蓬勃發(fā)展，導致競爭對手黯然失色。
我甚至想說，如果Delphi是在IBM OS/2上發(fā)布的，那么就可以拯救這個平臺。意義非凡。
大學最后一年，我們的課程使用了Visual Basic，但其實背后我們都在使用Delphi。實際上，我從未參加過任何微軟認證課程，而且只學習了一些基本知識就考出了好成績。那時，我已經(jīng)在用Delphi編寫COM組件，遠遠超出了課程范圍。
我至今仍記得有一天老師將課程放在一邊，單獨給我們講起了Delphi。他是一位充滿熱情的開發(fā)人員，將Delphi的包裝盒放在我們面前時，他幾乎無法抑制自己的激動心情。我們睜大了眼睛，張著嘴，津津有味地聽著有關(guān)這個奇妙的新系統(tǒng)的所有知識。充滿熱情的思想涌現(xiàn)出了很多新想法。那真是一個奇跡。
大學畢業(yè)后，我曾有機會從事教師的工作，但我拒絕了。除了Delphi之外，什么都不教的想法感覺像是倒退了一步。
Delphi教育
在結(jié)束了大學的學習后，頭幾年里我一直在擔任技術(shù)新聞記者，同時也在提高自己的開發(fā)技術(shù)。當再次回到大學學習時，Delphi已被列入了教學大綱。如今，年輕的開發(fā)人員常常在問為什么RAD Studio同時包含Delphi和C++ Builder，其實這種結(jié)合構(gòu)成了傳統(tǒng)軟件工程學位的骨干。這種趨勢一直持續(xù)到2002年，而且如今世界部分地區(qū)仍然如此。
這兩種語言并排發(fā)展，而且共同擁有一段1970年代的輝煌歷史。盡管許多開發(fā)人員錯誤地認為Object Pascal很老，C/ C++是現(xiàn)代編程語言，但實際上C與Pascal屬于同一個時代。就像Delphi并非憑空發(fā)展一樣，C也不是。而BrianKernigan和Dennis Richie的標準也是基于大型機行業(yè)已有（且經(jīng)常相互沖突）的工具。
因此，作為編程語言，Pascal和C以及進一步的Object Pascal和C++都是并排發(fā)展起來的，盡管它們之間的正式間隔是三年。
值得慶幸的是，Embarcadero繼續(xù)出色地完成了Delphi產(chǎn)品的最新功能。多年來，泛型、匿名方法、輔助類、屬性等功能已發(fā)展成為該語言的一部分。在這些工作的推動下，我們看到了Delphi的市場采用非常穩(wěn)定。無論是使用過其他語言的成熟開發(fā)人員，還是新手開發(fā)人員都能感受到Delphi的生產(chǎn)力和強大。
振奮人心的一件事是，Delphi和C++ Builder再次在教育領(lǐng)域大展手腳。在擔任Embarcadero的SC期間，我?guī)椭餐膬伤髮W建立了社區(qū)版。此外，在蘇格蘭、意大利、葡萄牙、南美和俄羅斯的一些機構(gòu)Delphi也在蓬勃發(fā)展。
挪威的老師都很激動，因為他們在Borland時代教過Delphi。就像一位教授款款而談：“就像問候多年的老朋友一樣。”
上個月Embarcadero宣布，土耳其將免費向其學生提供Delphi課程。估計有100萬學生參加，這真是個好消息！對于學生而言，最重要的還是領(lǐng)悟可靠、現(xiàn)代和原型編程語言的優(yōu)勢。這些能讓他們成長為更好的開發(fā)人員，就像我與數(shù)不盡的其他人一樣。
軟件工程原理
我不想離題太遠，只想簡單地說說原型編程語言。這是一個專屬領(lǐng)域，除了Delphi和C++ Builder之外，該領(lǐng)域只有一個其他的編程語言（盡管Rust絕對應該位列其中）。
原型語言是體現(xiàn)計算基本原理的一種語言。這些原則不受產(chǎn)品和市場變化等因素的影響，因為它們代表了計算機的基礎(chǔ)邏輯，有點像物理定律。在撰寫本文之際，只有匯編語言、C/C ++和Object Pascal才是原型語言。而且匯編語言是其他一切語言的基礎(chǔ)。
另一種語言稱為樂觀語言，這個名字源自數(shù)據(jù)庫技術(shù)的術(shù)語（例如，樂觀鎖定模型）。雖然我不打算在本文中討論為何一門語言被稱為樂觀，但總的來說，樂觀描述的是一種語言對于現(xiàn)有基礎(chǔ)結(jié)構(gòu)的依賴性的大小（因此被稱為樂觀，其意思就是認為存在某些特定條件是理所當然的）。匯編、C和Pascal是編寫操作系統(tǒng)或內(nèi)核的語言。從根本上講，它們對操作系統(tǒng)的依賴性不如Java或JavaScript那么強。
從低級編程到高級編程，再到高級面向?qū)ο螅珼elphi在廣泛的領(lǐng)域都有出色的表現(xiàn)
有好幾種操作系統(tǒng)都是用Pascal編寫的。最有名的系統(tǒng)莫過于蘋果經(jīng)典的Macintosh操作系統(tǒng)，該操作系統(tǒng)跨68k和PPC處理器。盡管毫無疑問，C/C++是這類工作的主要語言，但事實上，蘋果一直將Pascal作為核心語言，直到1996年史蒂夫·喬布斯回歸（喬布斯從NeXT帶來了Objective-C和Unix），這足以證明Pascal的強大和多功能性。自那時以來，Pascal的多功能性得到了極大的擴展。
我還想說說Ultibo，它是當今物聯(lián)網(wǎng)設(shè)備上非常流行的嵌入式系統(tǒng)。該系統(tǒng)包含一個完全用Object Pascal編寫的內(nèi)核，以及構(gòu)建現(xiàn)代嵌入式系統(tǒng)所需的所有基本組件。從USB堆棧到網(wǎng)絡(luò)的所有功能全是用Object Pascal編寫的。
雖然該系統(tǒng)使用的是受Delphi啟發(fā)的開源編譯器（FreePascal，過去曾被Delphi作為早期的移動支持），但是Ultibo的許多代碼都源自Delphi社區(qū)。
坦白來講，對于樂觀一族的語言來說，這種工作是不可能的，或者至少是非常不切實際的。你需要一個能夠覆蓋從匯編語言到高級構(gòu)造的所有東西，才能真正在這個級別上開展工作。你不能用JavaScript編寫內(nèi)核，因為它具有大量的依賴關(guān)系。
經(jīng)過25年的發(fā)展，Delphi像以往一樣強大且通用。關(guān)于Delphi的討論有很多層次，本文到目前為止，我們只說到了一些皮毛。
感言
在生日祝酒之前，我要先講幾句。
Delphi就像我們的家庭成員一樣，這么多年來，我把Delphi當成了血肉至親，所以過去我曾無數(shù)次表示贊賞Delphi，而且我希望告訴別人Delphi仍然很重要的一些原因，也許如今Delphi比過去更重要。
如果想細數(shù)Delphi擁有和能夠做到的一切，那么我可以滔滔不絕地說個沒完沒了。它的功能千千萬，能夠勝任的任務(wù)跨度非常大。Delphi帶來的創(chuàng)新源泉永不枯竭，我無法僅在一篇文章中盡數(shù)講清楚。
Delphi和C++ Builder涵蓋的技術(shù)領(lǐng)域非常廣泛，能夠從各種環(huán)境中輕松訪問文檔至關(guān)重要
在過去的15年中，我全身心投入到了Object Pascal和Delphi。我寫過博客，寫過論文，在學校教過Pascal，并盡我所能讓每一個人都了解Pascal。我甚至編寫了自己的開發(fā)環(huán)境，以方便Object Pascal能夠適應Node.js和HTML5等新平臺，而且全部都是用Delphi編寫的。
多年來，軟件開發(fā)界已經(jīng)接受了大量的折衷方案，現(xiàn)在整個行業(yè)的質(zhì)量和可靠性損失已顯而易見。這也是學術(shù)界渴望扭轉(zhuǎn)這一趨勢，并讓Delphi重返高等教育的原因。
我可以直言不諱：這個世界不需要JavaScript開發(fā)人員。我們不需要其他C#程序員。從整體看來，軟件開發(fā)需要的是更多的Delphi和C/C ++開發(fā)人員，因為質(zhì)量的需求已經(jīng)證實了我上面提到的那些基本原理。
那些曾受過Delphi和C++ Builder等經(jīng)典軟件工程教育的開發(fā)人員，如今可以開發(fā)定義規(guī)范的產(chǎn)品和公司。能夠撼動整個IT行業(yè)的人并非畢業(yè)于Java，他們是Java的締造者。真正核心的一切都是用原型語言締造的。這是一個無可爭議的事實。如果Linus Torvalds抱著Java不放，那么這個世界上就沒有Linux了。忠言逆耳，這些話可能很刺耳，但都是大實話。
我們生活在一個很難用一種編程語言謀生的世界里。我并不是說你只需要選擇一種編程語言。每種語言都有各自的用途，每個開發(fā)人員都應該從多方面充實自己。但是我必須強調(diào)以原型語言為基礎(chǔ)的重要性。
這與我個人的喜好無關(guān)，我也不是狂熱分子。我只是根據(jù)35年的開發(fā)經(jīng)驗總結(jié)出來的。我覺得至少我有這方面的積累，可以公開談?wù)撨@個話題。
如果你想成為一名普通的程序員，那么可以專門研究普通的編程語言。然而，如果你想成為杰出的開發(fā)人員，那么必須學習一種原型語言，而且在我個人看來，Delphi是最有效的。
如果你了解Delphi或C++ Builder，那么學習其他任何語言都易如反掌。因為在你學習Delphi時，就熟練掌握了那些基本原理。就沖著一點，你就比其他人都高一級。
Delphi的優(yōu)點在于，你可以從各個級別使用它。沒有人期望你編寫內(nèi)聯(lián)匯編程序，或從頭開始創(chuàng)建數(shù)據(jù)庫引擎。自Turbo Pascal以來，Delphi的覆蓋范圍已非常廣泛，且已經(jīng)過了時間的考驗，已發(fā)展成熟和完善。
因此，你可以按照自己的情況發(fā)展和學習語言。只要你充滿好奇心，且愿意挑戰(zhàn)自己，那么Delphi絕對值得一試。
此外，與其他語言不同，無論將來你投身何處，深入Delphi所獲得的知識和見解都會終身受益。Delphi？它是哲學，它是邏輯，它是藝術(shù)；它教你思考和提煉出解決方案，而其他人只能看到重重障礙。
本文的核心思想總結(jié)起來就一句話：
軟件工程學位不是目的地，而是聰明人一生的起點。
親愛的Delphi，我的老朋友，祝你生日快樂！
原文：https://community.idera.com/developer-tools/b/blog/posts/25-years-of-excellence
本文為 CSDN 翻譯，轉(zhuǎn)載請注明來源出處。
【CSDN 編者按】IDE 經(jīng)過 30 年的發(fā)展，種類越來越繁多。放眼國際，主流的 IDE 有 Intellij IDEA、Eclipse、PyCharm、Visual Studio Code 等等；近幾年國產(chǎn) IDE 也相繼崛起，如 deepin-IDE、CodeArts IDE 等。
面對不斷涌現(xiàn)的 IDE，有軟件開發(fā)者 Julio Merino 指出，30 年前我們所擁有的 IDE 雖然沒有圖形界面，但是卻帶來了許多令人印象非常深刻的功能，如今 隨著時光的流逝，很多功能失去了，而且如今的 IDE 并沒有太大的進步，唯一的區(qū)別可能只是添加了 AI 輔助代碼功能。
此觀點一出，也引發(fā)了巨大的討論。接下來，我們將走入 Julio Merino 這篇文章，深入探討我們過去擁有的文本編輯器以及與當今主流編輯器的最新比較，也旨在推動 IDE 更好的未來。
原文地址：https://blogsystem5.substack.com/p/the-ides-we-had-30-years-ago-and
本文為 CSDN 翻譯，未經(jīng)允許禁止轉(zhuǎn)載。
以下為譯文：
我是在 20 世紀 80 年代末 90 年代初學習編程長大的。那時，我并沒有完全理解我在做什么，以及為什么我使用的工具在當時硬件存在限制的條件下，表現(xiàn)得令人印象深刻。隨著年齡的增長，現(xiàn)在通過使用 DOSBox 重新體驗那些程序并將它們與我們當前的狀態(tài)進行比較真的很有趣。
這一次，我想看看在 Windows 主導個人電腦行業(yè)之前那個時代我們所擁有的純文本 IDE。我想這樣做是因為那些 IDE 幾乎毫不遜色于今天的 IDE。然而，感覺好像我們經(jīng)歷了一個黑暗時代，在那段時間內(nèi)我們失去了大部分功能，而時代似乎是個輪回，這些功能現(xiàn)在才重新浮出水面。
接下來，我們將領(lǐng)略一次懷舊之旅，同時對“臃腫的 IDE”發(fā)表一點看法。但更重要的是，繼續(xù)了解以前存在的東西，才能更好地評估未來功能的推出。
第一款編輯器和 TUI 界面
在 20 世紀 90 年代，幾乎每個運行的 DOS 程序都有一個全屏的文本用戶界面（TUI），它具有基于文本的窗口、下拉陰影、顏色和鼠標支持。以下是一個示例：
MS-DOS 編輯器（也稱為 EDIT.COM）展示了其中一個設(shè)置對話框。請注意菜單欄、帶有列表選擇器和按鈕的豐富對話框，以及記錄了導航快捷方式的狀態(tài)欄。
每個程序都是獨立的，因為它們的界面是獨特的。然而，它們在外觀上如此相似（80x25 個字符沒有太多的差異），以及它們的工作方式如此相似，以至于這些差異實際上并不妨礙可用性和可發(fā)現(xiàn)性。一旦你學會了 Alt 鍵打開菜單，Tab 鍵在輸入字段和按鈕之間切換，你幾乎可以輕松地瀏覽任何程序。
但是我們來談?wù)劸庉嬈鳌S-DOS 從第 5 版（1991年）開始附帶了一個 TUI 文本編輯器，如上圖所示。這個編輯器“能用”，但對于編碼來說確實很不方便：你需要退出編輯器來編譯和運行你的代碼，當你重新運行編輯器時，你需要導航回到之前的位置。
在“我家”中，我們使用了一個叫做 SideKick Plus（1984年）的東西，它不是一個真正的代碼編輯器：它更像是一個帶有內(nèi)置記事本的個人信息管理（PIM）系統(tǒng)。然而，它的酷炫之處在于它是一個常駐程序（TSR），這意味著它在后臺加載，并且你可以隨時通過按下 Ctrl+Alt 鍵來調(diào)出它。
按下Ctrl+Alt鍵后，SideKick Plus的主屏幕出現(xiàn)。請注意DOS仍然在后臺運行。
將這個 TSR 功能視為一種基本的多任務(wù)處理方式，適用于沒有多任務(wù)處理的操作系統(tǒng)。這非常有效，因為在高效的內(nèi)部開發(fā)循環(huán)中，快速切換代碼編輯和構(gòu)建是至關(guān)重要的。
然而，到這個時候，真正的 IDE 已經(jīng)存在了幾年。Turbo Pascal 1.0（1983年）展示了一種集成體驗的開始，盡管它還沒有其標志性的 TUI 界面。QuickBASIC 2.0（1986年）展示了更多“傳統(tǒng)”的TUI界面（與EDIT.COM相同，因為它們是同一個編輯器），而 MS-DOS 5 附帶了 QBasic，這是QuickBASIC 的簡化版本，它不允許編譯為本機代碼，但外觀相同。
Borland 公司開發(fā)的 Turbo 系列
在我看來，IDE 的巔峰之作是后來的 Borland Turbo 系列，其中包括 Turbo C++（1990年）、Turbo Assembler 和 Turbo Pascal。這些 IDE 是特定于語言的，但它們擁有全屏的 TUI 界面，并且功能非常強大。
讓我們來看看當時擁有的功能。語法高亮：
Borland Turbo C++ 顯示一個用于演示語法高亮的“Hello World”程序。
編譯器集成和診斷：
Borland Turbo C++編譯一個程序后顯示一個警告，因為我沒有從main()函數(shù)返回值。
集成的項目和構(gòu)建系統(tǒng)管理：
Borland Turbo C++顯示其項目管理和多窗口功能。在圖片中，你可以看到兩個C++源文件，其中一個依賴于另一個，并且項目窗口列出了所有需要一起編譯的文件。
帶有斷點、堆棧跟蹤等功能的調(diào)試器：
Borland Turbo C++ 顯示一個包含多個函數(shù)、斷點和當前調(diào)用堆棧的調(diào)試會話。
甚至還有完整的參考手冊：
Borland Turbo C++顯示其集成的幫助系統(tǒng)，背景中是“Hello World”程序，而幫助中是printf函數(shù)的說明。
請記住：這些都是在 20 世紀 90 年代早期，距今已經(jīng)過去了 30 多年。
我是 Turbo C++ 的忠實用戶，通過它我學到了很多東西。我記得使用它們的 conio.h 庫來實現(xiàn)自己的 TUI，并使用它們內(nèi)置的 graphics.h 庫來嘗試實現(xiàn) GUI。請注意：這是在沒有互聯(lián)網(wǎng)的情況下完成的。對于很多人來說，沒有“查找事物如何工作”的選項，也不能在 Stack Overflow 上找到答案：IDE 必須是即時可發(fā)現(xiàn)的（而且它確實是這樣的），并且是自包含的，為你提供完整的開發(fā)體驗。
那時候的 Linux 怎么樣？
那么回顧一下 20 世紀 90 年代初的 Linux 情景。
在 Linux 中，幾乎每個程序都是基于文本的，但這些程序并沒有提供全屏的 TUI（文本用戶界面）。這不符合“Unix的方式”。我記得當時看到 X11 配置工具（XF86Setup）或 OpenBSD 安裝程序時，對它們的簡單性感到震驚：連我這個幾乎沒有什么“真實”編程經(jīng)驗的年輕少年都已經(jīng)寫出了好看的程序。
無論如何，這并沒有阻止我追求不使用 Windows 的目標。我繼續(xù)學習 Linux 的知識，并很快經(jīng)歷了每本書和在線社區(qū)都在推薦的“最佳”編輯器：Vim 和 Emacs。但我無法理解它們?yōu)槭裁词艿饺绱烁叩臍g迎。使用它們就像回到了過去。它們確實是全屏程序，但看起來相當晦澀。Vim 確實支持語法高亮，但遠遠稱不上是一個 IDE。Emacs 可以配置與一些代碼輔助功能等集成，但也遠遠稱不上是類似“開箱即用”的 Turbo 系列 IDE。
看看今天的默認 Emacs 配置，它自那時以來幾乎沒有改變。它確實有窗口，但它們沒有裝飾。它沒有顏色（現(xiàn)在依然幾乎沒有）；過去不支持鼠標。雖然它確實有一個菜單欄，但這只是一個噱頭？如果按照說明按下 M-` 鍵，你會面對一個真正奇怪的界面來導航菜單，這讓人懷疑為什么他們甚至要浪費一整行屏幕空間來顯示一個毫無作用的菜單欄。
現(xiàn)在試著把這些交給一個沒有編程經(jīng)驗的人，讓他們來創(chuàng)建、編譯和調(diào)試一個程序。他們在瀏覽編輯器時會遇到麻煩，也找不到任何能夠進行項目管理或編譯器集成的功能。
相比之下，在撰寫這篇文章時，我在 DOSBox 中啟動了 Turbo C++，只需要幾分鐘就能夠創(chuàng)建一個“Hello World”的項目并且在環(huán)境中進行導航，而且一切都是直觀的。作為一個 IDE，它提供了全面的集成。
當代 TUI IDE
無論如何。讓我們忘掉過去，看看 TUI 領(lǐng)域的今天。我不想看 GUI，因為......Visual Basic 曾是圖形編程的巔峰之作，而我們現(xiàn)在也沒有了，這也是后話了。
與 Borland Turbo C++ 環(huán)境最接近的現(xiàn)代版本是 RHIDE（https://directory.fsf.org/wiki/RHIDE）。如下圖所示，它看起來非常相似——如果你以為這是 Turbo C++，那就大錯特錯了。遺憾的是，它只能在 DOS 環(huán)境下運行，而且現(xiàn)在似乎已基本廢棄，其最新版本發(fā)布于 7 年前。
RHIDE IDE 顯示的 "hello world "程序與之前的一樣，編譯后既無錯誤也無警告。
然后就有了 Free Pascal。這是最接近舊版本的體驗，但采用了現(xiàn)代代碼庫，可在 Unix 系統(tǒng)上本地運行，并可利用任何大小的終端。
Free Pascal IDE 包含一個簡單的“hello world”程序，以及用于內(nèi)置 ASCII 表格和計算器的重疊窗口
最后是 QB64。它與 Microsoft QuickBasic 非常相似，但......別被它騙了：盡管它看起來像一個 TUI，但它實際上是一個模擬 TUI 的 GUI 應用程序。你不能在終端運行 QB64。
QB64 IDE 看起來像文本，但實際上是圖形程序。
Free Pascal 和 QB64 都在維護和相對活躍的開發(fā)中，它們的最新版本發(fā)布于 2021 年......但它們大多被忽視了，因為它們使用的是現(xiàn)在大多數(shù)人都不感興趣的晦澀語言。
“真正的”現(xiàn)代控制臺 IDE
那么對于現(xiàn)代編程語言而言，我們還剩下什么選擇呢？
目前最先進的選擇似乎是 Neovim（https://neovim.io/）、Doom Emacs（https://github.com/doomemacs/doomemacs），甚至是 Helix（https://helix-editor.com/）。這些編輯器非常強大，并且通過各種插件提供了類似于 IDE 的體驗。
不過，如果你問我，我覺得這些編輯器都沒有像之前的 Borland 產(chǎn)品那樣提供相同的體驗：它們的界面很復雜，并且由于支持多種語言，對于幾乎所有語言都能工作得不錯，但是對于特定語言來說并不出色。可以說是“萬能但不精”。
無論如何，根據(jù)我在 microsoft/terminal#16440（https://github.com/microsoft/terminal/discussions/16440）討論中觀察到的情況來看，首選的“簡單”TUI（文本用戶界面）編輯器似乎是 GNU Nano......但其實首先它不是 IDE；其次對我來說，它看起來像 WordStar。Nano 的外觀讓我想起了我在 CP/M 時代使用文字處理器的第一次經(jīng)歷。看看這個：
GNU Nano 編輯器的默認設(shè)置，打開一個空文件。
所以，盡管現(xiàn)在我們有很多功能強大的控制臺編輯器，但它們并沒有提供與 30 年前完全相同的可用體驗。事實上，感覺在這 30 年間，我們在很多方面出現(xiàn)了倒退，直到現(xiàn)在才達到了一些曾經(jīng)擁有的功能水平。
當圖形化操作系統(tǒng)開始流行起來時，TUI（文本用戶界面）自然而然地變得不那么受歡迎，而它們最近才重新流行起來確實有些有趣。至于為什么會有這種趨勢，我認為我們應該歸功于 LSP（Language Server Protocol）的發(fā)明對這個領(lǐng)域的最新進展。
多年來，TUI 編輯器一直“擱置”不前，因為為它們構(gòu)建 IDE 功能需要很大的努力，而且它們的小型維護人員團隊無法承擔實現(xiàn)這些功能的成本。LSP 為現(xiàn)有的語言特定集成提供了接入方式，并重新激發(fā)了對古老而可靠的 Vim 和 Emacs 的興趣。希望即將發(fā)布的 BSP（Build Server Protocol）能夠更進一步，使這些 TUI 編輯器更像 IDE。
為什么要使用 TUI IDE（基于文本用戶界面）？
有人會問：“誰在乎呢？現(xiàn)在每臺臺式機和筆記本電腦都運行圖形操作系統(tǒng)了！”
這個問題問得好。
一般來說，你可能不需要 TUI IDE。如果 VSCode 是你的首選，那么它的遠程處理能力是一流的，而且 VSCode 擁有一個相當不錯的圖形界面，而不是一個完整的集成開發(fā)環(huán)境。但是，VSCode 也有一些不足之處。
首先，TUI IDE 非常適合在遠程計算機上工作，甚至比 VSCode 更好。你可以通過 SSH 輕松進入任何機器并啟動 IDE。將其與 tmux（終端復用器類自由軟件，功能類似 GNU Screen）相結(jié)合，就能獲得“完整”的多任務(wù)處理。當然，你也可以使用遠程桌面客戶端來代替 SSH，但我總覺得遠程桌面客戶端很笨拙，因為會出現(xiàn)延遲，而且與本地桌面快捷方式的整合也不恰當。
其次，VSCode 的遠程擴展不是開源的，這并不是什么大問題......只是它們無法在 FreeBSD 等操作系統(tǒng)上運行，而且也無法修復。因此，我無法使用 VSCode 遠程登錄我的主開發(fā)服務(wù)器。
第三個問題是......減少資源消耗。
無處不臃腫的 IDE
最后，我還想吐槽一下“IDE 的臃腫”問題。Borland 公司在 1990 年發(fā)布的 Turbo C++ 編譯器，配備了所有應有的功能（UI、C++ 工具鏈、集成手冊...），安裝后大小不到 9 MB，在 640KB 的 RAM 內(nèi)運行。
相比之下，Helix 文本編輯器在磁盤占用的空間也只有 16 MB，但 Doom Emacs 占用大約 500 MB，并消耗 RAM 的許多空間。然而，請注意，過往這些工具都不包含語言工具鏈或幫助系統(tǒng)，而現(xiàn)代工具鏈在磁盤空間都是以 GB 為單位。
要獲得“真正的”IDE，我們必須轉(zhuǎn)向使用 IntelliJ、VSCode 這類的圖形程序。不過，VSCode 占用磁盤空間約為 350 MB（令人驚訝地比 Doom Emacs 少），但它可能會吃掉你的電腦（占用內(nèi)存）：畢竟它是基于 Electron 開發(fā)的。我注意到通過放棄 VSCode 并轉(zhuǎn)向 Doom Emacs，可以顯著節(jié)省筆記本電腦的電池壽命。
因此，我想要留下的問題是：在 30 年內(nèi)，IDE 進步了多少？現(xiàn)代 IDE 擁有一些更好的重構(gòu)工具、更好的功能并支持更多的語言，但從根本上來說...它們并沒有太大變化。
對比 30 年前和 30 年后的 IDE，唯一主要區(qū)別可能是 AI 輔助編碼，但這是一項主要由遠程服務(wù)提供的功能，甚至不是由安裝的代碼提供的！