根據(jù)你的工作需要，可能有比 Java 更好的語言，但是我還沒有看到任何能把我拉走的語言。
我記得我是從 1997 年開始使用 Java 的，就在 Java 1.1 剛剛發(fā)布不久之后。從那時起，總的來說，我非常喜歡用 Java 編程；雖然我得承認(rèn)，這些日子我經(jīng)常像在 Java 中編寫“嚴(yán)肅的代碼”一樣編寫 Groovy 腳本。
來自 FORTRAN、PL/1、Pascal 以及最后的 C 語言 背景，我發(fā)現(xiàn)了許多讓我喜歡 Java 的東西。Java 是我面向?qū)ο缶幊痰牡谝淮沃匾獙嵺`經(jīng)驗。到那時，我已經(jīng)編程了大約 20 年，而且可以說我對什么重要、什么不重要有了一些看法。
調(diào)試是一個關(guān)鍵的語言特性
我真的很討厭浪費(fèi)時間追蹤由我的代碼不小心迭代到數(shù)組末尾而導(dǎo)致的模糊錯誤，特別是在 IBM 大型機(jī)上的 FORTRAN 編程時代。另一個不時出現(xiàn)的隱晦問題是調(diào)用一個子程序時，該子程序帶有一個四字節(jié)整數(shù)參數(shù)，而預(yù)期有兩個字節(jié)；在小端架構(gòu)上，這通常是一個良性的錯誤，但在大端機(jī)器上，前兩個字節(jié)的值通常并不總是為零。
在那種批處理環(huán)境中進(jìn)行調(diào)試也非常不便，通過核心轉(zhuǎn)儲或插入打印語句進(jìn)行調(diào)試，這些語句本身會移動錯誤的位置甚至使它們消失。
所以我使用 Pascal 的早期體驗，先是在 MTS 上，然后是在 IBM OS/VS1 上使用相同的 MTS 編譯器，讓我的生活變得更加輕松。Pascal 的強(qiáng)類型和靜態(tài)類型是取得這種勝利的重要組成部分，我使用的每個 Pascal 編譯器都會在數(shù)組的邊界和范圍上插入運(yùn)行時檢查，因此錯誤可以在發(fā)生時檢測到。當(dāng)我們在 20 世紀(jì) 80 年代早期將大部分工作轉(zhuǎn)移到 Unix 系統(tǒng)時，移植 Pascal 代碼是一項簡單的任務(wù)。
適量的語法
但是對于我所喜歡的 Pascal 來說，我的代碼很冗長，而且語法似乎要比代碼還要多；例如，使用：
而不是 C 或類似語言中的：
另外，有些事情在 Pascal 中很難完成，在 C 中更容易。但是，當(dāng)我開始越來越多地使用 C 時，我發(fā)現(xiàn)自己遇到了我曾經(jīng)在 FORTRAN 中遇到的同樣類型的錯誤，例如，超出數(shù)組邊界。在原始的錯誤點(diǎn)未檢測到數(shù)組結(jié)束，而僅在程序執(zhí)行后期才會檢測到它們的不利影響。幸運(yùn)的是，我不再生活在那種批處理環(huán)境中，并且手頭有很好的調(diào)試工具。不過，C 對于我來說有點(diǎn)太靈活了。
當(dāng)我遇到 awk 時，我發(fā)現(xiàn)它與 C 相比又是另外一種樣子。那時，我的很多工作都涉及轉(zhuǎn)換字段數(shù)據(jù)并創(chuàng)建報告。我發(fā)現(xiàn)用 awk 加上其他 Unix 命令行工具，如 sort、sed、cut、join、paste、comm 等等，可以做到事情令人吃驚。從本質(zhì)上講，這些工具給了我一個像是基于文本文件的關(guān)系數(shù)據(jù)庫管理器，這種文本文件具有列式結(jié)構(gòu)，是我們很多字段數(shù)據(jù)的保存方式?；蛘撸幢悴皇沁@種格式，大部分時候也可以從關(guān)系數(shù)據(jù)庫或某種二進(jìn)制格式導(dǎo)出到列式結(jié)構(gòu)中。
awk 支持的字符串處理、正則表達(dá)式和關(guān)聯(lián)數(shù)組，以及 awk 的基本特性（它實際上是一個數(shù)據(jù)轉(zhuǎn)換管道），非常符合我的需求。當(dāng)面對二進(jìn)制數(shù)據(jù)文件、復(fù)雜的數(shù)據(jù)結(jié)構(gòu)和關(guān)鍵性能需求時，我仍然會轉(zhuǎn)回到 C；但隨著我越來越多地使用 awk，我發(fā)現(xiàn) C 的非?；A(chǔ)的字符串支持越來越令人沮喪。隨著時間的推移，更多的時候我只會在必須時才使用 C，并且在其余的時候里大量使用 awk。
Java 的抽象層級合適
然后是 Java。它看起來相當(dāng)不錯 —— 相對簡潔的語法，讓人聯(lián)想到 C，或者這種相似性至少要比 Pascal 或其他任何早期的語言更為明顯。它是強(qiáng)類型的，因此很多編程錯誤會在編譯時被捕獲。它似乎并不需要過多的面向?qū)ο蟮闹R就能起步，這是一件好事，因為我當(dāng)時對 OOP 設(shè)計模式毫不熟悉。但即使在剛剛開始，我也喜歡它的簡化繼承模型背后的思想。（Java 允許使用提供的接口進(jìn)行單繼承，以在某種程度上豐富范例。）
它似乎帶有豐富的功能庫（即“自備電池”的概念），在適當(dāng)?shù)乃缴现苯訚M足了我的需求。最后，我發(fā)現(xiàn)自己很快就會想到將數(shù)據(jù)和行為在對象中組合在一起的想法。這似乎是明確控制數(shù)據(jù)之間交互的好方法 —— 比大量的參數(shù)列表或?qū)θ肿兞康牟皇芸刂频脑L問要好得多。
從那以后，Java 在我的編程工具箱中成為了 Helvetic 軍刀。我仍然偶爾會在 awk 中編寫程序，或者使用 Linux 命令行實用程序（如 cut、sort 或 sed），因為它們顯然是解決手頭問題的直接方法。我懷疑過去 20 年我可能沒寫過 50 行的 C 語言代碼；Java 完全滿足了我的需求。
此外，Java 一直在不斷改進(jìn)。首先，它變得更加高效。并且它添加了一些非常有用的功能，例如可以用 try 來測試資源，它可以很好地清理在文件 I/O 期間冗長而有點(diǎn)混亂的錯誤處理代碼；或 lambda，它提供了聲明函數(shù)并將其作為參數(shù)傳遞的能力，而舊方法需要創(chuàng)建類或接口來“托管”這些函數(shù)；或流，它在函數(shù)中封裝了迭代行為，可以創(chuàng)建以鏈?zhǔn)胶瘮?shù)調(diào)用形式實現(xiàn)的高效數(shù)據(jù)轉(zhuǎn)換管道。
Java 越來越好
許多語言設(shè)計者研究了從根本上改善 Java 體驗的方法。對我來說，其中大部分沒有引起我的太多興趣；再次，這更多地反映了我的典型工作流程，并且（更多地）減少了這些語言帶來的功能。但其中一個演化步驟已經(jīng)成為我的編程工具中不可或缺的一部分：Groovy。當(dāng)我遇到一個小問題，需要一個簡單的解決方案時，Groovy 已經(jīng)成為了我的首選。而且，它與 Java 高度兼容。對我來說，Groovy 填補(bǔ)了 Python 為許多其他人所提供的相同用處 —— 它緊湊、DRY（不要重復(fù)自己）和具有表達(dá)性（列表和詞典有完整的語言支持）。我還使用了 Grails，它使用 Groovy 為非常高性能和有用的 Java Web 應(yīng)用程序提供簡化的 Web 框架。
Java 仍然開源嗎？
最近，對 OpenJDK 越來越多的支持進(jìn)一步提高了我對 Java 的舒適度。許多公司以各種方式支持 OpenJDK，包括 AdoptOpenJDK、Amazon 和 Red Hat。在我的一個更大、更長期的項目中，我們使用 AdoptOpenJDK 來在幾個桌面平臺上生成自定義的運(yùn)行時環(huán)境。
有沒有比 Java 更好的語言？我確信有，這取決于你的工作需要。但我一直對 Java 非常滿意，我還沒有遇到任何可能會讓我失望的東西。
【責(zé)任編輯：龐桂玉 TEL：（010）68476606】