一百年后，人類將如何編程？轉：一百年后，人類如何編程？ 2011 年 3 月 30 日 13:37:35 一百年后的人類生活很難預測，只有少數事情是確定的。到時候汽車就有了低空飛行的能力，城市規劃規定會放寬，樓房可以建上百層，大街上整天都看不到太陽，所有的女人都學會了自我-防御。本文只想討論一個細節：一百年后，人們將使用什么語言來開發軟件？為什么這個問題值得思考？原因不是我們最終會使用這些語言，而是幸運的話，從現在開始我們將能夠使用這些語言。我認為編程語言就像生物物種。有一個進化背景。許多分支最終將成為進化的死胡同。這種現象已經發生了。該語言流行了一段時間，但似乎沒有后續語言繼承其思想。就像尼安德特人一樣，進化之路走到了盡頭。我預測 Java 也會這樣做。有人寫道：“你怎么能說Java不會成功？它已經成功了。”我認為這取決于您的成功標準。如果標準是相關書籍的出版數量，或者認為學習Java可以找到工作的大學生數量，那么Java確實成功了。當我說Java不會成功時，我的意思是它和那個一樣，進化之路已經走到了盡頭。

這只是我的猜測，可能不正確。這里的重點不是看Java，而是建議編程語言有一個進化的上下文，從而引導讀者思考某種語言在整個進化過程中的位置在哪里？提出這個問題，不是為了讓后人感嘆我們一百年這么聰明，而是為了找到進化的脊梁。它會激勵我們選擇接近主干的語言，這對當前的編程是最有利的。在任何時候，選擇進化的主干都可能是最好的解決方案。如果您不幸選擇了錯誤的人并成為尼安德特人，那就太糟糕了。你的對手克魯馬努會不時攻擊你并偷走你所有的食物。這就是為什么我想在一百年后找出編程語言。我不想下錯賭注。編程語言的進化與生物的進化還是有區別的，因為不同分支的語言會趨同。例如，該分支似乎與 的繼任者會合。理論上，不同的生物物種也可能會匯合，但可能性非常低，所以很可能從來沒有真正發生過。編程語言可能有聚合的一個原因是它的概率空間比較小，另一個原因是它的變異不是隨機的。語言設計者總是有意識地借鑒其他語言的設計思想。對于語言設計者來說，識別編程語言的進化路徑特別有用，因為這樣他們就可以相應地設計語言。這時，認清進化的主心骨，不僅有助于識別現有的優秀語言，還可以作為設計語言的指南。

任何編程語言都可以分為兩大組成部分：一組基本操作符（起到公理的作用）和除操作符以外的其他部分（原則上這部分可以用基本操作符表示）。我認為基本運算符是語言長期存在的最重要因素。其他因素不是決定性的。這有點像買房子首先要考慮地段。其他地方的問題以后會有辦法彌補，但地理位置不能改變。仔細選擇公理是不夠的，但要控制其規模。數學家總是認為公理越少越好，我認為他們已經達到了這一點。您仔細檢查語言的核心并考慮可以丟棄哪些部分。這至少是一個非常有用的培訓。在我漫長的職業生涯中，我發現冗余的代碼會導致更多的冗余代碼。不僅是軟件，像我這種懶惰性格的人，我發現這個命題在床底下和房間角落里也是有效的。一塊垃圾會產生更多的垃圾。我的判斷是，只有那些內核最小、最干凈的編程語言才會存在于進化的主干上。語言的核心設計得越小越干凈，它的生命力就越頑強。當然，猜測人們一百年后會使用什么編程語言本身就是一個很大的假設。也許一百年后，人類將不再編程，或者不再告訴計算機他們想要做什么，而計算機將自動執行。然而，到目前為止，計算機智能并沒有取得太大進展。

我想一百年后，人們仍然會使用相同的程序來控制計算機。今天可能有一些問題需要我們編程來解決，那個時候也不需要編程，但是我想會有很多和今天一樣的編程任務。您可能認為只有自以為是的人才能預測一百年后的技術。但是，請不要忘記，軟件開發的歷史已經走過了 50 年。在過去的 50 年里，編程語言的進化非常緩慢，所以期待一百年后的語言并不是一個徒勞的想法。編程語言進化緩慢的原因在于它們不是真正的技術。語言只是一種書寫方式，而程序則是一種嚴格遵守規則的描述，以書面形式記錄計算機應該如何解決您的問題。因此，編程語言的進化速度更像是數學符號的進化速度，而不是現實技術（例如交通或通信技術）的進化速度。數學符號的演變是緩慢的漸進變化，而不是真正技術的跨越式發展。不管一百年后計算機會是什么樣子，我們基本上可以得出結論，它們會運行得更快。如果摩爾定律仍然成立，一百年后，計算機的速度將是現在 18 倍的 74 倍 10 倍（準確地說是 73 786 976 294 838 206 464 倍）。很難想象。但實際上，更現實的預測并不是速度會提升這么多，而是摩爾定律最終不會成立。

不管是什么，如果每18個月翻一番，最后很可能會達到極限。但毫無疑問，當時的計算機比現在快得多。即使最終只快了 100 萬倍，它也會從根本上改變編程的基本規則。如果其他條件不變，現在被認為慢（也就是效率不高）的語言，未來會有更大的發展空間。屆時，仍然會有一些應用程序需要高運行速度。我們希望計算機解決的一些問題實際上是計算機本身造成的。例如，計算機處理視頻的速度取決于生成這些視頻的另一臺計算機。此外，還有一些問題需要無限快的處理能力，比如圖像渲染、加解密、模擬運算等。由于現實中有些應用程序本身效率較低，而其他應用程序會耗盡硬件提供的所有計算能力，那么擁有更快的計算機意味著編程語言必須處理更極端的情況，涵蓋更廣泛的效率要求。我們已經看到這種情況發生。如果按照幾十年前的標準來衡量，一些用新語言開發的流行應用程序會非常驚人地浪費硬件資源。編程語言不光有這種現象，其實是大勢所趨。隨著科技的發展，每一代人都在做上一代人覺得浪費的事情。 30 年前的人們看到我們今天這么隨意地打長途電話會感到震驚。

100年前的人，如果看到一個普通的包裹，還可以享受從波士頓寄出，經過孟菲斯，一天到達紐約的待遇，會更加震驚。我已經預測到，一旦硬件的性能在未來得到極大的提升，將會發生什么。新增加的計算能力將被破壞。當我學習編程時，計算機仍然很少見。記得當時用的電腦型號是TRS-80，內存只有4K。為了將程序加載到內存中，我不得不刪除源代碼中的所有空格。一想到那些效率極低的軟件，重復一些愚蠢的計算，消耗硬件的全部計算能力，就覺得難以忍受。然而，我的反應是錯誤的。我就像一個出身貧寒的窮孩子。我不愿意聽到我要花錢。即使我把錢用在重要場合（比如去醫院），我也很難接受。某些廢物確實令人作嘔。例如，有些人討厭 SUV（運動型多功能車）。即使他們使用可再生清潔能源，他們也無法改變他們的看法，因為SUV來自一個令人作嘔的想法（如何讓小卡車看起來更有男子氣概）。然而，并不是所有的浪費都是壞的。如今電信基礎設施如此發達，隨著時間的推移撥打長途電話有點問題。如果你有足夠的資源，你可以把長途電話和本地電話當作一回事，一切都會變得更容易。

廢物可分為好廢物和壞廢物。我感興趣的是好的浪費，這意味著用更多的錢來獲得更簡單的設計。那么，問題就變成了我們如何才能充分利用新硬件更強大的性能并最??有利地“浪費”它們？對速度的追求是人類內心深處根深蒂固的渴望。當您將計算機視為小工具時，您會不禁希望程序盡可能快地運行。抑制這種欲望需要付出很大的努力。在設計編程語言時，我們應該有意識地問自己，什么時候可以放棄一些性能來換取一點便利。許多數據結構存在的原因與計算機的速度有關。例如，今天的許多語言都有字符串和列表。從語義的角度來看，字符串或多或少可以理解為列表的一個子集，其中每個元素都是一個字符。那么，為什么我們需要將字符串作為數據類型分開呢？完全沒有必要這樣做。只是為了提高效率，所以字符串才會存在。但是，這種旨在加快運算速度，卻讓編程語言的語義變得非常復雜的行為，是非常不可取的。編程語言設置字符串似乎是過早優化的一個例子。如果我們將一門語言的核心設想為基本公理的集合，那么在核心中添加額外的公理只是為了提高效率，并不會帶來表達能力的提升。這絕對是一件壞事。是的，效率很重要，但我認為修改語言設計并不是提高效率的正確方式。

正確的做法應該是將語言的語義與語言的實現分開。從語義上講，不需要列表和字符串同時存在，僅列表就足夠了。在實現中，編譯器進行了優化，使其在必要時將字符串視為連續字節。對于大多數程序來說，速度并不是最關鍵的因素，所以你通常不需要擔心這種硬件層面的微觀管理。隨著計算機的速度越來越快，這一點變得越來越明顯。在設計語言時，對實現的限制更少，也會使程序更加靈活。語言規范的變化不僅是不可避免的，而且也是合理的。通過編譯器的處理，按照以前的規范開發的軟件將照常運行，提供了靈活性。 （論文）這個詞來自法語動詞，意思是“試一試”。在這個原始意義上，一篇文章是你寫一篇文章并試圖找出一些東西。軟件也是如此。我認為一些最好的軟件就像論文一樣，這意味著當作者真正開始編寫這些軟件時，他們不知道最終會產生什么結果。 Lisp 語言黑客早就明白數據結構靈活性的價值。當我們編寫程序的第一個版本時，我們經常以列表的形式處理所有內容。因此，這些初始版本的效率可能出奇地低。您必須克制以抵制優化它們。這就像吃牛排，所以你必須保持克制，以免去想牛排是從哪里來的，至少對我來說是這樣。是這樣的。

一百年后程序員最需要的編程語言是允許您毫不費力地編寫程序的第一個版本的編程語言，即使以這種方式效率低得驚人（至少從我們今天的角度來看）。他們會說他們想要的是一種易于學習的編程語言。低效的軟件并不意味著糟糕的軟件。一種讓程序員無用的語言真的很糟糕。浪費程序員時間而不是浪費機器時間才是真正的低效率。隨著計算機越來越快，這將變得越來越明顯。我認為放棄字符串類型是一個可以接受的想法。 Arc 語言已經做到了這一點，而且似乎運行良好。一些過去難以用正則表達式描述的操作，現在可以用回歸函數非常簡單地表達。這種數據結構扁平化的趨勢將如何發展？我非常努力地想象所有的可能性，結果連我自己都感到震驚。例如，數組會消失嗎？畢竟數組只是哈希表的一個子集，其特點是數組的鍵都是整數向量。此外，哈希表本身會被列表替換嗎？還有比這更驚人的預測。從邏輯上講，實際上沒有必要為整數設置單獨的表示，因為它們也可以看作是列表，整數n可以用n個元素的列表來表示。這樣也可以完成數學運算，但是效率無法承受。編程語言的發展會不會拋棄整數這一基本數據類型？我并不是要你認真思考這個問題，而是要開闊你對未來的思考。

我只是提出一個假設的情況：如果一股不可抗拒的力量遇到一個不動的物體，會發生什么。專門針對本文：當一種難以想象的低效語言遇到一種難以想象的強大硬件時會發生什么。我認為放棄整數類型沒有任何問題。未來相當長。如果我們想減少語言核心中基本公理的數量，我們不妨看得更遠一些，想想如果時間變量 t 趨于無窮大會發生什么。一百年是一個很好的參考指標。如果你覺得一個想法在一百年后可能仍然不能被接受，那么它可能在一千年后仍然不能被接受。讓我說清楚，我并不是說所有整數運算都使用列表來實現編程語言的發展，而是語言的核心（不涉及任何編譯器實現）可以這樣定義。實際上，任何執行數學運算的程序都可能以二進制形式表示數字，但這是編譯器的優化，而不是語言內核語義的一部分。另一種消耗硬件性能的方法是在應用軟件和硬件之間設置許多軟件層。這也是我們看到的一個趨勢，很多新興語言都被編譯成字節碼。比爾伍茲曾經對我說，根據經驗，每增加一層解釋，軟件的運行速度就會慢一個數量級。但是，額外的軟件層可以使編程變得靈活。 Arc 語言的初始版本就是一個極端的例子。它的層數很多，運行速度很慢，但確實帶來了相應的好處。

Arc 是典型的“”() 解釋器，是在 Lisp 的基礎上開發的，很像 John 在他的經典 Lisp 論文中定義的 eval 函數。 Arc解釋器只有幾百行代碼，所以很容易理解和修改。我們使用的 Lisp 版本是，它本身是在另一個字節碼解釋器的基礎上開發的。因此，我們總共有兩層解釋器。頂層的效率低得驚人，但語言本身是可用的。我承認它幾乎不可用，但它確實有效。即使對于應用程序，使用多層開發也是一種非常強大的技術。自底向上的編程方式是將軟件分成若干層，每一層都可以作為其上一層的開發語言。這種方法傾向于生成更小、更靈活的程序。它也是通向軟件可重用性 () - 圣杯的最佳途徑。根據定義，語言是可重用的。在編程語言的幫助下，您的應用程序以這種多層形式開發的越多，其可重用性就越好。可重用性的概念或多或少與 1980 年代出現的面向對象編程有關。無論你如何尋找證據，都不可能將這兩件事完全分開。一些使用面向對象編程開發的軟件確實是可以復用的，但這并不是因為它使用了面向對象編程，而是因為它的開發方式是自下而上的。

以函數庫為例。它們是可重用的，因為它們是語言的一部分，而不是因為它們使用面向對象或其他編程方法。順便說一句，我不認為面向對象編程在未來會消亡。我覺得，除了某些特定的領域，這種編程方式實際上并沒有給優秀的程序員帶來多少好處，但對大公司卻有著不可抗拒的吸引力。面向對象編程為您提供了一種可持續開發亂碼代碼的方法。通過不斷的打補丁，讓你一步步把軟件做大。大公司總是傾向于以這種方式開發軟件。我預計一百年后也是如此。既然我們在談論未來，那么最好談論并行計算（），因為似乎并行計算是為未來而存在的。不管你怎么想，并行計算似乎是未來生活的一部分。未來會實現嗎？在過去的二十年里，人們一直在說并行計算即將到來。但是，到目前為止，它并沒有對編程實踐產生太大影響。這是真的嗎？芯片設計人員必須考慮到這一點，為多 CpU 計算機開發系統軟件的程序員也必須考慮到這一點。然而，真正的問題是，并行計算可以達到什么抽象級別？會不會影響一百年后開發應用軟件的程序員？還是只是編譯器作者需要考慮的東西，在應用軟件的代碼中無處可尋？一種可能是，在大多數可以使用并行計算的情況下，人們會放棄使用并行計算。

盡管我的一般預測是未來的軟件將浪費大部分新硬件性能，但并行計算是一個特例。我估計隨著硬件性能的驚人提升，如果你明確說你想要并行計算，你肯定可以得到它，但你通常不會使用它。這意味著，除了一些特殊的應用，一百年后的并行計算不會是那種大規模并行計算（）。我期望對于普通程序員來說，一切更像是fork一個進程，然后讓多個進程在后臺并行運行。這是在編程的非常后期階段要做的事情。它是對程序的優化，類似于你想如何開發一個特定的數據結構來替換現有的數據結構。程序的第一個版本通常會忽略并行計算提供的各種好處，就像您在編程開始時忽略特定數據結構的好處一樣。除了一些特定的應用軟件，并行計算在一百年內不會很流行。如果應用軟件真的大量使用并行計算，那就是過早的優化。一百年后會有多少編程語言？從最近來看，出現了大量的新語言。硬件性能的提升是原因之一，這讓程序員可以根據使用目的在運行速度和編程便利性之間做出不同的權衡。如果這是未來的趨勢，強大的硬件只會在一百年內增加語言的數量。然而，另一方面，一百年內可能只有幾種通用語言。

部分原因是基于我的樂觀。我相信以后，如果你的作品真的很優秀，你可能會選擇一種易于開發的語言。用這種語言編寫的軟件第一版運行速度很慢，只有編譯器優化后運行速度才會提高。既然我這么樂觀，那我就得做出預測了。有些語言可以達到機器的最高效率，而另一些語言則很慢，只能運行。兩者之間存在巨大差距。我預測，在一百年后，這個差距的每一個點都會有相應的編程語言。因為這個差距越來越大，所以性能分析器()會變得越來越重要。目前，性能分析并未受到太多關注。許多人似乎仍然認為，提高程序速度的關鍵在于開發能夠生成更快代碼的編譯器。代碼效率和機器性能之間的差距越來越大。我們會越來越清楚地看到，提高應用軟件運行速度的關鍵是要有一個好的性能分析器來幫助指導程序開發。我說以后可能只有幾種常用的語言，但具體領域使用的“小眾語言”()不算在內。我認為這些嵌入式語言的想法非常好，肯定會蓬勃發展。但我判斷這些“小眾語言”會被設計成相當薄的一層，讓用戶一眼就能看到底層的通用語言，從而減少學習時間和使用成本。

誰來設計這些未來的語言？過去 10 年最令人興奮的趨勢之一是開源語言的興起，例如 perl 和 Ruby。語言設計已被黑客接管。目前尚不清楚這是好是壞，但發展勢頭令人鼓舞。例如，perl 有一些很棒的創新。然而，它也包含一些可怕的想法。這對于充滿侵略性和大膽探索的語言來說也是正常的。按照目前的變化速度，可能只有天知道 perl 一百年后會是什么樣子。有句話說，如果你自己做不到，那就當老師。這在語言設計領域并非如此。我認識的一些最優秀的黑客正在擔任教授。但是，老師也有很多事情是做不到的。研究職位對黑客施加了一些限制。在任何學術領域，都有一些題目可以做，有些則不能做。不幸的是，這兩種主題的區別通常取決于它們寫完后是否看起來很深，而不是它們對軟件行業的發展是否重要。也許最極端的例子是文學。文學研究者的任何成果對文學創作者幾乎沒有影響。雖然科學狀態要好一些，但研究人員可以做的主題和可以幫助設計好的語言的主題之間的交叉點小得令人沮喪。 （Olin 曾對這一點表示不滿，他說對了。

) 例如，關于變量類型的論文似乎層出不窮，盡管靜態類型語言似乎無法真正支持宏（在我看來，不支持宏的語言不值得使用）。新語言更多以開源項目的形式出現，而不是研究項目。這是語言發展的趨勢。另一個發展趨勢是，新語言的設計者更多是需要使用它們的應用軟件作者，而不是編譯器作者。這似乎是一個好趨勢，我希望它會繼續下去。一百年后的物理學基本上是無法預測的。但是計算機語言是不同的。從理論上講，設計一種能在一百年內吸引用戶的新語言似乎是可能的。設計一種新語言的方法之一是直接編寫你想編寫的程序，而不管是否存在編譯器，或者是否有支持它的硬件。這是假設您可以使用無限的資源。無論是今天還是一百年后，這樣的假設似乎都有道理。你應該寫什么程序？無論你想要什么，只要你能用最少的努力寫出來。但請注意，這必須是在您的想法不受當前使用的編程語言影響時。這種影響無處不在編程語言的發展，必須付出巨大的努力來克服。您可能會認為，對于像人類這樣的懶惰生物來說，喜歡以最省力的方式編寫程序是很自然的。但實際上，我們的思想可能往往僅限于某種現有的語言，只采用這種語言的更簡單的形式，其對我們思想的抑制作用將是驚人的。

新語言必須靠自己去發現，而不是靠讓你自然沉淪的心態。使用程序的長度作為它消耗的工作量的近似指標是一種非常有用的技術。這里的程序長度當然不是指字符數，而是各種句法元素的總長度，基本上就是整個解析樹的大小。可能不是說最短的程序就是編寫最省力的程序，但是當你想把程序寫得簡潔而不是松散時，你就離省力的目標更近了，你的生活也會變得更好。所以，設計一門語言的正確方法就變成了，看一個程序，然后問問自己，你能不能把它寫得更短？事實上，一百年后用想象的語言編寫程序，這件事的可靠性取決于你對語言核心的估計是否足夠正確。常規排序，現在就可以寫了。但是，很難預測一百年后該語言將使用什么庫。圖書館所針對的許多領域可能根本不存在。例如，如果 SETI@home 項目成功，我們將需要一個用于聯系外星人的圖書館。當然，如果外星文明高度發達，已經達到了以XML格式交換信息的地步，那么就不需要新的函數庫了。在另一個極端，我認為今天你可以設計一個一百年后的語言核心。事實上，在某些人看來，大多數語言核心是在 1958 年設計的。

如果一百年后我們可以使用一種編程語言，我們會用它來編程嗎？觀察過去，了解現在。如果今天的編程語言可以用在1960年，那個時候的人會用嗎？在某些方面，答案是否定的。今天的編程語言所依賴的硬件在1960年并不存在。比如在這樣的語言中，正確的縮進()在書寫時是非常重要的，但是1960年的計算機沒有顯示器，只有打印機終端，所以寫的不是很流暢。但是，如果排除這些因素（您可以假設我們只是在紙??上編程），那么 1960 年代的程序員會喜歡使用當前語言進行編程嗎？ ，我想他們會的。一些缺乏想象力并且深受早期編程語言思想影響的人可能會覺得不可能。 （沒有指針運算，怎么復制數據？沒有goto語句，流程圖怎么實現？）但我認為當時最聰明的程序員一定能夠輕松使用今天的大多數語言，假設他們能拿到。如果一百年后我們現在可以擁有一種編程語言，那么它至少可以用來編寫出色的偽代碼。我們會用它來開發軟件嗎？因為一百年后的一種編程語言需要為某些應用程序生成快速的代碼，所以它生成的代碼很可能可以在我們的硬件上運行，而且速度是可以接受的。與一百年后的用戶相比，我們可能需要對這種語言做更多的優化，但總的來說，它仍然應該給我們帶來凈收益。

現在，我們的兩個觀點是：1）一種一百年后理論上可以設計到今天的編程語言； 2）（（如果今天能設計出這樣的語言，很可能是適合編程，可以產生更好的結果。如果我們把這兩個觀點聯系起來，那么就得出了一些有趣的可能性。為什么不嘗試 a a from now? When When you your , it's good to keep this goal in mind. When to , one to is to the car , not by the body with the line on the , but by at a in the . Even if your is only a few away, this is . I we do the same when a .

網站欄目：一百年后，人類怎樣編程？轉：一百后
本文來源：http://m.newbst.com/news40/297990.html

成都網站建設公司_創新互聯，為您提供軟件開發、網站維護、外貿網站建設、App設計、用戶體驗、網站設計公司

廣告

聲明：本網站發布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創新互聯