Java 之父：找Bug最浪费时间，现在不是开源的黄金时代！
【CSDN 編者按】在編程工作或是學習中，你最頭疼的是什么？你知道嗎，Java之父也很討厭Bug，最讓他頭疼的事情是數值分析。然而，學生時期的他即便用最差的語言完成作業，成績照樣是A。這樣一位看似普通卻又充滿傳奇色彩的程序員，相信你也同樣對他充滿好奇。
主持人?| Grigory?Petrov，已獲Evrone授權?? ? ?
譯者?| 祝濤
出品 | CSDN（ID：CSDNnews）
90年代初，James Gosling和一群技術人員合作“綠色計劃”，創建了一個名為Oak的項目，旨在開發出能夠運行于虛擬機的編程語言，開創計算機在家電產品上的嵌入式應用。后來，這項工作就演變為Java。
1996年1月，Sun公司發布了Java的第一個開發工具包；
1997年2月，JDK 1.1面世；
1998年12月8日，第二代Java平臺的企業版J2EE發布；
2000年5月，JDK1.3、JDK1.4和J2SE1.3相繼發布;
……
隨著互聯網的普及，Java成為全球最流行的開發語言。James Gosling也因此被稱作“Java之父”。
來源：Evrone
James Gosling本人，出生于加拿大，是一位計算機編程天才，1977年獲得加拿大卡爾加里大學計算機科學學士學位，1983年獲得了美國卡內基梅隆大學計算機科學博士學位。畢業后到Sun公司工作，這才有了上面的Java。
近日，外媒Evrone的軟件工程師、技術編輯Grigory與Java之父James進行了一場線上對話。在采訪中，James提出了許多觀點，他認為：“對軟件的可靠性要求越高，靜態類型語言就越有幫助。”他還分享了自己對某些編程語言的看法：反感C語言中的宏、對Lombok又愛又恨、很喜愛Lisp等等。
關于現代編程語言的構建方式
Grigory：作為軟件開發人員和軟件顧問，我們試圖在俄羅斯組織Python、Ruby、Java和Go社區。您在Java方面的經驗和工作可以很好地幫助開發人員。通過這次采訪，我們希望能夠幫助到其他開發者，一起解決業內的基本問題。
有些語言，比如Go，沒有類和繼承一說，而另一些語言則嘗試使用諸如Rust的特性。作為一名語言設計師，您認為現代通用的、合理的編程語言構建方式應該是什么？
James：我應該會繼續使用類，類對我的編程工作很有用。在C語言中有一些宏，這非常糟糕，因為宏不是語言的一部分，不應該納入其中。而Rust的工作人員正在嘗試恰到好處地使用宏。
對于其他語言，如Lisp家族，人們總是設法更靈活地應用它們。它們有一種定義語法的方法，語法幾乎完全與語義無關。在大多數語言中，語法和語義是密切相關的。我曾寫了很多Lisp，我真的很喜歡使用Lisp程序。有的語言能讓你以不同的方式做到這一點，比如在Groovy中，你可以直接使用AST，Rust有一些語法集成的宏。但我總覺得還有一個問題：除此之外還能做什么呢？
Lisp對代碼片段進行運算，再生成新代碼，在Java世界里，人們就是這樣做的。雖然看似低級，但很受歡迎。人們可以使用注釋的組合，用一些不同的語言生成字節碼，這是超級強大的。它會給你意想不到的驚喜，比如在Jackson，它通過計算序列化程序延展了性能。
一方面，這是一種非常強大的技術，另一方面，它非常難以駕馭。這個技術充滿可能性，但這種可能性是有限的。我對Lombok又愛又恨，因為它添加了一大堆Java特性，這些特性都很不錯，但從另一方面來說，也顯示出了弱點。JCP的社區職能在下降，我已經離開好幾年了，雖然有些事情可以做，但也只能是在紙上談談。
Grigory：這就是為什么我們更想了解您創建語言的經驗，而不是一些Java增強建議。五年前，我嘗試操控一些Java字節碼。我發現，用它來創建特定領域的語言有點困難。但是有了Ruby后，就容易多了。Evrone公司有許多精通Ruby的開發人員。Ruby開發人員很優秀，但是他們需要多年的培訓才能真正掌控DSL的魔力。
James：像代碼片段運算這樣的特性，在Java中之所以尷尬是因為Java總是試圖去編譯機器代碼，Ruby幾乎總是被解釋。如果你想同時獲得超強功能和終極性能，這一切就會變得很困難。
如何看待那些破壞性的更改？
Grigory：最近，我們采訪了Ruby的創作者Yukihiro Matsumoto，他對最新的Ruby 3.0版本進行了實驗，試圖在不破壞更改的情況下發布這個版本。我知道Java對“不破壞更改”的態度一直很謹慎。讓所有語言在完全兼容的情況下進化，這是合理的嗎？還是說這個方法只能用于特定的語言，例如Ruby或Java？
James：這幾乎完全取決于開發人員社區的規模。每一個破壞性的變更都會給開發人員社區帶來痛苦。如果你沒有很多的開發人員，那么破壞更改并不是一個大問題。
除此之外，你還必須權衡成本效益。如果你做了一個突破性的改變，它會增加你的工作負擔，但也可能會帶來一些好處。不過，如果你只是將下標操作符從方括號更改為圓括號，這并不會帶來任何好處，只會徒增麻煩。
在JDK 9中，出現了一個罕見的破壞性變化：如果你使用的是隱藏API，封裝機制就會被打亂。人們打破封裝界限，運用了非常規的方式，使用了不應該使用的東西，這種改變是痛苦的。然而，一旦我們徹底改變，平臺便有了更多的創新空間。在這種改變下，平臺可以被分割，你可以定制打包，Java的運行環境就會更小。
另一個麻煩是：當遇到Bug時，人們會為之做一些變通措施，如果你修復了這個Bug，變通措施就被破壞了。在Java的世界中，確實有這樣的例子，我們要么不修復Bug，要么引入一個方法來修正錯誤，這甚至體現在硬件上。
如何看待靜態類型檢查器？
Grigory：25年前，當我開始自己的軟件開發生涯時，我寫了很多C和C++代碼。幾乎每個月都會遇到一次錯誤警報。調試這些錯誤是一件很痛苦的事情。但是現在，我看到許多工具集成到我們的工作流程中，比如靜態類型檢查器。現代開發人員使用IDE，如NetBeans、IntelliJ IDEA，甚至Visual Studio。他們編寫源代碼，編寫靜態類型檢查器解析程序，構造抽象語法樹，并進行檢查，然后在文本編輯器中標記錯誤。這些技巧不僅適用于靜態類型的語言，也適用于動態類型的語言，在Python、Ruby和TypeScript中皆可使用。
你對靜態類型檢查器有什么看法？它們能幫助人們編寫出更好的程序，還是說需要在語言語法中添加更多內容？
James：我都同意。我非常喜歡使用靜態類型系統的語言，因為它們為靜態類型檢查器和IDE提供了一個框架。作為一名資深軟件工程師，尋找那些奇怪的Bug是最浪費時間的。為減少這方面的時間浪費，我會盡力阻止Bug的出現。因此，我非常喜歡IDE，它能夠提供減少Bug的方法。而動態類型語言很少有框架來解決這個問題，因為它們不一定能判斷所有類型，只能靠猜測。強類型語言（如Java）為類型檢查器提供了更嚴格的框架。在另一個層次上，甚至可以進行自動的定理證明。像Dafny這樣的系統，它有一個非常復雜的定理證明器。所以如果你想建立一個加密算法，你將能夠用數學方法進行證明。這聽上去很夸張，但對于某些代碼來說，真的很有用。
這很大程度上取決于你的目標是什么。
如果你是一名正在努力完成作業的大學生，或是一名正在努力畢業的博士生，那么當你編寫一個程序時，你的目標是讓這個程序至少能運行一次，因為你必須要展示成果。
如果你在行業環境中，那么每次運行都必須成功。一次運行成功和每次都運行成功之間的差別是巨大的。如果只需要運作一次，那么動態語言會更合適。如果你必須確保它能一次又一次地運行，那么所有的靜態類型工具都適用。
如果你是一個物理學家，你想得出一些計算結果，那么它只需要運行一次。這取決于你的工作背景。你對軟件的可靠性要求越高，靜態類型語言就越有幫助。
現在是開源軟件的黃金時代嗎？
Grigory：我們來談談企業和產業發展吧。我從來沒做過機器人，但我曾在大型開發公司工作過，如果將今天和20-25年前進行比較，我們會發現，像GitHub這樣的社交編碼平臺，得到了大公司的支持，他們幫助個人開發者和企業軟件開發者進行開源開發。那么，現在是不是開源軟件的黃金時代呢？你有何看法？
James：我不知道。這個問題涉及未來。“現在是黃金時代嗎？”背后的意思是，將來要開始走下坡路了嗎？如果現在是黃金時代，那么未來就不是黃金時代了嗎？
我認為我們一直都在邁向黃金時代，依然在不斷改進。目前，我們依然有各種各樣的安全問題，網絡攻擊不斷，因此我不保證這是黃金時代。如果有一種方式，可以終結網絡安全隱患，那將是非常好的。現在確實是個好時機，但還可以更好。
為什么有的語言不使用JIT？
Grigory：您使用JIT（即時編譯）創建了Java和JVM。JIT保證了高速，同時保持了高級語法。許多語言都跟隨你的腳步，比如C#和JavaScript。其他語言，如Python、Ruby、PHP，都有可選的JIT，但不太常用。許多主流語言也并不使用JIT來提升速度。為什么不是所有的語言都使用JIT呢？他們不想為軟件開發人員提供更快的速度嗎?
James：如果開發者想要獲得性能改進，那么使用靜態類型語言是非常有用的。通常，人們會給語言添加注釋，就會得到TypeScript這樣的語言，TypeScript的本質就是帶有類型注釋的JavaScript。而JavaScript的本質是Java，只是去掉了類型聲明。所以TypeScript本質上就是帶有置換語法的Java。
在Python之類的語言中，通常只有一種數值，那就是雙精度浮點數。沒有真正的整數，沒有字節和16位整數這些東西。如果是雙精度浮點數和單精度浮點數，概念認知的過程會很復雜，但你必須掌握數值分析。許多軟件工程師對數值分析幾乎一無所知，所以他們直接放棄了。
如果你是一個使用Python的物理學家，那么精確度對你來說是最重要的。如果你需要在內存中放入一個非常大的數組，在這種情況下，單精度和雙精度或8位整數之間的差異就非常重要。
在我的一生中，我參加過許多數值分析課程，被數值分析弄得焦頭爛額，因此我不得不關注數值分析。具體問題具體分析，大多數使用腳本語言的人并不關注這類問題。很多人并不關心具體的性能和數值，他們關心的是：“它夠快嗎？”性能是一個boolean值，對一些人來說，這更像是調試一輛賽車，如果你的車每小時能多行駛兩到三英里，你更有可能獲勝。
Grigory：幾個月前，Ruby on Rails(一種廣受歡迎的Web框架)的作者David Heinemeier Hansson提到，在他的云計算的應用開發中，性能基本都是由緩存、消息隊列、存儲等方面決定的，開發語言的影響最多不超過15%。他指出，不管Ruby有多“慢”，這都不是很重要，因為即使Ruby的速度快了100倍，將15%變成了1%，也不會改變什么。
James：要具體分析你的任務類型。如果你的任務是由網絡和數據庫等主導的，你一直在做RPC，那么第一步就是質疑這些RPC是否有價值。微服務確實挺不錯，但是它們比方法調用慢一百萬倍。想想這意味著什么。
對于大多數人來說，他們可以通過清晰的大規模架構來獲得更多性能。但對部分人而言，所有的細節都很重要。如果你知道高并發的重要性，知道它能夠同時驅動數千個進程，進行大型計算；如果你做的是數據庫或存儲服務，你會非常在意這些細節。所以這完全取決于你手頭的任務。
關于現代async/await方法
Grigory：許多語言都采用了協程和async/await方法來處理網速慢之類的問題。這個方法被添加到Python、 Ruby、 JavaScript以及其他語言中。但是在一個線程中這個方法并不是無所不能的，并且很復雜，有時還會使軟件運行速度變慢。那么，您如何看待這種現代async/await方法呢？這是處理網絡的好方法，還是我們誤用了它，我們需要尋找其他方法？
James：這依然取決于實際情況。協程是完美的，它起源于60年代。第一種使用協程的語言是Simula 67。Simula是一種很好的語言，它沒有線程，但是有協程，只不過它們做協程的方式看起來很像線程。協程完全避開了并行中的一些難題。對我來說，協程有一個問題：它們不允許使用多個處理器，無法做到真正的并行。因此我已經很久沒有使用協程。
所以人們更重視那些真正具有并行性的語言，比如Erlang和Java。
在Java中使用ConcurrentHashMap可以做到很多事情。如果你在進行多協程操作又沒有足夠的處理器，一旦你使用基于協程的語言并使用多個處理器，最后也只是飽和了一個處理器而已。使用多個處理器也是不得已的，畢竟世界上已經沒有單位處理器了。每樣東西都有很多內核，如果你想在一個問題上同時使用所有的計算機，你只需要克服多線程所固有的復雜性。
還有樣式的問題。透明的控制反轉時常發生，而你只能被動接受。這會讓你的語法看起來很像線程，但也意味著在真正的線程中會遇到一些問題。例如，你輸入“a=a + 1”的語句，你知道這個操作不會被中斷，所以你不需要同步。但在其他情況下，它變成了一個event導向的樣式，操作過程中，你需要插入一個事件處理程序，去處理后續問題。這就是JavaScript的主要風格。這樣也不錯，但似乎有點笨拙。
70年代早期，我第一次接觸Simula，我發現它很靈活，在編碼過程中，運算過程幾乎是獨立的。作為一個概念模型，它要清晰得多。
第一語言的選擇
Grigory：我想問一個非技術問題，在你看來，對于現在剛入門的軟件開發人員或者是研究生和大學生而言，他們應該選擇哪一種語言來作為他們的第一語言？
James：我回答這個問題可能會帶有一點偏見，畢竟 Java 已經成功運行這么多年。我學的第一種編程語言是PDP-8匯編代碼，隨后是Fortran。大家可以去學習任何語言，有些人的接受能力更強，但這很大程度上取決于一個人最終的職業道路。如果你想成為一個軟件開發人員，你要構建大型的、高性能的系統，運行在JVM上的語言最值得去學習，例如Scala和Kotlin，Clojure很有趣。如果你是物理專業的學生，Python是個不錯的選擇。
其實選哪一種語言都無關緊要，很多人都只是堅持他們學到的第一種語言，如果你能讓人們反復學習各種語言，那肯定是最好的。我認為每個大學都應該為學生開設一門“比較編程語言”的課程。用五種不同的程序語言完成作業，這能加快學習進度，并且他們會發現這些語言的區別真的不大，同時也能讓他們自己去思考，哪一種語言更好。很久以前我上過一門課，每次作業我都用最不合適的語言，例如，用Cobol語言進行數值計算，以及Fortran中的符號操作。令人驚訝的是，我的成績依然是A。
如何看待“模式匹配”？
Grigory：下一個問題是關于模式匹配的。最近，它與Python、Ruby接軌，并且為不同的語言提出了建議。我們查閱了開發人員白皮書發現，目前并不能完全確定模式匹配在現代高級語言中的作用。您認為這種模式匹配思想，如何適用于Java、Python、Ruby或其他高級語言？我們真的需要模式匹配嗎，或者它是特殊案例的特定用法?
James：對于新手來說，我認為編程語言中的“模式匹配”一詞會造成誤導。當我聽到“模式匹配”這個短語時，我想到的是正則表達式。Simula有inspect語句，而inspect語句與許多模式匹配語句幾乎完全相同。inspect語句是一個case語句，其中case標簽是類型名，你可以執行：
Inspect?P When?Image?do?Show; When Vector do Draw;因此可以把它看成是一個case語句，用case處理類型，大多數模式匹配語言的建議都是這樣的。就我個人而言，我很喜歡，特別是應對C的隱形強制轉換。在C之類的語言中，常常需要進行強制轉換。如果你執行“inspect P When Image P do P ”，那么在case語句體中，P就是switch標簽的類型，這讓一切都變得簡單多了。我很喜歡Simula中的inspect語句。我同意所謂“特殊案例”的說法，如果稱之為“模式匹配”，但是它又不如正則表達式，就會有誤導性，像一則虛假廣告。但是拋開這些，我依然認為它的功能很強大。
可以將所有的語言聯系到一起嗎？
Grigory：還有最后一個問題。俄羅斯軟件開發人員對JetBrains和Kotlin的開發倍感驕傲。Kotlin、Clojure和Scala等語言，在您創建的Java虛擬機、庫、框架和現有代碼生態系統上蓬勃發展。但是，這些語言都面臨著挑戰嗎？能不能把這些語言都聯系到一起呢？當有人試圖用不同的語法對Java執行hotswap操作時，會遇到什么困難？
James：這要看你的目的是什么。Java虛擬機內置了許多安全性和可靠性的概念，主要與內存模型的完整性有關，諸如指針之類的東西，因此你不能偽造指針。對于C語言，如果你沒有能力偽造，你將無法使用。如果你試圖在JVM上實現C語言，并配置了嚴格的安全虛擬機，有些功能將無法實現。但是有些人所構建的虛擬機并沒有嚴格的安全模型，并且沒有內存分配模型。如果想要在C和Kotlin之間實現互操作，就必須放棄一定程度的安全性和可靠性。這就看你的取舍了。
在Java誕生之初，我的原則是：我不想調試內存損壞問題。在內存奔潰問題上我已經浪費了太多的時間，這個問題能消耗你幾天的時間。我真的很討厭追蹤內存損壞bug。不過，每個人的喜好不同，可能有人認為花時間做這件事很有價值。也有人喜歡使用vi，在70年代和80年代它都是一個很好的編輯器。
Grigory：內存安全模型確實很重要，它提供了一些東西，但也造成了一些限制。非常感謝你，James！
結語
讀完Java之父的專訪，你有哪些收獲與見地呢？對你來說，哪種語言是你的第一語言呢？
本文經原作者授權，由CSDN翻譯，轉載請注明來源！原文鏈接：
https://evrone.com/james-gosling-interview?
總結
以上是生活随笔為你收集整理的Java 之父：找Bug最浪费时间，现在不是开源的黄金时代！的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Java简繁体转换分享
- 下一篇： 马士兵学习笔记-Java基础网络编程