為什麼是Java？
這個系列我將詳細比較C#和Java——語言，而不關Java平台任何事情。其實這本不想強調這一點，因為語言和平台之間是沒有任何可比 性的。因為C#明顯只是一門語言，因此根據“類型推斷”，則Java也應該是“語言”類型才對。因此，我在標題中就不想加入“Language ”這樣較長的單詞了，累贅啊！
那麼，我為什麼選中Java來和C#進行比較，而不是其他語言呢？原因很多，主要有以下幾點。
首先，Java語言足夠熱門。看看TIOBE語言排行榜，Java 語言風光無限，從2002年開始幾乎全程領跑。如果我說這門受眾如此之廣的語 言一些壞話（好吧，其實是很多壞話），那響應的人一定會非常多。例如，事實上 Delphi語言在停滯發展之後，在我看來它也已經和Java 處於同一級別了。但是我不想說Delphi Sucks，因為即便這麼說，可能也不會有多大影響力——當然，可能在盛大創新院裡會正好相反。
其次，Java語言真的很糟糕。好吧我承認，它在誕生初期還是有重大意義的，它簡化了編程難度，大大提高了生產力。但是，由於它多 年來的固步自封，它已經完全跟不上如今時代的發展了。用現在的標准來衡量Java語言，會發現它是如何拖累程序員的生產力，如何成為 Java平台上最短的一塊木板。作為一次關於語言比較這種“爭議性話題”來說，如果不是有一方“全面落後”的話，那一定就會陷入雙方 粉絲的口水戰——摻雜大量主觀內容的討論，那倒真就沒有任何意義了。
還有，知道Java語言有多糟糕的人並不多。可能有不少朋友的確會感覺Java語言在使用時“挺啰嗦”的，但是由於並沒有去仔細了解其 他語言的的發展情況，對Java語言的糟糕之處也說不出個所以然來。但是大部分人，真的是大部分，他們一直認為Java是一門不錯，甚至 很優秀的語言了。為什麼？看看排行榜咯。但是我想說，排行榜只能說明它的“熱門” 程度，並不能代表Java語言有多麼優秀。正所謂“ 劣幣驅逐良幣”，我這個系列的文章也是想告訴堅持Java語言的程序員們，您到底損失了什麼。
更重要的是，那就是Java雖然糟糕，但還是有解決辦法的。如果沒有解決辦法，那麼這場討論的價值就會大打折扣了，因為討論了半天 我們還是只能保持現狀。例如，C語言生產力高嗎？當然不如如今許多高級語言。但是，C語言是不朽的，因為我們必須有一種語言來負責 底層的開發，這要求它和馮·諾依曼結構盡可能的對應，而不能有太高級的抽象（因為一高級就難以生成最為高效的機器碼了）。因此， 我不會討論C語言的特性，我會選擇Java語言。當然，這個解決辦法就是拋棄Java，換用一種生產力更高的語言。
最後，好吧，其實還有一點便是，我對Java語言足夠熟悉。我的“職業程序員”生涯便是從Java開始的（之前都算是小打小鬧），大學 裡的編程課學的也是Java（期末考試時是全班最高的106分，滿分是 100+10分附加題），也用它做了不少項目。我還記得最後一個Java項 目是2004年參與開發的是海關審批工作流，當時翻來覆去看的參考書是《J2EE Development without EJB》。只不過接下來我便投身 於.NET世界，用的最多的語言便是C#了。C#從2.0起突然發力，瞬間將Java語言甩開幾條馬路，而3.0的改進更是堪稱經典。不是我不想回 到Java平台，是我實在不想在Java語言上浪費生命。
嗯嗯，其實我也挺希望許多朋友在批評一個事物的時候，先對它的現狀有足夠了解的。否則，真挺沒意思的。
又為什麼是C#？
好吧，那為啥要拿C#出來耍？直接說Java的不是就行了嘛。其實我也有幾點理由：
首先，我的博客畢竟還是主要關注於.NET技術的，來看我文章的大部分朋友相信使用的還是C#語言。我這一系列文章雖說是要講Java爛 ，但可能大部分“手法”是在說明C#和Java語言之間的差距。因此，我也會努力地在文章中體現C#的美妙之處，會展示大量C#的編程模式 。這些模式並非只是為了好看，而絕對是在生產過程中非常有用且常用的。我希望這系列文章除了鼓勵別人擺脫Java語言的負累以外，也 可以給C#程序員帶來同樣的價值。
其次，我想改變許多朋友對C#的看法。我想大部分朋友應該了解C#語言比Java的特性多，但是您可能不太了解C#目前的發展狀況，以及 C#和Java之間的真實差距。您可能會認為，C#雖然比Java特性多，但也只是一些語法糖而已，雖然可能的確比Java生產力來的高，但是優 勢並不明顯。我想要告訴大家的便是，C#有別於Java的特性並非這麼普通，它是凝聚了Anders Hejlsberg這個天才的理想，都是對生產力 提高有重大意義的。
還有，如果要與Java語言進行比較，還有比C#合適的對手嗎？我想不到很合適的。因為根據TIOBE語言排行榜的紀錄，排名靠前的語言 中也只有C#和Java頗為相似。這個相似體現在多個地方，其中最重要的在於它們所在的平台所面向的應用類型幾乎完全相同。C#和Java語 言也是糾纏如斯，相信這兩者的碰撞會比其他情況帶來更多關注。同樣，至今還有些朋友認為C#只不過是在抄襲Java而已。不過我在這裡 想說的是，好吧我承認C#在最初和Java頗為相似（但也有許多不同），但是自從C# 1.0誕生之日起，就只出現Java借鑒C#特性的情況，至 今已將近10年。您可以記住這句話，我會證明給您看的。:)
當然，我對C#也足夠熟悉，我想這點就不用多做解釋了吧。
LISP那點事兒
呃，我在表示要寫Why Java Sucks and C# Rocks系列文章後，收到的許多質疑是有關LISP的。LISP是一門（或者說是一類）神奇的語 言，雖然在工業界的應用並不廣泛，但是卻有著不容置疑的歷史意義。我有幸在大學時加入了復旦大學軟件學院和愛爾蘭都柏林大學合辦 的所謂“愛爾蘭班”，開辦的第一門課便是函數式編程，使用LISP講解（不過現在的同學已經使用Haskell了），於是我在那時候也對LISP 產生了一定的興趣，也有了大半年的學習接觸。雖遠不能說是精通，但基本的了解想必還是有的。
關於LISP，有種說法便是“LISP之後，再無創新”。於是有朋友說，那麼你不談LISP，在Java和C#之間比什麼勁兒嘛。首先，我想上文 也已經表現了我的一部分想法了，現在則再談一些。其實我覺得這種說法就好比說“某某人已經是第一名了，後面的爭奪又有什麼意義呢 ？”，這個說法顯然是不妥當的。語言的爭論和評價從來不曾停止，即便是大師們，例如Linus炮轟C++，高司令談C#，Anders認為Java的 泛型不好，Matz在郵件列表中戲稱Ruby為MatzLisp，這些都是有趣的，有價值的，值得關注的東西。
也有朋友說，有什麼語言能帶來LISP那般革命意義，能夠代替Java呢？LISP的確有其革命意義，但是語言的確知道它的缺陷，因此也就 主要是把它供在神壇上，需要的時候膜拜一下便是，緊抱不放便是問題了。語言同樣在不斷發展和演變，尤其是對於工程應用來說，人們 對於生產力的追求永遠不滿足，這點從業界關於語言的會議（如Lang.NET）便可得知。而即便是如IFL這類專注於函數式編程的學術會議， 對於LISP語言本身的關注程度也有所降低。人們都知道，是該站在LISP的肩膀上向前看的時候了——其實很久以前就是這樣了。
而且，我的目的主要還是想鼓動大家拋棄Java語言，這和它的替代者是否革命意義並沒有關系。這就好比，對於石器時代的人們來說， 第一根鐵棍的革命意義遠超後來的神兵利器，但是人們什麼時候放棄過對神兵利器的追求呢？只要真正是“更好”的東西，那也就足夠了 。
我也是個俗人，討論討論對真正生產有直接影響的東西，也就夠了。
糖、糖、糖
再回到關於“語法糖”的討論。之前提到，有不少朋友認為C#相對於Java只是語法糖較多，夠甜。但事實上，我在這一系列文章中並不 想提“語法糖”這些東西。嗯，我是說，我眼中的語法糖。
從理論上說，只要是圖靈完備的語言，就不存在“能力”上的根本差異，任何工作都是可以實現的。但是我們使用的語言，往往也會影 響，甚至決定了我們的思維方式。因此一門語言的關鍵，我認為就是它的思想，或者說，是它對我們“思維方式”的影響。同時，由於語 言會影響我們的編程思維，甚至系統的架構設計，因此在我看來它也是至關重要的。
舉個有些極端的例子，如果人們還在使用匯編語言進行開發，那麼估計程序員的思維永遠無法跳出“子過程”這個抽象級別，什麼面向 對象設計，函數式編程幾乎無從談起。人們在生產和學習過程種會引發一些需求，因而需要產生一些工具來輔助學習和生產，而“語言” 便是此類工具之一。只有利用高級語言，人們才能有效地把真實世界抽象成計算機這些機器盒子能認識的東西。
如今，可用於構建項目可選的主流語言往往都會有多種，有時候我們的確會發現，好像不同的語言——例如Ruby和Python——從各方面 來說並沒有太大區別（或者說優劣之分）。這是比較正常的，因為某些（甚至是大部分的）語言特性，並沒有對我們的“思維”產生影響 。
舉例來說，某些喜歡Ruby的朋友認為Ruby語言的編程體驗非常良好，好比它的數組操作可以直接做加法或減法：
array = ['aaa', 'bbb', 'ccc'] - ['ccc', 'ddd']
或者說，在Python裡交換兩個變量的值也只需要一行代碼（大部分語言中可能需要借助中間變量，好吧，我承認Ruby裡也能做到這一點 ）：
a, b = b, a
但是，就我個人觀點來說，這些語言特性，雖然它們的確可以讓編程工作變的相對輕松一些，例如可以讓我們少些一點代碼，但終究沒 有改變，或是表現出另一種編程思維。這樣的語法特性，一般來說都可以通過構建一些簡單的輔助函數來做到類似程度的“簡化開發”（ 如上面Ruby的例子），對於那些非“即寫即拋”的程序來說，這些特性的優勢並不明顯。就我個人來看，我並不會太重視這些內容。
而與此相比，Ruby的Mixin機制和Python的Decorator就不僅僅是“語法糖”，而是比較重要的語言特性了，因為它們可以帶來或大大簡 化某些十分有用的編程模式。“簡化”也是語言設計中非常重要的一點，我始終認為，一個語言特性只有真正“好用”，它才能被人們廣 為接受。例如，使用 Java語言能實現Actor模型嗎？能，但是它缺少Scala那樣靈活的函數式語法，以及模式匹配等特性，因此無法構建出 一個好用、易用的Actor框架，自然也就無人問津了。這其實也是“語言影響思維方式”的典型案例之一。
其實人們在LISP之後繼續前進的原因，也是因為LISP雖然提出了許多編程理念，范式，但是每個都不夠“好”、“優雅”、“簡單”等 等。做的“更好”便是其他語言不可忽視的意義。
是的，我不會強調C#如“屬性”，“操作符重載”等語言特性，雖然它很多時候的確讓開發變得簡單，但是它們並不能改變我們的開發 思維。那麼這一系列的文章中我會重視哪些語言特性呢？我想，它們至少應該同時具備以下三個條件吧：
必須是純粹的語言特性：有人說Python方便，很多事情一個方法就能搞定了。這在我看來只是類庫相關的東西而已。在這裡，我並不關 注類庫與框架，我只關注純粹語言特性。
無法，或很難通過類庫或框架彌補的差距：同樣是一個方法能搞定的案例，但是如果這個方法必須借助特定的語言特性才能實現，那麼 這便是我的關注點。
能夠改變編程思維、或是引出額外的編程范式：正如上文討論的那樣，這是我最為重視的東西。
嗯嗯，就是這樣。
再補充一些內容
好吧好吧，我知道您看到那麼多文字之後也一定也想說些什麼了，不過您再堅持一下，等我把話說完吧。
寫這一系列文章的目的，我想已經說得很清楚了。不過我想我還是有必要強調一下，我並不想讓您：
立即拋棄Java語言（不過我希望您可以現在就開始准備了）
使用C#來代替Java語言
使用.NET來代替Java平台
認為.NET平台勝過Java平台
認為CLR強於JVM
……
總之一句話：我沒說過的東西，您也別多想。我說過的，您也不用懷疑我的“誠意”。:)
再來一些問答吧，如果有需要的話我也會不斷補充一些內容的。
問：語言的生產力，關鍵還是看熟悉程度吧？答：我不這樣認為，很多東西的差距是實實在在，不容置疑的。例如，C語言的生產力就 比匯編要高，電鋸的切割效率就比手工鋸條要好。的確，我承認使用者對工具的熟悉程度會影響生產力，但我想您可以想，就當您已經對 兩種語言都足夠熟悉了，這時候總可以開始比較生產力了吧。不了解怎麼辦？學咯，“磨刀不誤砍柴工”，有句俗話應該是這麼說的吧。
問：開發項目並不由語言一個方面來決定吧？答：沒錯，所以我也不認為您應該“立即”將Java語言拋棄。例如，假如您對它的替代品 還不夠熟悉的話，假如您的團隊還是對Java語言有足夠了解的話，假如您的老板決定非要用Java語言而您離開他又活不了的話……那就繼 續用Java咯。總之，項目的技術選型是個平衡的結果。我只是給您在語言方面給出建議而已。
問：Java語言的替代品足夠成熟嗎？答：足夠成熟。當然，它的社區資源肯定還不如Java語言，但我認為它也足夠了。而且，如果我現 在對它進行推廣，那麼它又會有什麼發展，資源又如何增多呢？是啊我承認，我是個頗有理想主義的人。
問：為什麼不比較Java與.NET平台？答：因為在我看來兩者實在難分高下，上文也說了，這樣的比較幾乎就一定會淪為雙方程序員的口 水戰，因為沒有一方可以拿出切實的證據來說服對方，大家主觀對主觀，實在不專業。當然，如果您感興趣的話可以自己比較一下，我會 適時跟進的。:)
好，該說也說得差不多了。那麼從下一篇文章開始，我們就來一起享受技術帶給我們的快樂——和挫折吧！
文章地址：http://blog.zhaojie.me/2010/04/why-java-sucks-and-csharp-rocks-1-thoughts-and-goals.html
