作者 | 王啟隆
責編 | 唐小引
出品丨AI 科技大本營（ID：rgznai100）
已過花甲之年的 Cay Horstmann 是 Java 經典著作【Java 核心技術】和【Java 核心技術：速學版】的作者，幫助了無數 Java 開發者啟蒙進階。截止到今天，Cay 在軟體領域已經工作了 40 多年，但他本人與 Java 的結緣方式卻不比尋常，始於 Java 萌芽時。
1995 年，Cay 的朋友 Gary Cornell 給他打了個電話：「我們要寫一本關於 Java 的書。」
那時，Java 還未正式釋出。 所以 Cay 回答他： 「除了媒體上的報道，我對 Java 一無所知。 」 他知道 Gary 的情況也一樣，「而且，你對 Java 也一無所知。 」
Gary 卻說：「但我已經拿到了一份出版合約。」
原來， James Gosling （ Java 之父 ）不願透過 Sun Microsystems Press 這家出版社發行書籍，雙方陷入了扯皮。Gary 得知此訊息後，便告知出版社的編輯，他恰好知道合適的人選來執筆此書。
於是，Cay 和 Gary 在那個聖誕節期間瘋狂地學習 Java，他們有了三個月的時間來完成這部著作。幸運的是，Cay 當時還沒從教授崗位下來，能依據研究授權獲取到 Java 的原始碼 —— 這件事遠早於開源時代，當時的 Java 源碼僅向研究者開放。 正因為他們能接觸到原始源碼，清楚 Java 的實際功能，才發現最初版本的 Java 並不完全符合官方文件所述，甚至存在許多漏洞。
他們出版了首部真實揭示 JDK 運作機制的書籍：【Java 核心技術】（Core Java），隨即大獲成功。 隨著 Java 突飛猛進地發展，兩人不斷更新內容，一直出到了現在的第 13 版。針對已經有基礎的程式設計師，Cay 還單獨開設了 【Java 核心技術：速學版】（Core Java for the Impatient） 系列，讓有其他程式語言經驗的開發者可以迅速上手 Java 套用開發，中文版本的【 速學 版 】在 2024 年剛剛出版，更新至 Java 17。
Cay 的職業生涯並不是一直都在寫書。 他曾在聖荷西州立大學教授電腦科學將近 三十年 ，前段時間他教完了最後一堂課，並決定離開學校，將生活的重心轉移到寫書上。
其間，又發生了一個與 Java 相關的插曲：出版社為了節省成本，將 Cay 編寫的書籍出版工作外包給了海外的一個團隊，但對方未能勝任。結果，他不得不自學排版技術，用 Java 和 Scala 編寫了一些輔助排版工作的程式來自動化這一過程。他說，自己未來的目標便是 將更多的互動元素融入到現在已經完全電子化的書籍中 。
正如他在社交媒體 上的簽名：在我大量的業余時間裏，我寫書並為初學者和專業程式設計師開發線上課程。
Cay 對時代的變化適應得很快，但他對 AI 的態度非常冷靜。作為一名 30 年的 Java 開發者、一位 2005 年的 「 Java Champion 」，他甚至覺得 AI 會讓自己開發的速度變慢。
他支持並使用這些所謂幫助開發者工作的「效率工具」，比如 Copliot；但 他不相信 AGI（通用人工智慧），至少不相信現在的人工智慧可以發展成 AGI 。他也不認為 通用人工智慧會像人們設想的那樣，普及到眾多套用場景中，並斷言：
AI 熱會在幾年內逐漸降溫。
比如，未來的編譯器內不會整合 AI，且任何需要精確計算最優解的任務（ 這事實上是很常見的需求 ）也不會采用 AI 技術。
Cay 不認為有人會願意乘坐由 AI 操控的飛機，因為它不夠安全可靠，且這種關乎人命的事情，我們至少希望了解人工智慧決策背後的邏輯，而當前的 AI 系統「黑盒」尚無法提供這種透明度。
AI 擅長生成供人類後續審查的內容，但在直接操作和執行方面並不突出。
盡管有人試圖讓我們相信並非如此，但 現有的技術距離實作通用智慧還相去甚遠。
我認為 AI 雖有其趣味所在，但它並未帶來根本性的範式轉變。
Cay 的早晨通常從編程開始，他 完全不介意早起投入到計畫工作中，編寫程式碼，學習新知識。學習是他生活中的一大組成部份。 【新程式設計師】和 Cay 相約 在德國時間的九點進行采訪，於是他起床後先是開啟電腦敲程式碼。到點之後，妻子開啟房門提醒：「你不是早上九點和人有約嗎？」 他這才停下了手中的活兒，進入到線上對話當中。
在我們這個領域，有一點頗為獨特，那就是你必須每周抽出時間來學習新東西。否則，你很快就會落伍。因此，我手頭有幾個小計畫，我透過它們來促使自己學習最新的技術。
除了學習，Cay 還熱愛旅行、徒步和騎自由車，享受與家人的共處時光，同時他也是一位閱讀愛好者。他的旅行愛好常能與職業相結合，因為他頻繁受到各地邀請進行演講。上周，他剛從保加利亞回到德國，那是他從未去過的地方。他 借此機會存取新地方、結識新朋友，增添 生活的樂趣與色彩。
Cay 對於電腦的熱愛源於青少年時期。那是德國一個寧靜小鎮的高中裏，學校本身並無特別之處，唯獨有一位特立獨行的物理老師。這位老師雖然不熱衷於日常授課，卻對發掘並培養學生的創新思維充滿激情。 在二戰結束後的某個時刻（ 遠早於 Cay 入校之前 ），老師便發起了一項別開生面的 課外活動 ：利用戰爭遺留的軍用物資，讓學生們動手將之變廢為寶，制作成那個年代頗受歡迎的收音機、電唱機等電子裝置。
待到 Cay 入學之後，這項課外活動早已成為了歷史悠久的課堂傳統，當時的世界也正值數位革命的起步階段。Cay 在課堂上親眼見證一個比他大兩歲的孩子用剩余的繼電器造了一台電腦。
就像二戰時德國人造的繼電器電腦一樣，那家夥把大約一千個繼電器串聯在一起，真是令人驚嘆……每當執行任務的時候，它就會發出哢噠聲，你光是聽就能分辨出它當前是在解碼指令還是執行指令，一切都讓人感到無比激動。
那時，孩子們可以購買到諸如「 與門 」、「 或門 」、「 非門 」等基本邏輯閘芯片並進行組合。 Cay 跟著班上的學長們，學習整合電 路的原理，搗鼓發明。 他後來還完成了科學計畫，那是一個 邏輯系統 —— 一個沒有采用布爾邏輯，而是包含 0、1、2 三種狀態的邏輯系統 —— 他構建了類似的裝置，並憑借該計畫在全國科學展覽會上榮獲佳績。
Cay 伴隨著這些技術成長，他的班級甚至還用 80 系列的微處理器自制了一台電腦，雖然作業系統是從別處獲取，但電腦上的所有軟體都是他們自行開發的。
高中畢業之後，他的首份工作便是 編寫組合語言程式 。高中的這段經歷事實上沒有讓 Cay 愛上 電子工程，因為在大多數同學都是電子工程師的環境中，只有他 對焊接總是很不在行，常常會燒壞電路。
那時候我明白了一件事：
對我來說，偏向理論思考的部份才是更適合的。
在安阿伯密西根大學，Cay 獲得了數學博士學位。大學畢業後，Cay 成為了一名「 連續創業者 」（ Serial Entrepreneur ），這個詞被專門用於描述那些 多次創立並經營企業，具有多次創業經歷的人。他們通常在完成一個創業計畫後，不論成功或失敗，都會繼續投身於新的創業活動中。
1997 年，互聯網泡沫的第三年。 Cay 前腳剛離開一家公司，便有一個朋友找到他： 「 我想籌集資金辦一家公司， 你想來當技術副總裁嗎？ 」
Cay 此時面臨兩個選擇：回學校當教授，或是面臨互聯網泡沫繼續創業。 他這麽說服自己： 「如果以後我的孫子們問我，「你在互聯網革命期間都做了什麽？ 」，那我當然想告訴他們，我參與其中。 」
最後，Cay 只問了問公司的職責是什麽，而朋友回答他： 「數位著作權管理。 」
這家公司叫 Preview Systems，最開始只有四個人。 Cay 入職期間，還成功招聘過不少非常優秀 的中國程式設計師，其中一位只靠一封電子信件中的一句話說服了 Cay 招聘他：「我對 Windows PE 檔格式的每一個字節都了如指掌。」 這個程式設計師 迅速成為了 公司技術進步的催化劑，而 Cay 又接連吸納了此人的幾位同僚加入， 團隊不斷壯大。
2001 年左右，互聯網泡沫全速消退，公司在這一年被收購，這段歷史也隨著 Pr eview Systems 這個名字一起消失，但創業的經驗被 Cay 視為珍寶。
聯想到當今正在進行的「AI 泡沫」，各界人士為了不錯過所謂的「下一個大事件」，紛紛湧入 AI 領域，推高了初創企業的估值，Cay 也為所有躊躇不定的創業者給出了建議：
我能完全理解年輕人現在的感受：如果你們也有同樣的機會在初創公司或某個企業中從事 AI 相關的工作，那我會建議你放手去搏。這是激動人心的時刻，身處其中總是充滿樂趣。
但要現實一點 —— 互聯網泡沫並非對每個人都有好結局，很多人損失慘重。
我在互聯網泡沫期間並沒有致富，但我學到了很多。所以要明白，每一項新技術發展都有其積極面和被過度炒作的一面。但我認為，能親身參與其中並近距離觀察，總比袖手旁觀要好。
我一直喜歡矽谷的一點是，即使你參與的計畫最終沒有成功，也沒關系。沒有人會因你的創業失敗而放棄僱用你。相反，很多人會認為這是件好事，因為他們現在有機會雇用一個經歷過失敗的人，且那次失敗是由別人買單的。
Java 不會是那個最需要創新的語言
我不認為通用智慧會像人們普遍設想的那樣普及到眾多場景中。
【新程式設計師】：你對 Copilot 的第一印象是什麽？使用後的第一感受怎麽樣？
Cay Horstmann： 說實話，我還沒有到每天都用它的地步。我只在涉及一些我不太熟悉的領域時會去用 Copilot。
我已經做了 30 年的 Java 編程，所以 Copilot 反而會讓我的速度慢下來 ；但當我用 Python 做一些事情時，例如一些我不太熟悉的 Python 庫，我才會接受建議並考慮它。
我認為 Copilot 最終會像今天的自動補全功能一樣，成為開發者的日常工具之一，它們能夠輔助工作而不取代人類。所以，它至少還算是一個偉大的工具。
另外我也會用 Copilot 寫提案或是類似的文件，很多開發者都頭疼這些任務。雖然我是一個作家，我知道如何寫作，但我仍然覺得動筆很困難。AI 能提供一個初步的框架或思路啟發，盡管初稿品質可能不高，但它能打破僵局讓我繼續寫下去。
總之，我完全支持這些 AI 工具，只是人們現在過於傾向高估它們的能力。作為工程師，我們很清楚如何開發和評估這樣的東西。你們可以去嘗試、練習、了解這些 AI 工具的能力，但不要過度興奮，認為世界明天會發生翻天覆地的變化。
【新程式設計師】：AI 時代的程式設計師要做出什麽改變嗎？
Cay Horstmann： 如今大家的註意力都被人工智慧所吸引，所以資源事實上被稀釋了。我的觀點是， 未來幾年內人工智慧的熱潮將會逐漸降溫 。 因此，我並不建議完全只專註於人工智慧。 這是一個有趣的領域，但我認為未來並不像某些人想象的那樣完全取決於人工智慧， 傳統的編程軟體開發、軟體架構將繼續保持其重要性。
【新程式設計師】：很多人都擔心自己會被 AI 淘汰。
Cay Horstmann： 很多人都問過我這個問題。我認為答案顯然是「不」，因為 AI 工具獨立生成的內容建議很多都是沒法直接采用的。它們頂多是參考建議罷了。
退一步講，以一種或許帶點美國視角的方式來說，大約二十年前我們見證了 外包業務 的興起。彼時，眾人擔憂美國程式設計師是否會因外包而被淘汰，結果顯而易見，編程在美國仍是一份極佳的職業。而且，外包團隊展現出的能力事實上遠超當前人工智慧所能達到的水平。他們通常聰慧、有才且充滿動力，能實際編寫出高效程式碼，這是任何 AI 助手難以企及的。因此，我們不能僅憑 AI 助手的存在就斷言程式設計師將被淘汰，畢竟之前這波智慧而充滿動力的人群浪潮也未曾讓程式設計師這一職業消失。
人工智慧並不意味著人類失業了，反倒是以往需要死記硬背或迅速尋找的資訊（ 比如基礎演算法 ）現在可以依賴自動補全功能了。這是件完 全的好事，提升了工作效率的同時釋放思維，讓我們 去學習迄今為止我們沒有時間學習的其他事物。
【新程式設計師】：Kent Beck 曾在不情願地嘗試了 Copilot 之後驚奇地發現：AI 雖然將他 90% 的編程技能全部取代，但也把剩下的 10% 技能放大了一百乃至一千倍。你同意他的看法嗎？
Cay Horstmann： 一千倍可能有點誇張，但確實是對的。這種情況在過去的許多年裏隨著技術的發展一直存在。我剛開始工作時，是用打字機寫東西。後來出現了文書處理軟體，我甚至自己編寫了一個文書處理軟體並成功出售獲利。
技術的進步讓我們能夠專註於如何增加更多價值的事務上。這一點在人工智慧上無疑是正確的。 所以我認為這個觀點基本上是完全正確的。
【新程式設計師】：你經歷過最大的技術變遷或範式轉換是什麽？是當前的人工智慧革命嗎？
Cay Horstmann： 事實上，最重要的轉變 —— 這一轉變在今天看來或許並不引人註目 —— 是 Java 中的 垃圾回收 技術。
在此之前的情況非常糟糕，因為當你使用 C++ 時，大量開發時間都會耗費在追蹤和修正指標錯誤上。 而轉投 Java 後，這一問題就徹底消失了。 僅憑一門語言解決了一個既繁瑣又不愉快的問題，就極大提升了生產力。 如今，這一切甚至已經變得理所當然。
除此之外， 記憶體管理 也曾是個大難題，現在已基本消失。 我上次處理記憶體問題時，還是在用 Objective C 進行某個計畫，那同樣令人頭疼。這是一個重要的技術轉型。
還有一個我能想到的重大變革是 雲端運算 。如今，如果我需要資料庫，就可以直接在雲端獲取，雖然需要支付一定費用，但我無需聘請資料庫開發人員，也無需配備資料庫管理員等。所以，我認為雲端運算的影響是巨大的。
至於 AI 將如何影響開發者，我尚不確定。 AI 確實在某些領域表現出色，但也有很多領域與 AI 無關。 因此， 我不認為通用智慧會像人們普遍設想的那樣普及到眾多場景中 。 例如，你的編譯器不太可能內建 AI 功能； 任何需要精確計算最優解的任務，都不會簡單地依賴 AI 來完成 —— 這是非常普遍的需求，卻不是 AI 所擅長的。 我也不認為你會願意讓飛機依靠 AI 來駕駛，這不僅是安全性問題，而是 涉及人身安全的情況下，我們總希望理解它的答案是如何得出的。
AI 擅長生成供人類後續審查的內容，但在自主執行方面並不特別出色。 以目前的 AI 發展水平來看，我難以預見其在這方面能有多少突破。 我不是說永遠不可能， 但至少現在 我們目前擁有的東西距離通用智慧還很遙遠 。 因此，我認為 AI 雖然很有趣，但它所帶來的東西並不構成一種根本性的範式轉變 。
【新程式設計師】：Java 該如何適應人工智慧並支持技術進步？未來或許還會出現為下一代環境而設計的程式語言，以 Java 的性質，有可能會與之競爭嗎？
Cay Horstmann： 我們可以觀察一下當前程式設計師的編程方式。他們會頻繁使用如 GitHub Copilot 之類的輔助工具，所以未來語言的設計需要適應這種趨勢。這是一個引人深思的問題，目前我覺得尚無定論，因為人工智慧還在新興階段。但顯然，這種語言設計思路具有明顯優勢。
如果我們回顧較為早期的發展，人們過去常常使用像 vi 或 Emacs 這樣的文字編輯器。而現在，一切都透過整合式開發環境（IDE）來完成。IDE 不僅透過自動補全等功能簡化了編碼過程，還使庫的探索與套用更為高效，以至於我們難以想象重返缺乏這些輔助功能的純文本編輯時代。 事實上，我認為未來每個 IDE 都將內建某種編碼輔助功能 。在今天，自動補全早已成為現代 IDE 不可或缺的一部份，VS Code 與 IntelliJ IDEA 上的使用者幾乎無法想象缺少這項功能的 IDE。所以在未來，基礎的程式碼輔助也會一樣演變為標配，甚至更新越來越好。我還不清楚這將如何具體實作，但 IDE 是一個非常適合實作這一功能的地方，因為 IDE 本來就是一直在演化的，它們會伴隨新特性的疊加，變得愈發復雜，直至催生出追求簡約的新一代 IDE。VS Code 的興起便是對此前過度復雜的 IDE 的一次反撥。我認為 這種創造性的破壞和工具的叠代將會持續發生 。
這無疑是一個精彩的問題，盡管我無法確切告訴你答案，但可以預見，未來確實會像你說的一樣，新型語言湧現並充分利用人工智慧技術。至於 Java，這是一種高度保持回溯相容性的語言，它甚至可以在未經修改的情況下執行我在 29 年前編寫的程式。所以 Java 可能不是那個需要創新的語言，因為它的強項就是回溯相容性 。這也意味著，如果我想構建一些十年後仍能工作而不需要我改變所有東西的語言，那麽我會隨時選擇 Java。
精通一門語言並快速學習其他語言
這是開發者順應時代變化的基本技巧
30 年後，Java 仍然是我最喜歡的程式語言。
【新程式設計師】：為什麽會在寫完【Java 核心技術】之後還推出「
速學版
」？
Cay Horstmann： 【Java 核心技術】這本書是 30 年前設計的經典之作，原版超過了 2000 頁，是一本很長的書。那時並非所有人都熟悉物件導向設計，它也是針對那些可能對數據結構或並行編程不太了解的初學者編寫的。並行編程在當時是一個非常新穎的概念。
隨時間推移，我逐漸意識到，許多讀者已具備其他程式語言的深厚功底，比如現在有很多學生是從 Python 開始學編程的，他們也就無需重復學習基礎內容。 此外，【Java 核心技術】力求面面俱到，詳盡介紹大多數人可能感興趣的API知識，而並非所有讀者對這種內容都有需求。
所以，如果有些開發者性子比較急（Impatient），或是已經 有了一些編程的基礎知識，並且不需要深入一些更專業的主題 ，我想應該有一種更好的方式來滿足他們。 這就是【Java 核心技術：速學版】（Java for the I mpatient ）以及整個「速學版」（ ~ for the Impatient ）系列書籍的由來。
我之前還寫過一本名為【快學 Scala】（ Scala for the Impatient ）的書，創作動機就非常類似，針對的是那些不想了解所有背景，特別是函數語言程式設計背景，只想立即使用Scala的人。我寫那本書是為了自己，因為我急於實踐 Scala。我厭倦了那些試圖強加某種編程教條的論調，只求一本能讓我直接上手的指南。
我還推出了【寫給大忙人的現代 JavaScript】（ JavaScript for the Impatient ）遵循同一理念 —— 也就是說，它也是為我自己而寫的。 當時我發現為學習者建立的所有互動式體驗都是用 JavaScript 做的，所以急著進行學習。 於是，我參考了 David Flanagan 的那本「犀牛書」（ 【JavaScript 權威指南】 ），也是 JavaScript 的經典著作。
【新程式設計師】：以後還會有其他程式語言的「
速學版
」書籍嗎？
Cay Horstmann： 可能會有。我一直在努力尋找一種全新的、令人興奮的程式語言，像 Python 現在已經變得非常流行，它有一些很好的特性，但 Python 的資料已經夠多了，所以我並不打算深入。
說實話，我對 Python 了解不多。我懂基礎，能寫指令碼，但從未真正涉足高級套用，也沒有這方面的需求。Java 對我來說已經足夠好。你知道現在中國最熱門的程式語言是什麽嗎？
【新程式設計師】： 根據 CSDN 最新的 ，是 Java（笑）。
【新程式設計師】： 你剛剛說你對 Python 了解不多，但我知道你出過一本書，叫【Python for Everyone】。
Cay Horstmann： 對，這些書的內容其實和【Java 核心技術】大相徑庭。它們是面向初學者的電腦科學入門書籍，我一共出了三本，分別是【Big Java】，【Big C++】，還有一本【Python for Everyone】，它們實際上都沒暢銷過。我原本計劃也將其打造成一本大型 Python 書籍，但未能實作。
這些書實際上並不是為了教授對應的程式語言，而是為了教授電腦科學的基礎。語言只是一種工具，所以你如果同時閱讀這三本書，會發現有很多重復的基礎知識。而【Java 核心技術】 顯然是為了教你關於 Java 語言及其平台的所有知識。
【新程式設計師】：你這麽多年的工作內容其實都和教育有關。你認為現代教育最大的變化在哪？
Cay Horstmann： 三十年前我們傳播知識的手段還是書籍，但現在人們獲取知識的渠道已經極為豐富。我最近在研究怎麽讓演算法和數據結構相關的教學不那麽晦澀，因為教學書上的演算法通常只有幾張圖表輔助說明，理解起來並不直觀。這意味著，讀者如果要想真正掌握，還需要親自動手實踐，比如在紙上演算、做練習題、嘗試自證演算法正確性、親自編碼實作，這個過程往往缺乏老師明確的指引。而且讀書自學 Java 的人有不少在現實很忙，沒法投入足夠的時間。
作為作者，我以往對此束手無策，但這個時代卻有能力做得更多。我可以 隨著讀者閱讀行程，穿插提問，引導他們動手操作 。我能夠在書裏設計互動環節，提出更有意義的問題：以二元樹章節為例，我定義了葉節點的概念後，隨即展示一個隨機生成的樹，要求讀者點選所有葉節點。這一過程僅需幾秒，但完成之後，作為作者的我便能確認，讀者已掌握了這一概念；同時，讀者自身也會意識到這一點，從而獲得更大的學習動力，更有信心地繼續探索。 學習編程，最好的方法就是動手實戰 。
我以前還在大學教授過一門大型課程，每班數百名學生，基本全都是初學者。當時的課程結構安排為每學期四次大作業，但對剛接觸編程的學生而言，他們實際上很難獨立完成如此規模的作業。因此，他們經常求助於同學，共同完成作業 —— 其實就是抄作業。所以，學習效果不是很好，聰明的學生承擔了大部份工作，其他人因為抄襲答案導致收獲甚微。到了下學期，我發現很多學生經過一學期的電腦科學學習，竟然連簡單的迴圈都不會編寫。
後來，我徹底改革了教學模式，不再布置大型作業，轉而采用大量小型任務。改良後的課程中共包含了一百多個練習，當學生們親自編寫過一百次迴圈後，第一百零一次便來得輕而易舉。 這種持續的實踐練習比假設學生自己會去學習要有效得多 。
二十年前，這種做法難以在書中實作，但如今卻成為了可能。我現在可以在書中嵌入範例程式碼，要求讀者修改迴圈、解釋迴圈功能，或是編寫類似迴圈。因此，我設想的教育方式比過去更加動態，而不是靜態地在頁面上展示材料並希望讀者會有所行動。現在真的可以讓讀者積極參與進來，讓讀者感受到進步。當讀者在閱讀後能自信地說：「我了解如何套用這個知識點了，因為我剛剛實踐過」，這樣的學習才有動力，這才是更為沈浸式、更富成效的學習方式。
因此，我強烈建議大家，如果有此類互動學習材料 —— 雖然這是一項較新的發展 —— 一定要積極尋找利用。反之，如果你沒有這樣的資源，不要只是機械地觀看視訊，而是應該主動思考，結合所學內容，動手做一些實踐性的工作。畢竟，犯錯是學習的一部份，我自己也是透過實踐中的失敗，不斷嘗試直至成功。
我最近還和出版社溝透過，詢問他們為什麽不能在【Java 核心技術】內部也實作這樣的互動學習。遺憾的是，出版社當前尚不具備這樣的技術支持。這聽起來有些匪夷所思：他們為什麽能提供基於網路的 EPUB 格式書籍，卻不能在其中融入練習環節呢？但出版社總是告訴我，他們正在研發中，預計還需一至三年。
尤其考慮到【Java 核心技術】的中文版目前仍以紙質形式出版，讓我更加期待變革的到來，並在後續版本實作更強的互動性。請對此保持期待。我們會為此建立專門的網站，讓使用者登入後即可閱讀、完成練習 —— 這其實並非難事，只是出版商尚未深入思考罷了。
【新程式設計師】：除了廣泛的教育改革，你在 Java 的教學方法上具體有過哪些調整嗎？現在的軟體開發非常多元化，是不是要在教學的時候讓學生為其他程式語言也做好準備？
Cay Horstmann： 其實很簡單，雖然 Java 語言一直在持續演進，但這種前進演化是循序漸進的，所以我們能預見到即將發生的變化，將其融入教材並非難事。我始終堅持一個原則： 假設所有的讀者都希望透過書籍學習當下最實用、最先進的知識 。因此，我會剔除過時的內容，用最新的技術和最佳實踐取而代之，以滿足讀者的學習需求。畢竟，這是讀者對書籍的基本期待。
我不傾向於在書裏追溯 Java 歷史沿革，詳述從前是怎樣的，之後又如何變遷，因為現代讀者往往不太關註這些背景，他們更關心當前的最佳實踐是什麽。我可能會在註釋中這麽寫：「某些舊技術可能在某些老舊資料中仍可見，但建議忽略這些，采用更新的方法」，然後再寫行字解釋我這麽做的理由。
現在的另一個不同之處在於，讀者只想學習他們需要的內容。因此，我正在努力調整書籍的結構，讓線上閱讀的讀者不必從頭讀起，可以隨時從感興趣的部份開始閱讀。這意味著我會減少章節間的相互依賴，並為未閱讀前面內容的讀者提供必要的回顧連結。畢竟，這也是我自己在需要學習新知識時的常用做法 —— 透過搜尋引擎尋找資訊，或是存取如 O'Reilly 這樣的網站，瀏覽多家出版社的書籍資源，迅速切入主題，快速理解我想要的知識。
早先的幾本書中，我曾設計了一條貫穿多章節的長案例，但現在我已經不再采用這種方法了。我認為，對於那些希望從任意章節開始閱讀的讀者來說，這是一種不便。再說，未來的教學趨勢在於互動性。技術日新月異，可能突然間就需要轉向移動開發，或面臨全新的程式語言和技術棧。所以從教學角度看，借用我在大學教授的經驗，大學的責任並非教授你多種語言，而是 教會你如何學習 ，因為 作為開發者，終身學習將成為常態 。因此，我的目標是最高效地培養這種能力。實作這一目標的方法是，確保你能精通至少一種語言。
過去，Java 常作為通用的教學語言，而現在 Python 或許會取而代之。不論何種語言，我認為，經過四年的大學教育，學生應當至少深入掌握一種語言，對這門語言的語法、構建系統、工具鏈了如指掌，並透過這一過程快速掌握其他語言。
我常在大學課程（如軟體工程課）中設定一種課題，就是讓學生將做到一半的計畫采用另一種語言完成。這不僅是計畫的一部份，也是適應新語言、新工具的一個過程。我會明確這一學習路徑：如何從已知過渡到未知，這也是大學應當傳授的技能之一 —— 學習如何學習 。因此，我還特意引入了一些極具挑戰性的語言教學，如 Scheme、Haskell，這些語言具有思維拓展性，不同於學生熟悉的常規語言。我甚至會使用 Scala，但僅限於其函數語言程式設計部份，禁止變量的修改，這種方式能讓學生們學會適應完全不同的編程範式。在我看來，教育體系的職責正在於此： 精深掌握一項技能，同時掌握快速學習其他技能的訣竅 。
【新程式設計師】：時代一直在變化，但也有很多戀舊的人。我記得 James Gosling 曾經還特別呼籲過希望大家棄用 JDK 8。
Cay Horstmann： 我看過最新的數據，JDK 8 已經是過往的歷史了。
曾經，從 JDK 8 過渡的難點在於模組系統和 JDK 9 的引入。然而，一旦使用者從 8 跨越至 9 之後的任意版本，無論是 11 還是 17，繼續升級到最新 JDK 就顯得輕松許多。因此，任何從 8 升級到 11 的使用者，實質上已經踏上了一條平滑的升級路徑，他們現在可以直接過渡到 17 或 21 版，且一切將順暢執行。
這與以往情形相似：更換 JDK 版本或許需要花些時間處理細小問題，隨後即可順利執行。8 升至 9 之所以引起過爭議，是因為當時 引入了 模組化 ，它導致了許多相容性問題，使得人們質疑升級的必要性。然而，時至今日，這些難題早就被克服了。促使開發者升級 JDK 的明確理由有兩個：
1. 安全性 ，執行如此陳舊且含有大量已知安全漏洞的軟體不是一件很理智的行為，更不必提那些潛在未知的風險；
2. 授權成本考量 ，若想沿用 JDK 8，必須承擔高昂費用，因為合法的途徑是采用 Oracle JDK，且年費逐年攀升。因此，若你仍在使用 JDK 8，不妨仔細計算一下成本。實際上，短期內從 8 直接升級到 17 是完全可行的，我甚至建議開發者總是跟進最新的長期支持版本。比方說目前而言，你應該切換到 21 版。我預計 JDK 8 的遺留問題不會持續太久，堅守舊版實在沒什麽必要。
【新程式設計師】：有些開發者是因為公司的需求導致必須留在 Java 8，但無論如何，「新版任你發，我用 Java 8」 已經成為一個梗了，你怎麽看待這種現象？
Cay Horstmann： 坦白講，我無法理解有人能理直氣壯地聲稱 Java 8 在某些方面優於新版本。 我曾經維護過一個基於 8 版的程式碼庫，每當涉及檔操作時都令我非常頭疼，因為 自 8 版之後，Java 在檔處理方面已經有了許多微小卻重要的改進。
從程式設計師的角度出發，新版本也總是更加優越。 Java 本身並未退步，它只是不斷增添了可選的新特性，而與此同時，bug 數量也在不斷減少。 因此，我看不到堅守舊版本的任何益處 。 每個新版本總有某些方面表現更佳，比如字元處理隨著 Unicode 標準的進步也在演進。 如果使用的是支持舊 Unicode 版本，就會遇到局限。
所以你提的這個問題我也曾思考過： 是否應該編寫一本指南，幫助使用者直接從 8 版無縫過渡到最新版？ 因為有些人可能只是單純對升級感到不安或缺乏信心。 也有可能是【Java 核心技術】這類書籍預設讀者對 Java 並不熟悉，因此缺乏直接針對從 8 到最新版快速過渡的指導資料。又 或許是需要一個新的官方計畫，專門引導使用者從 8 版遷移，並提供具體步驟。
總之，對於那些仍停留在 8 版的開發者，我強烈建議閱讀線上的【Java 核心技術】內容，我在裏面介紹了所有的 Java 最新特性，裏面有一些很不錯的小更新
。
比如模式匹配（
Pattern matching
），我現在覺得它極為實用。
起初我還覺得它有些復雜，但這個功能如今變得日益成熟了。
我還接觸了不少全新的正規表式特性，正在被廣泛套用。
【新程式設計師】：隨著谷歌（Google）宣布 Kotlin 成為 Android 開發的首選語言之後，Java 在行動應用開發領域的統治地位有何影響？你對 Java 開發者轉向 Kotlin 有何看法？
Cay Horstmann： 這個問題問得 非常好。 曾經有一段時間，Java 的發展確實很緩慢，然後 Scala、Kotlin、Clojure 等語言出現了，它們都是基於 JVM （Java 虛擬機器）開發的。JVM 是個出色的技術，但這些後起之秀發展的更快，其中 Scala 尤為如此。如今 Java 擁有了許多讓 Scala 作為日常程式語言更友好的特性，例如引入了 lambda 運算式和流處理。因此，轉向新語言的需求沒有那麽迫切了。但是， Scala 在型別系統上的探索確實激動人心，這是我在 Java 或 Kotlin 中永遠無法體驗到的 。
至於 Kotlin，通常情況下轉向 Kotlin 的理由並不那麽充分，盡管它更加人性化、更加一致，但也帶來了足夠的差異性。比如在 虛擬執行緒 的處理上，Kotlin 為了保持競爭力，在未來可能需要反向而行；相比之下，Java 則采取了更為長遠的策略，現今似乎找到了更佳的解決方案，堅守 Java 的開發者也因此得到了回饋。Brian Goetz（Oracle 架構師）就曾經說過， Java 享有「後發制人」的優勢，能夠借鑒並最佳化已被驗證有效的實踐 。
但你說得對 —— 移動開發領域的情況確實不太一樣了。雖然使用 Java 進行移動開發仍是可行之選，但新興資料和教程幾乎都以 Kotlin 為主。如此看來，如果有人想投身 Android 開發，Kotlin 幾乎是必經之路，就像 iOS 開發繞不開 Swift 一樣。
個人而言， 我對層出不窮的專用程式語言持保留態度，它們相較於通用語言僅實作了細微改進 。現實便是如此。我認為，精通一門語言，並在必要時能快速掌握並運用一門新語言，是一種必要的能力。即便我個人不涉足 Android 開發，但如果需要，我也會選擇 Kotlin 來完成任務。對於一位優秀的 Java 開發者來說，學習 Kotlin 並非難事。
【新程式設計師】：假設現在有個學生站在你的面前，問你 「我學習 Java 的理由是什麽？」，你會怎麽回答他？
Cay Horstmann： 我的第一個建議是，你應該 跟從你的社群 。
如果問我這個問題的人在大學裏，而大學使用 C++，那就學習 C++，因為那是周圍其他人都在學習的語言。而且他們很可 能已經根據這一點最佳化了整個課程結構。
但如果 提問者 是自學者，那我實際上會向他推薦 Java 。這樣做的原因有三點：一、關於 Java 的 優秀資料很多 ；二、Java 是一種非常好的語言 ；三、Java 是 編譯時型別檢查 的，而對於學習者來說，我認為能夠盡早看到自己所犯的錯誤是非常有用的。
當然，Python 的優勢在於，關於它的優質學習資源也非常豐富，如果 提問者 想接觸數據科學或人工智慧這類酷炫領域，Python 相比 Java 會稍微容易一些。但 Python 的缺點是，你在編碼過程中一旦出錯，往往是在程式崩潰時才發現那個錯誤，然後你將面臨一段痛苦的偵錯時光。而在 Java 中，「一次編譯、隨處執行」（Write once, compile anywhere）。
【新程式設計師】：現在也有不少人是透過開源社群的計畫學習的，許多開發者可以在同一個開源計畫裏共同進步，積累經驗。
Cay Horstmann：
沒錯，說得很好。我認為參與某些開源計畫是拓寬視野和展示自己能力的絕佳方式。
很多時候，你其實沒法在申請新工作的時候真正展示你在舊工作中編寫的程式碼，但你可以展示你在開源計畫中的貢獻
。
我的建議是，如果開發者對某個計畫感興趣，那就直接參與進去，弄清楚計畫營運者的需求是什麽 —— 這通常相當明顯，因為這些討論往往已經是公開的。然後，就可以考慮自己能貢獻什麽。一般可以從簡單的 Debug 開始，以便贏得社群的信任。
開源這種美妙的事情在 40 年前是不存在的，它極大地改變了編程的方式，讓每個人都有參與的機會。如今全世界有那麽多計畫迫切需要額外的幫助，甚至 Java 也發生了翻天覆地的變化。Java 剛起步的時候還沒有開源，現在一切都公開了，鼓勵大家參與討論和開發。可能在實作層面不會期望新手為 Java 這樣極其復雜的計畫做出貢獻，但它確實非常開放，我認為這對人們參與其中至關重要。
除了參與開源計畫，還有人可能想啟動自己的開源計畫，接下來就需要一步步構建社群、尋找貢獻者。事實上，如果真的有人正在看這篇采訪，並且想做點開源計畫 —— 可以直接來找我的開源計畫。我最近在做一個匿名且對作者友好的自動閱卷系統，特別適合用於簡單編程作業的自動評判。
Cay 的 GitHub 主頁： https://github.com/cayhorstmann
【新程式設計師】：聽起來很可靠。你參與了這麽多年的計畫，有經歷過哪些刻骨銘心的失敗嗎？
Cay Horstmann： 我經歷過的最大挫敗在很多年以前，我的公司在嘗試將業務從 DOS 系統遷移至 Windows 系統時遭遇失敗。這聽起來挺荒謬的。根本原因在於，我們努力實作的功能無法借助 Windows 的公共 API 完成。
我們當時本應該與其他面臨類似困境的企業攜手合作，因為成功轉型的那些公司都是對 Windows 進行了逆向工程。但問題實質上出在內部的溝通不暢，以及我們或許過於自信，認為既然以往能成功應對其他挑戰，這次也必然不在話下。
有時我們確實會遇到這樣的狀況： 計畫設定的目標超出了現有工具的能力範圍 。
除此之外，我還想到了另一件事。我們曾在一個計畫中急於成為 Java EE（Java 平台企業版）的先行使用者，而實際上，我們的計畫根本不需要Java EE旨在解決的那些問題。結果，我們不僅面對著一個尚不成熟的計畫，還采用了一項並不完全適配計畫需求的技術。我後來還目睹過一些數據量並不龐大的團隊犯了和我一樣的錯誤，他們選用 MongoDB 而非更符合需求、更為現代化的 SQL 資料庫。
所以， 選擇錯誤的技術路徑並因此陷入困難，其實是很常見的一件事 。關鍵在於事後要自省：什麽才是最合適的技術？我們該如何恰當地運用它？
優秀程式設計師的標準過了 50 年也沒改變過
我見證過的技術興衰比許多人學過的技術還要多。
【新程式設計師】：你的第一門程式語言是什麽？
Cay Horstmann： 我的第一門程式語言比 Java 早了大約 20 年。那個年代我們自己組裝電腦，所以別無選擇，只能用組合語言編程。
我的第一門高級語言要麽是 ALGOL，要麽是 Fortran，我也記不清了。上大學後，我們從 Pascal 開始學起。Fortran 並不有趣，但 ALGOL 和 Pascal 都是結構嚴謹的語言，我認為它們很適合編程初學者。
【新程式設計師】：我記得那個年代有很多 COBOL 程式設計師。
Cay Horstmann： 對，在我很年輕的時候，COBOL 一直是個不錯的職業方向，但我從未對其產生興趣，所以也沒去學。
【新程式設計師】：學習一門新程式語言時應該保持什麽樣的心態？
Cay Horstmann： 讓我舉個例子 - 如果我要學習 Rust，我會先自問 「 Rust 的獨特之處在哪裏？ 為什麽人們要創造這門新語言？」 畢竟，引入數百種語言是一種很大的成本，所以一定有發明新語言的原因。我會深入探索新語言的特性和不同之處，找出它們獨特的理由。
當然，我們不能簡單地說「更好」，比如 Rust 並不是「更好」的語言，而是它試圖最佳化某些方面，比如記憶體管理 —— 編譯器會嚴格監控記憶體使用情況，使得編程高效而不必依賴垃圾回收。因此，我會集中精力學習這一點。
此外，我還會透過構想一個計畫來學習，這個計畫必須凸顯這種特性的重要性，而放在 Rust 這個例子上那就是一個需要大量記憶體分配的計畫。在學習過程中，我會嘗試構建一個小套用，從而明確自己哪些地方不懂，然後逐一攻克。關鍵在於，我將專註於那些使其與眾不同的特性。
當我初次接觸 Scala 時，就是采取了這種方法。我當時並不關心它與其他語言的相似之處，因為那並不吸引人。我好奇的是 Scala 的獨特之處，比如型別系統。我會努力理解那些在 Java 中難以實作，但在 Scala 中得以施展的功能，聯集中精力研究。
【新程式設計師】：該怎麽判斷自己是否精通了一門程式語言？
Cay Horstmann： 問題在於，我們真的需要對精通每一門語言嗎？掌握一門非常熟悉的語言是好事，它能為你提供一個基準。但如今，我們不得不面對多種程式語言。因此，我不確定是否有必要把每門語言都學得極其透徹。
我追求的是在這些語言上的熟練運用，了解每種語言中的常用習慣用法。同時，我也想了解每門語言的獨特之處。即便一開始不能掌握所有細節也沒關系，隨著實踐的深入，自然會逐步掌握。事實是，如果不實踐，就很難達到 100% 的掌握程度。因此，我建議先快速提高生產力，同時學習相關的工具，不要在特定生態環境下的工具使用上感到困擾。
我建議，首先允許自己表現得「笨拙」，但至少能動手做事，意識到自己渴望提升，然後逐步達到熟練。 最終隨著時間的積累，你會成為專家。
【新程式設計師】：你為什麽會讀數學博士，而不是電腦科學？
Cay Horstmann： 我曾以為電腦科學只會是我的業余愛好。 我大學主修數學，同時一直堅持學習電腦科學，因為我擔心在數學領域最終會找不到工作 —— 我最後也確實沒能在數學領域找到工作，所以電腦科學作 為我的備選發揮了作用。
但是，我在大學期間一直都有電腦科學的兼職工作。 我做過各種各樣的編程計畫。 在研究生院時，我擁有著一家軟體公司，銷售我為數學排版而編寫的軟體。 那實際上相當成功。 後來我獲得了數學博士學位，但就業市場並不理想，於是我得到了一份教授電腦科學的工作機會。
【新程式設計師】：學習數學對成為一名程式設計師是必要的嗎？
Cay Horstmann： 至少不會有壞處。
有些人會說，「成為程式設計師必須精通各類數學理論」。我對此的看法是，雖然了解離散數學是有益的，但是在 2024 年掌握微積分知識並不是成為一名優秀程式設計師的核心要求。
所以， 我建議如果有人想學習數學，絕對應該學習離散數學，尤其是要學會證明方法 。能夠進行證明就如同能夠編寫程式一樣重要，但遺憾的是，市面上缺乏高效指導如何正確進行證明的資源。相比之下，你可以在很多線上平台學習編程，所以年輕人很容易學會編程，卻沒法透過同樣簡單的方式自學掌握數學精髓。
現在也有可汗學院這樣的平台，他們能教會你運用公式，但這僅能觸及到數學的皮毛。所以我覺得，如果能填補這一塊兒的空白 ，無疑是一大進步。另一方面，如果一個人想學習編程，也沒必要因為不會數學而感到自責。你可以先學習基礎編程來培養一些直覺，然後再深入學習離散數學的時候就會來得更容易，因為你清楚你想用它來做什麽。
【新程式設計師】：如果讓你現在站在 CEO 的角度思考，你今年會招聘什麽樣的程式設計師？現代程式設計師應該具備哪些品質？
Cay Horstmann： 這真是一個很好的問題。
在大型電腦時代，有一本編程書籍叫【人月神話】，裏面提出的幾乎所有建議在今天依然具有指導意義，比如「向計畫增派人力往往會導致延期」或是「第二個系統是程式設計師所實踐的最危險的系統」。所以我覺得，優秀程式設計師的標準其實一直沒改變過。
當然，優秀的程式設計師還需要理解編程的基礎知識。我認為，盡可能多地吸收關於數據結構和演算法知識，並使自己能夠巧妙地 理解、 修改和發明新演算法 ，仍然是非常有價值的。事實上， 有很多網站可以讓你進行這樣的學習。 例如，去年為了好玩，我參加了一個名為 Advent of Code 的網站，每天都可以練習一些演算法 。
此外，優秀的程式設計師還需要了解一些軟體工程的知識，而實踐是最好的學習方式。 如果能夠早期參與 團隊合作 （ 尤其是那些註重品質的團隊 ），體驗開發流程，那將是非常寶貴的經驗。 但遺憾的是，我們經常看到一些團隊只是想快速推出產品，然後各自散去，沒有人對自己的決策負責。 這可能不是學習成為一名優秀的軟體工程師的最佳環境。 如果有機會加入一個深思熟慮的團隊，構建出能夠持續 10 年、20 年仍然存在的產品，那將會好得多。
【新程式設計師】：新時代的程式設計師還需要培養哪些非編程技能？
Cay Horstmann： 掌握一些商業技能總是更好的。我在開公司的時候，非常希望自己的開發人員對業務有一些了解。我會讓 CFO 每月開一次會議，我們會共同檢視公司的財務狀況。我的意思就是， 無論你在一家多小的公司，最好也要了解你公司的財務狀況。 如此一來，你會成為一個更有用的員工，同時可以弄清楚是什麽讓公司盈利並支付你的薪資。
我總是會帶一些工程師去參加銷售會議。因為工程師們如果獨自工作，不太了解銷售人員面臨的情況 ，更不知道客戶需要什麽。很多時候，客戶在銷售 會議 中提出的需求非常簡單，可能只需我們幾天就能完成。從工程角度看，工程師們對此常常感到失望，他們會說：「這確實很簡單。」 然而，當我們在短時間內精準滿足客戶需求時，銷售人員自然十分高興。 此外，有些敏捷開發的公司試圖透過始終讓客戶在現場來實作這一點，這也很有效。
我十分鼓勵每一位工程師嘗試去了解他們正在開發的產品的經濟價值
，
以及客戶實際想要什麽
（
而不是他們自
認為客戶想要什麽
）。
很多客戶事實上也不知道自己的需求，所以你必須保持持續的溝通。
我們必須確保沒人在做純理論的工作，而是都做點實事。為了 做到這點，我覺得可以考慮去參加一些大學的基礎商業課程。但如果你已經在一家小公司裏了，那向你的財務學習就行。
【新程式設計師】：開發者社群其實有一種說法：「程式設計師到了 35 歲，要麽轉管理，要麽退休。」
Cay Horstmann： 工程師轉型為管理層的現象確實十分普遍。這種轉變可能順利也可能不順利，因為這實際上取決於新管理者是否有興趣和背景。因此，我認為人們需要認真對待這種轉變，並問問自己，「我 是否喜歡管理？ 」 我就 當過幾年的經理，但後面我發現自己實在不喜歡這份工作，所以又回歸到了開發領域。
事實上，成為一名優秀的管理者完全不簡單，你需要投入大量時間和精力去實踐並保持高度的積極性。但現在曾經單一的職業發展路徑已逐漸被打破，許多大型企業意識到並非所有人都適合這一模式，於是開辟了成為資深工程師的發展道路。有人熱衷於走向管理層，也有人偏好資深工程師的角色。我覺得 讓每個人都能依據個人喜好和專長選擇最適合自己的發展道路，才是最重要的。
如果真的想要成為優秀的管理者，那我覺得有一個好的鍛煉途徑是參與小型企業的營運， 小公司的管理會承擔多重角色，有機會嘗試各種不同的事務 。
【新程式設計師】：我聽說，很多開發者不論級別如何，都會與「
冒名頂替者症候群
」（Impostor syndrome）鬥爭。他們相信自己的成功是運氣因素導致，而 AI 程式碼生成的出現很可能加劇這種現象。
Cay Horstmann： 每個人都或多或少會有自我懷疑的時候，不是嗎？ 我們如今面對的技術錯綜復雜，以至於沒有人能理解一切。 有時候我們只是依靠點滴積累的理解前行，並在遇見那些更深見解的人後不禁感嘆： 「天哪，我恐怕永遠達不到他們的境界。 」
我也不喜歡一直感覺到自己很渺小，但這是我們必須要習慣的。 大家都在試圖表現出自己比實際知道的多一點點，這是生活的常態 —— 如果現在我告訴你所有我不知道的事情，人們就不會再買我的書了，（大笑）所以我不能這麽做。
我可以舉一個實際的例子。我最近為一個叫 Project Valhalla 的 OpenJDK 計畫做了個演講，我本想淺析幾行字節碼，展示值型別帶來的最佳化效果，卻意外發現自己對近二十年間組譯程式碼的演變竟如此陌生。我當時心想，「我需要在接下來三個月的時間來學習現代組譯到底是什麽樣子。」 但事實上我現在還沒去學，所以我在某種程度上就是一位 「 冒名頂替者 」 ，對吧？
世界上有太多知識等待我們去掌握了，而 我見證過的技術興衰比許多人學過的還要多。 面對最新的技術，我通常需要有所判斷：「 這項技術是否值得深入？ 」 有時答案是肯定的，有時則是否定，必須有所取舍。明確自己的興趣所在之後，才能判斷哪一種答案有益於職業發展。 沒人能知道所有的事情 ，所以 我們其實都是「 冒名頂替者 」 。
開發者正在迎接新一輪的技術浪潮變革。由 CSDN 和高端 IT 咨詢和教育平台 Boolan 聯合主辦的 2024 年度「全球軟體研發技術大會」秉承幹貨實料（案例）的內容原則，將於 7 月 4 日-5 日在北京正式舉辦。大會共設定了 12 個大會主題：大模型智慧套用開發、軟體開發智慧化、AI 與 ML 智慧運維、雲原生架構……詳情👉： http://sdcon.com.cn/
