Java之父接受Evrone專訪：您需要的軟件可靠性越高，靜態(tài)類型語言的幫助就越大
[導讀]每一次重大更改都會在開發(fā)人員社區(qū)中引發(fā)痛苦。如果您的開發(fā)人員不多，那么破壞性更改不是大問題。而且您還必須考慮成本效益的權衡。如果你做一個突破性的改變，它會增加一些痛苦，但也會帶來一些好處。JamesGosling：“您需要的軟件可靠性越高，靜態(tài)類型語言的幫助就越大?！苯榻BJava...
每一次重大更改都會在開發(fā)人員社區(qū)中引發(fā)痛苦。如果您的開發(fā)人員不多，那么破壞性更改不是大問題。而且您還必須考慮成本效益的權衡。如果你做一個突破性的改變，它會增加一些痛苦，但也會帶來一些好處。
James Gosling：“您需要的軟件可靠性越高，靜態(tài)類型語言的幫助就越大。”
Java之父James Gosling
????When?Image?do?Show;
????When?Vector?do?Draw;
所以你可以把它想象成一個 case 語句，它在類型上有 case。而這些模式匹配語言提案中的大多數都屬于這種類型。就我個人而言，我很想念它。我真的很喜歡那個。特別是如果發(fā)生的事情就像 C 中的隱式強制轉換一樣。所以如果你說“在圖像 P 做 P 時檢查 P”，在 case 語句的主體中，P 現(xiàn)在是 switch 標簽的類型。這讓生活變得更加輕松。在所有這些地方，在具有類似 C 語法的語言中，您總是以強制轉換告終。它看起來像：“如果 a 是 x 的實例，否則如果 a 是 y 的實例，然后……” Simula 中的“檢查”語句非常漂亮；我愛它。從那以后，我每天都在懷念它，許多這些模式匹配提議和語言特性看起來就是這樣。如果你稱它們?yōu)椤邦愋桶咐薄弥饕?。但是如果你稱它為“模式匹配”，而且它的威力比正則表達式要小，那感覺它是誤導性的，或者像虛假廣告。但是，作為一個功能，我認為它很棒。Grigory：我們的最后一個問題有點強制性。俄羅斯軟件開發(fā)人員為 JetBrains 和 Kotlin 的開發(fā)感到自豪。當然，我不會問一些像Java vs. Kotlin之類的瑣碎事情。我會試著問一些不同的事情。Kotlin 和許多其他語言（如 Clojure 或 Scala）在您創(chuàng)建的現(xiàn)有 Java 虛擬機以及現(xiàn)有的庫、框架和現(xiàn)有代碼生態(tài)系統(tǒng)上蓬勃發(fā)展。所有這些語言都面臨任何挑戰(zhàn)嗎？有什么東西可以把他們團結起來嗎？對他們來說有些困難？當他們試圖用一些不同的語法熱交換 Java 語法時，他們面臨哪些挑戰(zhàn)？James：有點取決于你想要做什么。Java 虛擬機的特點之一是它內置了許多安全性和可靠性的概念。它們主要與內存模型的完整性有關。指針之類的。所以你不能偽造一個指針。如果你看看像 C 這樣的語言，如果你沒有偽造的能力，你就不能做 C。有一些虛擬機沒有嚴格的安全模型。在 JVM 之類的東西上，如果您嘗試實現(xiàn) C - 有些人已經這樣做了，盡管這很奇怪 - 如果您有一個嚴格安全的虛擬機，那么有些地方您就不能去。但是有些人構建的虛擬機并不嚴格安全，沒有內存分配模型。所以這取決于你愿意去哪里。當然，在 Java 誕生之初，我的個人規(guī)則之一是：我不想調試另一個該死的內存損壞錯誤。我已經浪費了太多時間在需要數天時間在內存損壞錯誤上。這只是一個循環(huán)中的一個錯誤，恰好從數組末尾移出一個條目，直到數百萬條指令之后您才會發(fā)現(xiàn)。而且我真的，真的很討厭追逐內存損壞錯誤。所以這取決于你對什么感到舒服。有些人，你知道的，認為花時間這樣做非常有男子氣概。但是也有人喜歡使用 vi，它在 70 年代是出色的編輯器，在 80 年代是出色的編輯器……加油，伙計們！James：內存安全模型確實是核心，它提供了一些東西，但限制了一些東西。非常感謝你，詹姆斯！很高興與您進行這次談話，我希望在經歷了這場僵尸啟示錄之后，我們可以在某個線下會議上見面。謝謝你，祝你有美好的一天！
James Gosling：“您需要的軟件可靠性越高，靜態(tài)類型語言的幫助就越大。”
介紹
采訪
Grigory：作為軟件開發(fā)人員和軟件顧問，我們試圖在俄羅斯組織一個社區(qū)：Python、Ruby、Java 和 Go 社區(qū)。我們希望通過采訪突出我們行業(yè)的基本問題來幫助我們的開發(fā)人員。我認為你的經驗和你在 Java 方面的工作可以幫助開發(fā)人員變得更好。所以讓我們努力幫助他們吧！一些語言，比如 Go，省略了類和繼承，而另一些語言則在 Rust 中嘗試使用特性等特性。作為語言設計師，您認為編程語言進行組合的現(xiàn)代、通用、合理的方式是什么？James：我不認為我不會上課。我實際上發(fā)現(xiàn)類對于組合非常有效。對于如何做不同的事情，我真的沒有任何好的、清晰的想法。我會以不同方式做的一些事情有點奇怪。在 C 中有宏，這幾乎是一場災難，因為宏不是語言的一部分；他們有點不在乎。Rust 的人試圖在語言中很好地擬合宏。其他語言，如所有 Lisp 家族，設法更優(yōu)雅地適應它們，但它們有一種定義語法的方法，其中語法幾乎完全沒有語義。在大多數語言中，語法和語義是齊頭并進的。作為前世寫過很多 Lisp 的人，我真的沉迷于使用 Lisp 程序來操作 Lisp 程序的技術。這是我非常非常想念的一件事。某些語言允許您以不同的方式執(zhí)行此操作，因此就像在 Groovy 中一樣，您可以直接使用 AST。Rust 有某種語法集成的宏。但我總覺得里面有一個有趣的研究問題：你能做更多嗎？我能體會到 Lisp 對代碼片段進行計算以生成新代碼的感覺嗎？在 Java 世界中，人們會這樣做。這是比較流行的功能之一，只是它的級別非常低。因為人們結合使用注釋和您可以使用某些不同語言生成字節(jié)碼的事實。那是超級強大。它被用在你意想不到的地方，比如在杰克遜。它通過計算序列化器獲得了很多性能。一方面，這是一種非常強大的技術。另一方面，它非常難以使用。事實證明這是可能的。但你能走多遠？它們可能是有限的。所以，如果你看看像 Lombok 這樣的東西，我發(fā)現(xiàn)它是其中之一......好吧，我對它有強烈的愛恨情仇。因為它添加了一堆非常好的 Java 特性，但另一方面，它也顯示出弱點。部分在這個過程中，因為這是一組應該只是內置的功能。Java 社區(qū)的驅動力已經變弱了并沒有推動這些特性的發(fā)展。我本人已經不再社區(qū)內很長時間了，但是這些你想干的事情僅僅停留在路線圖上（but there are things you could do that are just all over the map 不太好翻譯）。?Grigory：這就是為什么我們準備了有關您創(chuàng)建語言的奇妙體驗的問題，而不是一些現(xiàn)代 Java 增強提案。五年前，我可以承認，我操縱了一些 Java 字節(jié)碼。當然，這是好的，但是從中創(chuàng)建特定于領域的語言有點棘手。有了 Ruby，事情就簡單多了。我們 Evrone 精通 Ruby，我們有數十名 Ruby 開發(fā)人員。Ruby 開發(fā)人員很棒，但是他們需要經過多年的培訓才能學習所有 DSL 魔法。James：具有計算代碼片段等功能的事情之一，它在 Java 中很尷尬的原因之一是 Java 試圖一路編譯機器代碼。Ruby 幾乎總是被解釋的。當你這樣做時，當你不試圖獲得所有你能獲得的表現(xiàn)時，生活就很容易了。但是，如果您想同時獲得強大的功能和終極性能，生活就會變得更加艱難。Grigory：最近，我們采訪了 Ruby 的作者 Yukihiro Matsumoto，他提到他對他最新的 Ruby 3.0 主要版本進行了實驗。他試圖在不破壞更改的情況下發(fā)布這個版本，看看會發(fā)生什么。不會破壞任何內容的主要語言版本。我知道 Java 對不破壞事物持謹慎態(tài)度。所有語言都在沒有不兼容的情況下發(fā)展是一個好主意嗎？或者它是一種只能用于特定語言（如 Ruby 或 Java）的有限方法？James：這幾乎完全取決于開發(fā)者社區(qū)的規(guī)模。每一次重大更改都會在開發(fā)人員社區(qū)中引發(fā)痛苦。如果您的開發(fā)人員不多，那么破壞性更改不是大問題。而且您還必須考慮成本效益的權衡。如果你做一個突破性的改變，它會增加一些痛苦，但也會帶來一些好處。例如，如果您將下標運算符從方括號更改為圓括號，它可能不會給您帶來任何好處，并且會引起極大的痛苦。那將是一個愚蠢的想法。在 JDK 9 中，發(fā)生了變化，這是引入的極少數破壞性更改之一，它破壞的是：如果您正在使用一些所謂的隱藏 API，封裝機制會被打亂，而那些破壞的人封裝邊界和使用不應該使用的東西以不應該使用的方式使用，他們在從 8 到 9 的過程中遇到了一些痛苦。但是一旦我們超越了這個界限，它就會讓平臺有更多的創(chuàng)新自由。而在這種從 8 到 9 過渡的特殊情況下，這意味著平臺可以切片和切塊，您實際上可以進行自定義包裝，這樣 Java 運行時環(huán)境就會更小。另一個總讓人感到不舒服的地方是：當某事存在錯誤，并且人們?yōu)樵撳e誤制定了解決方法時，如果您修復了錯誤，則可能會破壞解決方法。在 Java 世界中肯定有過這樣的例子，我們決定要么不修復錯誤，要么引入一種做正確事情的方法。這甚至出現(xiàn)在硬件中。sin 和 cos 有問題，它們有點不正確，所以你必須有正確和不正確的指令。Grigory：25 年前，當我開始自己的軟件開發(fā)職業(yè)生涯時，我編寫了大量 C 和 C 代碼。我記得這些每月發(fā)生一次的神秘指針錯誤。調試這樣的錯誤很痛苦。但是現(xiàn)在，作為一名軟件開發(fā)人員，我看到許多工具集成到我們的工作流程中，例如靜態(tài)類型檢查器?，F(xiàn)代開發(fā)人員使用 IDE，如 NetBeans、IntelliJ IDEA，甚至 Visual Studio Code。他們編寫源代碼，靜態(tài)類型檢查器解析程序，構建抽象語法樹，并檢查所有可能的內容。然后在文本編輯器中突出顯示可能的錯誤。這些技巧不僅適用于靜態(tài)類型語言，甚至適用于動態(tài)類型語言，如 Python、Ruby 和 TypeScript。您對我們今天使用的這些靜態(tài)類型檢查器有何看法？它們是朝著編寫更好的軟件邁出一步，還是我們需要在語言語法中加入更多內容？James：嗯，兩個都需要。我是靜態(tài)類型系統(tǒng)語言的忠實粉絲，因為它們?yōu)殪o態(tài)類型檢查器和 IDE 的工作提供了一個腳手架。我一生中的大部分時間都是作為一名軟件工程師度過的，對我來說，最不令人滿意的消磨時間的方式就是尋找在奇怪的時間發(fā)生的晦澀的錯誤。我能做的任何事情都可以讓錯誤在它們浪費我的時間之前消失，這是一件好事。所以，我非常喜歡 IDE 可以做的任何事情來降低出現(xiàn)錯誤的可能性。因此，當我們查看 JavaScript 和 Python 等動態(tài)類型語言時，它們沒有足夠的推理框架來解決這個問題，因為它們不一定知道任何東西的類型；他們只是在猜測。強類型語言（如 Java）為類型檢查器提供了更嚴格的框架以供使用。和，更上一層樓，有些事情可以進行全自動定理證明。所以有像 Dafny 這樣的系統(tǒng)，它有一個非常復雜的定理證明器。因此，如果您想構建一個加密算法，您將能夠從數學上證明屬性。你可以這樣做。這可能有點過頭了，但對于某些代碼來說，它確實很有用。而且很大程度上取決于您的目標是什么。如果你是一名大學生并且你正在努力完成你的作業(yè)，或者你是一名博士。學生，并且您正在嘗試畢業(yè)，那么當您編寫程序時，您的目標是它應該運行一次。至少一次。因為你必須做一個演示并能夠展示它，看看它是否有效。如果您在工業(yè)環(huán)境中，我一生中的大部分時間都在那里工作，那么工作一次只會有點用處。它必須每次都有效。一次工作和每次工作之間的差異是巨大的。因此，如果它只需要工作一次，那么更動態(tài)的語言工作得相當好。如果您必須確保它會一遍又一遍地工作，那么所有靜態(tài)類型工具都可以幫助您建立信心。但如果你正在做的事情是......說，你是一個物理學家，你想找出一些計算的結果，它只需要運行一次。這取決于你正在做的工作的背景。您對軟件的可靠性要求越高，靜態(tài)類型語言的幫助就越大。Grigory：談企業(yè)和產業(yè)發(fā)展。我從來沒有給機器人編程過，但我花時間在為數百萬人開發(fā)軟件的公司工作，我可以將今天和 20-25 年前進行比較。我現(xiàn)在看到，像 GitHub 這樣的社交編碼平臺得到了大公司的支持，它們幫助個人開發(fā)人員和企業(yè)或工業(yè)軟件開發(fā)人員進行開源開發(fā)。那么我們可以將今天稱為開源軟件的黃金時代，還是不是很清楚？你怎么看待這件事？James：我不知道。你在問一個關于未來的問題。而問題的問題，“今天是黃金時代嗎？”……這個問題含蓄地說：“從這里開始走下坡路了嗎？”如果這是黃金時代，那么明天就不會那么黃金了。我認為我們正在引領它，無論黃金時代是什么。我認為可能會發(fā)生很多有趣的改進。目前，我們面臨著各種圍繞安全以及人們如何進行網絡恐怖主義的危機。當這種事情發(fā)生時正在發(fā)生，我不認為這是黃金時代。如果人們社區(qū)的合作有某種方式可以導致網絡恐怖主義的終結 - 那將是非常黃金的。我們會看到。我的意思是，這是一個真是美好的時光，但可能會更好。Grigory：您使用 JIT（即時編譯）創(chuàng)建了 Java 和 JVM（Java 虛擬機）。JIT 提供了非常驚人的速度，同時保持語言語法愉快和高級。許多語言都跟隨您的腳步，例如 C# 和 JavaScript。通過熱路徑編譯和重新編譯代碼的速度接近 C 和 C 。但是許多其他語言，Python、Ruby、PHP，都有不那么流行的可選 JIT。并且許多主流語言不使用 JIT 來獲得如此巨大的速度提升。為什么不是所有語言都使用 JIT 為軟件開發(fā)人員提供極好的速度？James：要真正獲得您所看到的性能改進，擁有一種靜態(tài)類型語言非常有幫助。對于像 Python 這樣的動態(tài)類型語言，這真的非常困難。通常情況下，人們最終會在語言中添加注釋，以便獲得類似 TypeScript 的語言，它本質上是帶有類型注釋的 JavaScript。這真的很有趣，因為 JavaScript 本質上是 Java，刪除了類型聲明。因此，TypeScript 本質上是具有排列語法的 Java。他們有一些 Pascal 風格的聲明。但是，如果您只是在 Python 中編寫快速腳本，那么這個世界上的很多人都會發(fā)現(xiàn)聲明很煩人?？紤]變量的類型很煩人。在 Python 和許多其他語言中，通常只有一種數字，那就是雙精度浮點數。沒有真正的整數，沒有字節(jié)和 16 位整數以及類似概念上增加復雜性的東西，但它們也提高了性能。如果你有一個雙精度浮點數和一個單精度浮點數，那么就會有認知負擔。要做出明智的權衡，您必須了解一些數值分析。對于軟件工程師來說，對數值分析幾乎一無所知是很常見的。所以他們寧愿不去想它。如果您是一名使用 Python 的物理學家，您可能希望獲得幾乎總是可以獲得的所有精度。當然，除非你需要在內存中放入一個非常大的數組，其中單精度和雙精度或 8 位整數之間的區(qū)別真的很重要。如果你生活在一個這些東西都沒有任何影響的空間里，那對人們來說就更容易了。但是如果你需要關心的話……我這輩子上過太多的數值分析課程，并且被劣質數值分析燒傷了足夠多的時間，我傾向于關心。這取決于您在頻譜上的位置，腳本語言世界中的大多數人并不關心這類問題。他們的擔憂處于非常不同的水平。很多人實際上并不關心性能和數字的細節(jié)；他們關心的是：“速度夠快嗎？” 性能有點像布爾值：它足夠快，或者它不夠快。對于某些人來說，這更像是調整賽車。如果您的汽車每小時能多跑兩到三英里，那么您就更有可能贏得比賽。Grigory：我記得幾個月前，Ruby on Rails（廣受歡迎的 Web 框架之一）的作者 David Heinemeier Hansson 提到，他的云預算中只有 15% 用于語言本身。剩下的就是一些緩存、消息隊列、存儲等。他告訴我們，無論 Ruby 有多“慢”，它都不是很重要，因為即使 Ruby 快了 100 倍并且 15% 變成了 1%，這也沒有太大變化?，F(xiàn)代語言確實“足夠快”。James：這在很大程度上取決于您的任務在程序空間中的位置。如果你想要完成的事情真的是由網絡和數據庫以及其他所有東西主導的，如果你一直在做 RPC，那么你應該做的第一件事可能是質疑所有這些 RPC 是否都是有價值的。當人們談論微服務時，它們是一件好事，但只要明白它們至少比方法調用慢一百萬倍。仔細想想這意味著什么。通常，對于大多數人來說，通過確保他們的大型架構是干凈的，他們會獲得更高的性能。但是對于很多人來說，所有細節(jié)確實很重要。如果您知道高度并發(fā)很重要，能夠同時驅動數千個進程，進行主要計算。. 如果您正在做諸如數據庫本身或主要存儲服務之類的事情，您真的非常關心。所以這一切都取決于手頭的任務。Grigory：最近，我們看到許多語言都采用協(xié)程和 async/await 方法來處理諸如網絡之類的事情，這很慢。它被添加到 Python 中，它被添加到最近的 Ruby、JavaScript、許多語言中。但是這種在一個線程中的 async/await 和協(xié)程和調度程序并不是靈丹妙藥。它們帶來了自己的復雜性，有時它們會使軟件變慢。那么你如何看待這種現(xiàn)代的 async/await 炒作？它是處理網絡的好方法，還是我們只是濫用它，我們需要檢查 Erlang 和其他方法？James：這是上下文決定一切的事情之一。協(xié)程非常好；它們從 60 年代就存在了。第一種帶有協(xié)程的語言是 Simula 67。Simula 是一種可愛的語言。我仍然很想念它。它沒有線程，它有協(xié)程，但是他們做協(xié)程的方式——它們看起來很像線程。協(xié)程有點神奇地回避了真正并行中的一些頑皮問題。對我來說，協(xié)程的問題之一，這就是我很久沒有使用它們的原因，是它們實際上并沒有讓你這樣做或讓你利用多個處理器。你不能做真正的并行。所以人們會用具有真正并行性的語言來看待事物，比如 Erlang 和 Java。你必須做的事情增加了另一個層次的復雜性。盡管通常情況下，您處理這種復雜性的方式是通過精心策劃的原語。你可以用 Java 中的 ConcurrentHashMap 做的事情很神奇。但是，一旦您獲得了這些基于協(xié)程的語言中的一種并嘗試利用多個處理器，如果您正在執(zhí)行大量協(xié)程類型的操作而您沒有足夠的處理器，那么您只會使一個飽和處理器。你真的很想使用多個處理器，因為世界上不再有單位處理器了，對吧？一切都有很多核心，如果你真的想一次使用你所有的電腦，在一個問題上，然后是風格問題。想象一下這樣的環(huán)境，你可以說“等待這個”和“等待那個”，他們會在你被動讓步的情況下進行這種透明的控制反轉。這為您提供了看起來很像真正線程的語法外觀。但這意味著您可以避免真正線程中的許多棘手問題。因此，如果您說“a = a 1”，您就知道在該操作的中間您不會被中斷，因此您不必進行同步。但是在其他地方，它不是做那種風格，而是變成了一種事件導向的風格，在那里你做你的事情，然后你把一個事件處理程序插入一些東西來處理當事情完成時發(fā)生的事情。這往往是 JavaScript 中的主要風格。效果很好，當我在 70 年代初發(fā)現(xiàn) Simula 時，它有一種自然的風格。你只是編程，你可以把你的計算看作是一個獨立的東西。其他事物是否與它交織對您來說是透明的。我發(fā)現(xiàn)它作為一個概念模型，比事件編程要簡潔得多。在幕后實施更難，但通常更容易考慮。Grigory：畢竟 Simula 是第一個面向對象的語言！我從來沒有機會使用它，但我查看了文檔，它看起來很有特色。然而，如果我們回顧一些像 Ruby 這樣的現(xiàn)代語言，并發(fā)模型是復雜的：我們有進程、進程中的單獨解釋器、單獨解釋器中的線程和線程中的核心例程——就像一個俄羅斯娃娃。如果您允許，現(xiàn)在是一個非技術問題。當我們談論不同的語言時，在您個人看來，現(xiàn)在教新軟件開發(fā)人員的最佳語言是什么，作為他們的第一語言？也許在研究生院或大學。James：我顯然有偏見。Java 已經以這種方式成功使用了很長時間。但我學習的第一種編程語言是 PDP-8 匯編代碼，大致與 Fortran 并行。你可以教人們任何東西。它會比其他人更容易進入他們中的一些人，但這在很大程度上取決于一個人最終的職業(yè)道路將是什么。如果您打算成為一名全面的軟件開發(fā)人員，在其中構建某種大型、高性能系統(tǒng)，那么很難擊敗任何在 JVM 上運行的語言。而且我實際上并不關心您在 JVM 上使用哪種語言。我的意思是，Scala 和 Kotlin 都很好。Clojure 真的很有趣，但您必須真正以不同的方式思考。如果你是一名物理學生，Python 很好。而且我認為您選擇哪個實際上并不是什么大問題。雖然很多人只是堅持他們學到的第一件事并這樣做，但如果你能讓人們學習多種語言并來回......每所大學都應該為每個學生開設的一個非常好的課程是一個比較編程語言課程。在這個學期，你有 5 個不同的程序語言的 5 個作業(yè)，這讓人們習慣于快速學習它們，因為它們實際上并沒有什么不同，并讓他們思考哪些更好。很久以前，我參加了其中一門課程，我在每項作業(yè)中都使用了絕對最差的語言。在 Cobol 中進行數值計算。那只是有趣！和 Fortran 中的符號操作......令人驚訝的是，我仍然得到了 A。Grigory：正如預期的那樣。所以，下一個問題是關于模式匹配。最近，它光榮地登陸了 Python 和 Ruby，并且有很多不同語言的提案。我們查看了開發(fā)人員白皮書，他們并不完全確定模式匹配在現(xiàn)代高級語言中的作用。這種模式匹配的想法，對于使用 Java、Python、Ruby 或某些高級語言的普通現(xiàn)代開發(fā)人員，我們真的需要模式匹配嗎，還是它是針對特定用例的一些小眾語法？James：首先，我認為編程語言中的術語“模式匹配”有些誤導。因為當我聽到“模式匹配”這個詞時，首先想到的是正則表達式，無論是字符串上的正則表達式還是樹上的正則表達式。也許模式匹配樹的形狀，無論如何。但是回到Simula。Simula 有一個檢查語句，檢查語句幾乎就是這些模式匹配語句中的許多語句。即，inspect 語句是一個 case 語句，其中 case 標簽是類型名稱，所以你會說：Inspect?P????When?Image?do?Show;
????When?Vector?do?Draw;
所以你可以把它想象成一個 case 語句，它在類型上有 case。而這些模式匹配語言提案中的大多數都屬于這種類型。就我個人而言，我很想念它。我真的很喜歡那個。特別是如果發(fā)生的事情就像 C 中的隱式強制轉換一樣。所以如果你說“在圖像 P 做 P 時檢查 P”，在 case 語句的主體中，P 現(xiàn)在是 switch 標簽的類型。這讓生活變得更加輕松。在所有這些地方，在具有類似 C 語法的語言中，您總是以強制轉換告終。它看起來像：“如果 a 是 x 的實例，否則如果 a 是 y 的實例，然后……” Simula 中的“檢查”語句非常漂亮；我愛它。從那以后，我每天都在懷念它，許多這些模式匹配提議和語言特性看起來就是這樣。如果你稱它們?yōu)椤邦愋桶咐薄弥饕?。但是如果你稱它為“模式匹配”，而且它的威力比正則表達式要小，那感覺它是誤導性的，或者像虛假廣告。但是，作為一個功能，我認為它很棒。Grigory：我們的最后一個問題有點強制性。俄羅斯軟件開發(fā)人員為 JetBrains 和 Kotlin 的開發(fā)感到自豪。當然，我不會問一些像Java vs. Kotlin之類的瑣碎事情。我會試著問一些不同的事情。Kotlin 和許多其他語言（如 Clojure 或 Scala）在您創(chuàng)建的現(xiàn)有 Java 虛擬機以及現(xiàn)有的庫、框架和現(xiàn)有代碼生態(tài)系統(tǒng)上蓬勃發(fā)展。所有這些語言都面臨任何挑戰(zhàn)嗎？有什么東西可以把他們團結起來嗎？對他們來說有些困難？當他們試圖用一些不同的語法熱交換 Java 語法時，他們面臨哪些挑戰(zhàn)？James：有點取決于你想要做什么。Java 虛擬機的特點之一是它內置了許多安全性和可靠性的概念。它們主要與內存模型的完整性有關。指針之類的。所以你不能偽造一個指針。如果你看看像 C 這樣的語言，如果你沒有偽造的能力，你就不能做 C。有一些虛擬機沒有嚴格的安全模型。在 JVM 之類的東西上，如果您嘗試實現(xiàn) C - 有些人已經這樣做了，盡管這很奇怪 - 如果您有一個嚴格安全的虛擬機，那么有些地方您就不能去。但是有些人構建的虛擬機并不嚴格安全，沒有內存分配模型。所以這取決于你愿意去哪里。當然，在 Java 誕生之初，我的個人規(guī)則之一是：我不想調試另一個該死的內存損壞錯誤。我已經浪費了太多時間在需要數天時間在內存損壞錯誤上。這只是一個循環(huán)中的一個錯誤，恰好從數組末尾移出一個條目，直到數百萬條指令之后您才會發(fā)現(xiàn)。而且我真的，真的很討厭追逐內存損壞錯誤。所以這取決于你對什么感到舒服。有些人，你知道的，認為花時間這樣做非常有男子氣概。但是也有人喜歡使用 vi，它在 70 年代是出色的編輯器，在 80 年代是出色的編輯器……加油，伙計們！James：內存安全模型確實是核心，它提供了一些東西，但限制了一些東西。非常感謝你，詹姆斯！很高興與您進行這次談話，我希望在經歷了這場僵尸啟示錄之后，我們可以在某個線下會議上見面。謝謝你，祝你有美好的一天！
下載文檔
