0101.在時間軸上的缺陷

History
在時空當下, 事物絕大多數是可合理化的; 但隨著時空的推移, 它不一定能被持續的考驗, 你可選擇改變也可墨守成規. - 老魚

YouTube Video


在這頁, 老魚沒有多大資格來批判 JAVA / C++ / C#, 因為老魚不太相信全球有多少位學者甚至推有著作品的作者, 能真正看到這幾者的缺陷, 更別論老魚, 所以在此僅能將老魚的所見所聞, 一一整理轉述給各位.

程序語言無分好壞優劣, 重在你想要什麼 ? 是當一位通才(熟悉各種程序語言學者, 但缺點則都不精通者), 或者當一位專精特定程序程序語言的專家,  在老魚看, 語言都只是個過程工具, 懂再多的語言, 寫再多本著作, 回歸本質都只是過程, 工具的目的在於它能實作出完整創作品的大格局工藝思維, 切勿浪費生命在探究片斷小程式邏輯上鑽牛角尖的小格局, 與其如此不如去研究數學更來的有價值.






JAVA / C++ / C# 都開始呈現老態了


C++ / JAVA 有著數十多年的發展史, 也在今天坐擁全球物件導向(Object-Oriented)編程的前幾名, 但歷史的包袱和缺陷也逐漸侵蝕其原有的優點, 在數十年後的今天, 需要更先進的編程研究與實作來接替未來的十年發展 ...

JAVA / C++ 都開始呈現老態了, 更別論改良於 JAVA / C++ 的 C#, 回到當時20年前, 物件導向(OO)改變當代的思維, 但近年來, 我們認為嚴謹的開發模式逐漸被挑戰甚至被打破了定律 ...
  1. 輕快的 Python, Ruby, Groovy, ..., 在許多層面的創新與簡約, 重擊了守舊 Java / C++ / C# 開發者們的思維 ...
  2. OO 中的繼承(Inheritance)曾被識為重用的最大特點, 但現在看來它不是, 更存在著缺陷 ...
  3. 摩爾定律(Moore's Law)被 Multi-Core 的出現, 而被推翻, 造成我們必須擁有更好的 Concurrency; 在多個 CPU 上同時執行多線程環境,而不再是在單個 CPU 上執行標準循環週期,這意味著 Code 必須具有牢固的線程(Thread Security)安全性,才能存活下來。Concurrency 衝突是真正的問題所在 ...
  4. 但最重要的是,我們周圍的世界變了, 不再是十多年前的背景因素 ...


靜態語言易導致大量的固定語法規則限制


Scala 是類型語言, 是靜態類型的, 但不同的是它僅在必要之處明確定義其類型. 語法是輕量的, 且富表達性.



根基缺陷, 不是藥物就能治愈


核心設計在程序語言級是不可輕易動搖地, 更隨著時間的推移的越久, 對向下相容的要求, 更易形成一種隱性甚至是顯性的“包袱“ ...

JAVA / C++ / C# 在一定的程度上都為了讓開發者易於接受已創的程序語言而長年努力, 並在其基礎上超越對手, 但核心的問題並未真正符合當代的問題來加以重構, 問題也就跟著不自覺的擴散到各平台 ...



OO缺陷與過度亂用



  • 繼承不是萬靈丹



 

多核多執行緒共時同作的新挑戰


現時的 Concurrency 的編程存在幾個問題,
  1. 難以理解
  2. 難以撰寫
  3. 運作衝突



函數編程的價值重新被重視



  • 不變性





References


Google App Engine的資料存儲和基於Java的持久化
Richard還指出了Java-based persistence目前的一些嚴重的缺陷,並給出了相應的解釋和說明。

LambdaJ 将real closures带入Java

Scala拾趣--從Java7說開來
Java 是一種令人驚嘆的複雜語言(它的語法規範長達600頁,我懷疑到底有沒有人能真正理解它),它有自動裝箱(Autoboxing),空指針 異常(NPE)往往就是這時拋出的。其中的基本類型(primitive type),字符串/文字/緩衝器/集合類(collections)以及數組缺乏多態性,以至於處理任何資料結構都需要冗長的語法;而且,由於Bean 屬性和對閉包支持的缺失(甚至在JDK 7里也仍然還不支持),這會讓你的代碼裡充滿了 try/catch/finally 這些語句(除非你使用框架和新的自定義API)。除了這些還有好多數不清的麻煩問題。Java倒是有類型推斷(type inference)功能但卻不用,使得我們要多輸/讀如此大量的代碼。

這個問題在沒有Java7後變得更加緊迫 (在Snorcle之後它變得更加重要:我不知道javac是不是要被jdkc 取而代之了?)。所以我猜javac可能已經走到了盡頭,它看起來根本就沒有什麼進展或簡化了。

Comments