這個問題有意思。

但是說傾向有點早。

很多概念早就產生且應用，但一直半死不活，直到有一天在某個領域確定一點結果，然後會被無線炒作。

類似的有以前js,nosql,mobgodb,nodejs,到微服務，再有函數語言程式設計，反應式程式設計。。。

但是這裡面銀彈很多。。。比如函數語言程式設計，java8裡擴充套件了對這方面的支援。。

我們團隊也有激進的，全部採用函數語言程式設計，這麼做的目的並不是函數語言程式設計更優雅解決了什麼問題，至少目前完全沒有。用它的目的僅此一個，覺得牛逼想用上試試。。

但帶來的結果並不好，效能上壓測沒有任何優勢，程式設計方式上完全不如面向物件的可讀性好，程式很大一部分是給人看的，是要維護的，早已不是一個人的事情，是團隊合作的，另外除錯性也很差，排查問題難。。。當然我自己也在嘗試函數語言程式設計，但只為了解決一部分問題，而不是萬能藥

一切都是為了簡潔！

長期以來JAVA作為面向物件的代表語言佔據著開發語言的榜首，面向物件的三大特性是繼承，多型，封裝，這就意味著面向物件的開發先從定義物件開始，即便是一個很簡單的功能也有著相對冗長繁雜的程式碼！

JAVA語言憑藉著成熟的技術社群和豐富的類庫，還有模範化的開發模式一直都是企業級應用的寵兒，但正是因為此，冗餘程式碼，複雜開發飽受詬病！為了改變這一現象，oracle在收購JAVA之後，一直致力於JAVA的簡潔化開發，最近幾年很流行的程式語言scala等，因為其不僅融入了面向物件的思想，還有函數語言程式設計的特點，非常符合現如今簡潔開發的理念！

JAVA開始瞄準scala，因為scala本就在jvm中執行，其指令碼化，函式式的特性正是JAVA所需要的，JAVA8中加入了lambda表示式與函式式介面，能方便的進行函式式的開發工作，雖然相比koltlin，scala還略顯囉嗦，但總算是撬開了函式式的大門！

總之，以後的JAVA新版本會提供更多的函式式開發的相容開發，不是說函式式比面嚮物件語言好，而是能各取所需，走向更美好的明天，以後的程式語言是不是就沒有特性之分了，值得期待。。

是的，但是絕對不是為了什麼“簡潔”，這太膚淺了。從C++開始，人們發明了面向物件式程式設計，取得了巨大的成功，因為這種方式很貼合人類認知世界的方式，所以很容易被人接受，但是面向物件只是讓程式程式碼看上去更容易被理解，並沒有正真解決計算本身的複雜性問題，這個問題在程式的計算環境相對簡單的年代中尚可忍受，但是隨著大資料和雲計算的來臨，終於到了忍無可忍的程度，計算實體的位置感消失的同時，結果的一致性要求反而提高了！而面向物件在這個問題上不僅毫無建樹，相反助紂為虐。於是人們不得不回去重新考慮該如何在不確定的環境中依然能夠寫出可靠的程式，既然面向物件只是計算的表象，那麼計算的本質是什麼呢？其實那就是是數學，只有數學才是嚴謹的，可被證明的，才是不管在多嚴苛的條件下都能夠得到唯一結果的，因此我們必須修正面向物件中那些不滿足數學精神的部分，比如變數的共享修改，這在數學中是不被允許的，想象一下你在解答數學試卷的時候，你解答的每一個證明都是獨立的，不可能因為修改了某一個命題的條件而影響了另一個命題的答案，這就造成了某種結果上的不確定性，而這恰是面向物件的原罪，因此泛函程式設計這個古老命題再次被人提起，泛函程式設計其實並不是新鮮事物，上個世紀70年代就已經有人提出，只不過在計算機尚未普及的年代，人們面對的主要挑戰是如何普及計算機，人們透過施加一些小的程式設計技巧來暫時迴避這些專業性的理論，因此在和麵向物件的第一次競爭中，對人類更友善的面向物件以絕對優勢勝出，才成就了8.0之前的Java，之後的事情大家都知道了，計算環境發生了翻天覆地的變化，人們再次反思，泛函程式設計重見天日，所以今天你才會再次見到這個“古老”命題。

我覺得主要是沒有其它好炫技的方式。

做為一個寫了好久java的老程式設計師。覺得java的優勢在於那死死地語意表達。簡單的來說，就是一個意思能表達的方式很少。這個是有利於大專案開發的。但是造成了一個對程式設計師的制約，你很難透過一兩行程式碼反映你的水平。因為反應水平，需要看你一個專案寫下來到底好不好維護。

縱觀java。能夠通過幾行程式碼炫技的。目前為止，除了java8那些。其他幾乎找不到。總不見得說我spring配置的多優雅吧。