摘要：原文鏈接有大量平均水平左右的工人可被選擇參與進(jìn)來這意味著好招人有成熟的大量的程序庫可供選擇這意味著大多數(shù)項(xiàng)目都是既有程序庫的拼裝，標(biāo)準(zhǔn)化程度高而定制化場景少開發(fā)工具測試工具問題排查工具完善，成熟基本上沒有團(tuán)隊(duì)愿意在時間緊任務(wù)重的項(xiàng)目情況

原文鏈接：http://pfmiles.github.io/blog/java-groovy-mixed/

有大量平均水平左右的“工人”可被選擇、參與進(jìn)來 —— 這意味著好招人

有成熟的、大量的程序庫可供選擇 ——
這意味著大多數(shù)項(xiàng)目都是既有程序庫的拼裝，標(biāo)準(zhǔn)化程度高而定制化場景少

開發(fā)工具、測試工具、問題排查工具完善，成熟 ——
基本上沒有團(tuán)隊(duì)愿意在時間緊、任務(wù)重的項(xiàng)目情況下去做沒有把握的、基礎(chǔ)開發(fā)工具類的技術(shù)試探

有面向?qū)ο筇匦? 適合大型項(xiàng)目開發(fā) ——
無數(shù)大型項(xiàng)目已向世人述說，“面向?qū)ο蟆笔情_發(fā)大型軟件的優(yōu)秀代碼組織結(jié)構(gòu)

能適應(yīng)大型團(tuán)隊(duì)、多人協(xié)作開發(fā) ——
代碼需要簡單易懂，起碼在接口、api層面是這樣

—— 這是我所理解的“工業(yè)化開發(fā)編程語言”的概念

很顯然, java就是種典型的“工業(yè)語言”, 非常流行，很多企業(yè)靠它賺錢，很實(shí)際；
但java也是常年被人黑，光是對其開發(fā)效率的詬病就已經(jīng)足夠多，不過java始終屹立不倒；

這樣的局面其實(shí)無所謂高興還是擔(dān)憂，理性的程序員有很多種，其中一種是向“錢”看的 —— 我寫java代碼，就是因?yàn)楣ぷ餍枰眩軒椭业慕M織搞定業(yè)務(wù)，做出項(xiàng)目，這很好；
當(dāng)有人說java語言不好的時候，理性的程序員不會陷入宗教式的語言戰(zhàn)爭之中，他會思考這些人說的是否有道理；如果真的發(fā)現(xiàn)整個java平臺大勢已去，他會毫不猶豫地扭頭就走，不過直到目前為止，還沒有這種跡象出現(xiàn);

那么，從這些無數(shù)次的口水之爭中，我們能否從別人的“戰(zhàn)場”上發(fā)現(xiàn)一些有用的東西, 來改進(jìn)我們的開發(fā)方式，從而使得java這種已經(jīng)成為一個“平臺”的東西走得更遠(yuǎn)，賺更多的錢呢？
答案是“有的”，感謝那些參與口水戰(zhàn)爭的、各種陣營的年輕程序員們，有了你們，java speaker們才有了更多的思考;

我就只談一個最實(shí)際的問題：

也就是說，到底是哪些主要特性直接導(dǎo)致了某些其它語言在語法上相對于java的優(yōu)越感？

在groovy中定義map和list的慣用方式：

def list = [a, 2 ,3]
def map = [a:0, b:1]

而java呢？只能先new一個list或map，再一個個add或put進(jìn)去; 上面這種literal(字面量)形式的寫法便捷得多;

而javascript在這方面做得更絕, 我們都用過json，而json其實(shí)就是literal形式的object

極端情況下，一門編程語言里的所有數(shù)據(jù)類型，包括”內(nèi)建”的和用戶自定義的，統(tǒng)統(tǒng)可以寫成literal形式;
在這種情形下，其實(shí)這種語言連額外的對象序列化、反序列化機(jī)制都不需要了 —— 數(shù)據(jù)的序列化形式就是代碼本身, “代碼”和“數(shù)據(jù)”在形式上被統(tǒng)一了

java對這方面幾乎沒有任何支持，對于提高編碼效率來講，這是值得學(xué)習(xí)的一點(diǎn), 起碼“內(nèi)建”數(shù)據(jù)結(jié)構(gòu)需要literal寫法支持

無論是js, 還是python/ruby，或是groovy，都可以將函數(shù)作為另一個函數(shù)的參數(shù)傳入，以便后者根據(jù)執(zhí)行情況判斷是否要調(diào)用前者
或者能夠?qū)⒁粋€函數(shù)作為另一個函數(shù)的返回值返回，以便后續(xù)再對其進(jìn)行調(diào)用
這種高階函數(shù)特性，就不要再說java的匿名內(nèi)部類“能夠”實(shí)現(xiàn)了, 如果認(rèn)為匿名內(nèi)部類已經(jīng)”夠用”了的話，其實(shí)就已經(jīng)與現(xiàn)在的話題“開發(fā)效率”相悖了

高階函數(shù)顯然是一種值得借鑒的特性，它會讓你少寫很多很多無聊的“包裝”代碼;

還有就是匿名函數(shù)(lambda)了
我不喜歡lambda、lambda地稱呼這個東西，我更喜歡把它叫做“匿名函數(shù)”或者“函數(shù)字面量(literal)”, 因?yàn)樗鷶?shù)學(xué)上的lambda演算還是有本質(zhì)區(qū)別，叫”lambda”有誤導(dǎo)的危險

函數(shù)字面量的意思就是說，你可以在任何地方，甚至另一個函數(shù)體的調(diào)用實(shí)參或內(nèi)部，隨時隨地地定義另一個新的函數(shù)
這種定義函數(shù)的形式，除了“這個函數(shù)我只想在這里用一次，所以沒必要給它起個名字”這種理由之外，還有一個更重要的理由就是“閉包”了

所謂閉包，其實(shí)也是一個函數(shù)，但是在這個函數(shù)被定義時，其內(nèi)部所出現(xiàn)的所有”自由變量(即未出現(xiàn)在該函數(shù)的參數(shù)列表中的變量)”已被當(dāng)前外層上下文給確定下來了(lexical), 這時候，這個函數(shù)擁有的東西不僅僅是一套代碼邏輯，還帶有被確定下來的、包含那些“自由變量”的一個上下文, 這樣這個函數(shù)就成為了一個閉包

那么閉包這種東西有什么好呢？其實(shí)如果懶散而鉆牛角尖地想，閉包的所有能力，是嚴(yán)格地小于等于一個普通的java對象的，也就是說，凡是可以用一個閉包實(shí)現(xiàn)的功能，就一定可以通過傳入一個對象來實(shí)現(xiàn)，但反過來卻不行 —— 因?yàn)殚]包只有一套函數(shù)邏輯，而對象可以有很多套，其次很多語言實(shí)現(xiàn)的閉包其內(nèi)部上下文不可變但對象內(nèi)部屬性可變

既然這樣，java還要閉包這種東西來干嘛？其實(shí)這就又陷入了”匿名內(nèi)部類可以實(shí)現(xiàn)高階函數(shù)”的困境里了 —— 如果我在需要一個閉包的時候，都可以通過定義一個接口再傳入一個對象來實(shí)現(xiàn)的話，這根本就跟今天的話題“開發(fā)效率”背道而馳了

顯然，java是需要閉包的

這和開發(fā)效率有關(guān)么？
編程語言不是越“動態(tài)”，開發(fā)效率越高么？還需要強(qiáng)大而復(fù)雜的靜態(tài)類型系統(tǒng)么？

試想一下這種api定義：

def eat(foo) {
    ...
}

這里面你認(rèn)識的東西可能只有’吃’了, 你知道foo是什么么？你知道它想吃什么么？吃完后要不要產(chǎn)出點(diǎn)什么東西？ —— 你什么都不知道
這種api極易調(diào)用出錯，這就好比我去買飯，問你想吃什么你說“隨便”，但買回肯德基你卻說你實(shí)際想吃的是麥當(dāng)勞一樣

可能你還會反駁說，不是還有文檔么？你把文檔寫好點(diǎn)不就行了么？ —— 不要逼我再提“匿名內(nèi)部類”的例子，如果給每個函數(shù)寫上復(fù)雜詳盡的文檔是個好辦法，那就顯然 —— again, 與“開發(fā)效率”背道而馳了

那么，靜態(tài)類型系統(tǒng)，這里顯然就該用上了

靜態(tài)類型系統(tǒng)在多人協(xié)作開發(fā)、甚至團(tuán)隊(duì)、組織間協(xié)作開發(fā)是非常有意義的；
擁有靜態(tài)類型系統(tǒng)的編程語言通常都有強(qiáng)大的、帶語法提示功能的IDE，這很正常，因?yàn)殪o態(tài)類型語言的語法提示功能好做;
只要把別人的庫拿過來，導(dǎo)入IDE，各種函數(shù)簽名只需掃一眼 —— 很多情況下根本不需要仔細(xì)看文檔 —— 就已經(jīng)知道這個函數(shù)是干嘛用的了, 合作效率成倍提升;

而且，作為”api”，作為“模塊邊界”，作為與其它程序員合作的“門面”, 函數(shù)簽名上能將參數(shù)和返回值類型“卡”得越緊越好 —— 這樣別人不用猜你這個函數(shù)需要傳入什么類型，甚至他在IDE里一“點(diǎn)”，這里就給自動填上了 :)

要做到“卡得緊”，光有靜態(tài)類型系統(tǒng)還不夠，這個系統(tǒng)還需強(qiáng)大, 試想一下這個例子:

/**
 * 我只吃香蕉和豬肉，請勿投食其它物品
 */
public void eat(List