[討論] Java語言被很多人抱怨語法繁瑣、開發效率低、體系繁雜而笨重，為什麼還有這麼強的生命力，尤其是在企業軟體領域？

問題源自知乎問答：Java語言被很多人抱怨語法繁瑣、開發效率低、體系繁雜而笨重，為什麼還有這麼強的生命力，尤其是在企業軟體領域？

做過五年對日外包，接觸過一點Java，提供一些觀察同事搞Java專案而得到的看法（本人主要在UNIX下寫C和Shell）：

語言本身：

1. Java語言是不是繁瑣呢？手頭有一本《Thinking in Java》中文第四版，數了一下正文共22章856頁。隨手翻一下，示例程式碼和講解正文大概比例在1.5 : 1這樣。沒有真正用Java幹過專案的人肯定會大為驚歎：我勒個去，這麼多知識點！此為“繁”;

2. 絕大部分搞程式設計的人，事實上，都是在使用一門語言的某個子集。該子集的形成由專案主導者發起、開發活動參與者共同決定，且相對長期穩定。每一個即將參與該專案的人肯定會先把語言學個大概（其難度參考前一條），然後再根據專案學習該語言子集，最後固化下來。不斷使用該子集固然能提升開發效率，但代價不菲，極容易就變成了專案中的一顆鏍絲釘（“專家”）;

3. 一門語言的設計肯定不會一蹴而就，一步步改良。沒記錯的話，Java誕生於1995年左右，到今天已經快滿20年。在當時那種IT環境和條件下設計出來的語言，必然存在許多妥協、限制與錯誤，既不能隨便將之抹除（可能還有很多工程依賴著），也不能隨便更正，只能通過新增新語法、新類庫來打補丁，導致語言更“繁”。舉個例子，非內建容器類庫是一個典型硬傷，再舉個例子，時間日期類沒見有多好用，也沒見有更新過，連替代品都沒見過（恕我不寫Java，的確沒見過）;

4. 類庫（框架）豐富是好事還是壞事，要看針對同一個任務能找到多少替代品。如果有三到四個，那麼肯定是好事，既不會造成單點故障，也不至於造成理解和記憶上的負擔。但是類庫太多，選擇太多，人的幸福感反而會下降，高效率也就無從談起;

5. 框架真的可以保證快速開發嗎？熟悉的話是可以的，專家程式設計嘛！但是a)熟悉之前要花非常多時間學習使用吃悶虧，b)框架只能免除掉一部分開發工作量，c)框架跟業務總是存在“不合縫”的差異，d)只不過將複雜度從開發轉移到了部署運維，e)依賴性極強;

6. IDE可以提高開發效率嗎？僅僅一部分罷了。IDE本身就是個非常複雜的東西，將之調校到符合個人開發步調的程式可能會持續很久，事實上大部分人也只是用一些常用功能罷了。而且a)基於圖形介面意味著自動化不容易（需要編寫額外外掛），b)出了問題查詢原因不易，c)依賴性極強;

7. Java本身是面向系統（機器）的，不是面向開發人員的。這種強設計保證有助於提升目標系統的可靠性，卻犧牲了開發人員的幸福感。既然設計得如此嚴謹規範，為什麼不能自動生成Java程式，而非得找一大票北大青鳥的人來寫？

工程管理：

1. Java已經發展太久，太多專案依賴於它，“還在執行中的系統就不要去改動”，所以如果要選的話，後繼專案可能還是會用Java。積累下來的專案資源不復用將是巨大的浪費，但同時也會將原有的設計錯誤、補丁、複雜度一併繼承下來（能大賺一票當然好，但更好的是可以持續賺若干票）;

2. Java的強系統可靠性保證影響了IT經理們的技術判斷和選型。有些業務第一要求是“穩”，第二要求才是“快”。如果這類業務可以分解成細小任務並行執行，沒有理由不用Java，硬體方面花錢買就是了;

3. IT經理們的技術選型影響著人才市場的供應。既然如此之多的公司和專案選擇Java，那麼對於人力資源供應異常豐富的中國而言，想借助初級IT能力就業那實在太容易了。反過來，人才供應豐富又進一步強化鞏固Java的地位，因為能替換的人力部件實在太多了，還便宜（真的，學Java除非能跟業務搭上關係，否則用個五年十年都是白搭）;

4. Java語言是“業界最佳實踐”，意味著出錯了不能責怪選它和用它的人，而得責怪整個業界捧錯了它（參考《黑客與畫家》）。

其它：

1. 創業公司還是不要上Java，做快速原型這玩意確實不合適，做穩定業務則可以認真考慮;
2. Java該革新了;
3. 如果沒有Sun和Oracle，Java又當如何？