程式語言領域的專家和市場的對決？

為什麼每個人都討厭GO語言？一文明顯地暴露了這種衝突，Go語言受到市場的歡迎，但是專家們卻認為它拋棄了40年的程式語言研究成果。

更有甚者，拋棄這種手工程式碼編寫，兩位開發者一週內沒有寫一行程式碼開發出一個應用，他們使用圖形化虛擬開發工具，如同當初Delphi一樣能夠快速拖曳開發出一個應用，他們認為這會讓開發者更加關注業務需求。

抑或現在程式語言的複雜得以至於讓人們失去了方向，魔鬼是在細節中，因為魔鬼會讓人過於沉湎於細節，以至於沒有精力搞清楚我們使用這些工具到底是為了做什麼？

物件導向分析的概念模型和實現細節的不匹配一文提出了當前語言並不能很好實現針對需求分析的概念模型。

文中列出了八大不匹配，其中提出分析領域的“類”的概念和程式語言如Java的“類”其實是不同的，概念模型中的物件不只是可以屬於一個類，也可以遷移到屬於其他類。而在Java等語言中，一個物件是類的一個例項，這個例項一旦生成就不能更改為其他類，針對這種情況有兩種解決辦法，首先是使用繼承，讓一個類事先繼承很多種類，然後這個類生產例項時，確保有很大的記憶體這個物件例項能夠將其繼承的所有類欄位都載入到記憶體，很顯然這個辦法比較笨重，實踐中很少使用，還有一種辦法是：：語言能提供物件屬性的動態獲取和刪除，在這個模式中，所有物件實現將是動態的資料結構，我們透過對資料結構的成員的動態組合實現一個物件是任何幾個類的成員這一目標。Scala等語言的trait和Go語言是徹底的面向組合的併發語言也許是這一目標的兩種嘗試。

該文還將實現內部併發和分散式通訊的活動物件也是概念模型的一個要求，而與之對應的Java等語言中，物件都是被動的，所謂被動也就是物件自己沒有行為(貧血模型)，都是作為資料DTO被動地被服務等傳來傳去，而分析領域的概念模型要求物件是一種可以自行活動的物件，可以有自己內部併發機制。這方面Scala的Actor模型和Go語言的CSP模型應該都是一種探索。

該文指出，軟體開發的未來是分散式、併發、持久、活動物件系統。這其實對程式語言的未來指出一個方向，也許等到那天，業務和程式語言能夠和諧統一在一起，人們不再會為業務快速變化與程式語言不斷複雜變化而頭疼。