Java之父接受Evrone專訪：您需要的軟件可靠性越高，靜態(tài)類型語言的幫助就越大

時間：2021-09-22 14:35:04

關(guān)鍵字：軟件 vr

手機看文章

掃描二維碼
隨時隨地手機看文章

[導(dǎo)讀]每一次重大更改都會在開發(fā)人員社區(qū)中引發(fā)痛苦。如果您的開發(fā)人員不多，那么破壞性更改不是大問題。而且您還必須考慮成本效益的權(quán)衡。如果你做一個突破性的改變，它會增加一些痛苦，但也會帶來一些好處。JamesGosling：“您需要的軟件可靠性越高，靜態(tài)類型語言的幫助就越大?！苯榻BJava...

每一次重大更改都會在開發(fā)人員社區(qū)中引發(fā)痛苦。如果您的開發(fā)人員不多，那么破壞性更改不是大問題。而且您還必須考慮成本效益的權(quán)衡。如果你做一個突破性的改變，它會增加一些痛苦，但也會帶來一些好處。

James Gosling：“您需要的軟件可靠性越高，靜態(tài)類型語言的幫助就越大。”

介紹

Java之父接受Evrone專訪：您需要的軟件可靠性越高，靜態(tài)類型語言的幫助就越大 — Java之父James Gosling

James Gosling，通常被稱為“Dr. Java”，是加拿大計算機科學(xué)家，最著名的是 Java 編程語言之父。他做了Java的原始設(shè)計，并實現(xiàn)了它的原始編譯器和虛擬機。近日軟件開發(fā)商evrone的技術(shù)布道師?Grigory Petrov?有機會采訪了?James，聊了不少關(guān)于他自己的人生、編程語言特別是Java的事情，我整理了一下分享出來，希望能從大佬的話語中獲取一些有價值的東西。

采訪

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