atitit.高級編程語言的特性 and 將來趨勢與進化.doc

atitit.高級編程語言的特性 and 將來趨勢與進化.doc

 

1 編程語言的發展歷程 1

1.1 編程語言的進化，起始發現背後的思想 ：不論什麼兩個系統之間的複雜性，都可以經過加入一個抽象層要屏蔽 1

1.1.1 C語言, 硬件抽象層 2

1.1.2 高級語言：java,.net  跨平臺(os)抽象層vm 2

1.2 DSL領域編程語言(跨越編程語言) 2

1.2.1 實現方式:: 語義 和 語法 分開 2

1.2.2 結構Dsl,dsl解釋器 2

1.2.3 統一的開發語言 2

1.2.4 每個領域特性部分,使用類庫解決 2

2 語言特性發展 3

2.1 Oo+ 3

2.2 Function 3

2.3 動態（non編譯）仍是編譯？？ 3

2.4 多核 3

2.5 強類型仍是弱類型？？？類型判斷和模式匹配 4

2.6 面向天然語言仍是簡單的?? 4

2.7 抽象能力 4

2.8 刪除語法噪音 4

2.8.1 語法噪音 4

2.9 強大ide,vm 5

2.10 Gc 垃圾收集 5

2.11 Vm 平臺化 5

2.12 數據與結構分離仍是緊密集合？？？ 5

2.13 異步api 5

2.14 安全api 5

2.15 庫與語法融合 6

2.16 . fluent API： 流暢api 6

3 參考 6

 

1 編程語言的發展歷程

 

1.1 編程語言的進化。起始發現背後的思想 ：不論什麼兩個系統之間的複雜性，都可以經過加入一個抽象層要屏蔽

 

1.1.1 C語言, 硬件抽象層

對於彙編語言的問題。主要要解決跨硬件平臺，加入一個抽象層，這個就是硬件抽象層

 

1.1.2 高級語言：java,.net  跨平臺(os)抽象層vm

爲了解決C語言的跨平臺的問題

 

做者:: 老哇的爪子 Attilax 艾龍，  EMAIL:1466519819@qq.com

轉載請註明來源： http://blog.csdn.net/attilax

 

 

1.2 DSL領域編程語言(跨越編程語言)

 

1.2.1 實現方式:: 語義 和 語法 分開

 

而個的語言編程語言通常都是語法和語義綁定在一塊兒的

 

1.2.2 結構Dsl,dsl解釋器

 

 

1.2.3 統一的開發語言

現在愈來愈有這個趨勢了，各個語言都在加入其它語言的特性。加強本身的特性，之後各個語言都變的愈來愈相似，功能也愈來愈雷同

 

1.2.4 每個領域特性部分,使用類庫解決

或者二手的dsl?

?

 

 

 

 

2 語言特性發展

2.1 Oo+

2.2 Function

2.3 動態（non編譯）仍是編譯？？

綜合考慮，工業級別的源代碼保護的考慮哈,仍是要編譯,,yaneng跟個python雅十,共同的情形哈不編譯器,給客戶的時候兒編譯..

 

python雅十,常用使用script式,,也能編譯了...

 

動態性意味着更加靈活，意味着開發人員有不少其它的"魔術"可以玩。而開發人員會天生對動態語言有親暱地感受，這是人的本性。

但是凡動態語言，JavaScript、Python、Ruby這些，實際上已經意味着與地層開發無緣了。

同一時候靈活意味着少約束，少約束意味着大規模程序很是難被編寫出來。到眼下爲止。很是少聽到過超過10萬行級別的JS語言項目，這種現象多少與JS的動態性有關。

反過來看，動態性較低的C語言現在成了驅動和OS內核開發的不二之選。因爲好像驅動裏面根本用不着那些看上去NB的抽象——即便你用了C++。也是像C同樣用而已

 

2.4 多核

 

 

2.5 強類型仍是弱類型？？？類型判斷和模式匹配

 

以及ide支持不行。。

因此。綜合考慮，工業級別的  任然是強類型的天下。。

也可以強大的類型判斷和模式匹配

 

或者,語言支持弱的型,也能強壯的型…必要的的時候兒,能強類型…

 

Scala是靜態類型的。不少人會把vals="ABC"這種看成動態類型特性，而vals:String="ABC"才以爲是靜態類型特性。實際上，這無關類型爭論，而是類型系統實現的範疇。是的，在Scala裏，你可以放心大膽地使用vals="ABC"。而Scala裏強大的類型判斷和模式匹配。絕對會讓你愛不釋手。

 

 

2.6 面向天然語言仍是簡單的??

Cobol,ada的強壯的理解性…普通的的人們能理解的..

大部分情形哈,仍是簡單的特性ok…而個的java代替了cobol,ada..

 

2.7 抽象能力

抽象能力應該是現階段語言進化的第一優先級，抽象手段無非函數式、過程式和麪向對象三種，看計算機語言的流行歷史， 不難看出 函數式=>過程式=>面向對象=>函數式迴歸 這種規律。Lisp一直在學術界評價頗高，但是其商業應用一直低迷。其抽象能力比較弱一直是個重要的緣由。

 

2.8 刪除語法噪音

2.8.1 語法噪音

語言除了功能和設計，「長相」也是很是重要的。這裏要提到一個語法噪音的概念，比方JS裏面的function，相比lambda表達式，這個噪音就多了

arr.some(function(x){ return x<2});

而C#裏面可以這麼寫：

arr.some(x=>x<2);

這裏面。functionkeyword。returnkeyword，各類符號，事實上實際意義都不大，因爲JS語法設計，而必須要加上，這就是一種噪音。

有趣的是，向python這種語言對於「去噪」的追求達到了極致，甚至不惜用空白作標誌幹掉花括號，這個作法致使了其譭譽參半，喜歡的人特別喜歡，不喜歡的人特別討厭。

 

2.9 強大ide,vm

2.10 Gc 垃圾收集

眼下不少語言都可以本身主動垃圾收集。。

但是僅僅是內存。。

數據庫。網絡，以及磁盤io鏈接任然有泄露的可能。

。

 

 

2.11 Vm 平臺化

 

2.12 數據與結構分離仍是緊密集合？？？

 

儘量的分離爲好。

 

程序和數據也不該該被分開。

因爲現代數據操做和模塊化的基礎是並行程序（parallelism），而有效實現並行的基礎是程序的first-class表達，也就是把程序做爲一種基本數據類型。

2.13 異步api

 

2.14 安全api

 

閉包、多個返回值

2.15 庫與語法融合

 

庫與語法融合在了一塊兒。

咱們可以看到在Java中對字符串String對象的操做可以簡單地使用操做符+、+=進行操做。然而String自己並不是關鍵 字，但是可被編譯器識別。因爲你換成其餘對象可能就沒法用這些操做符來進行操做了。

而對String類的實現自己可用一個用Java編寫的相對獨立的庫進 行實現。

 

事實上將語法體系與語言自帶標準庫綁定仍是有很多優勢的。

首先，這easy被擴展，開發人員可以依據本身的需求來本身定義某些語法的行爲。

其次，對編譯器而言可以減 輕壓力。某些執行時行爲可以交給標準庫進行實現。

這樣，編程語言可以比較方便地被打形成比較完備的語法體系。這樣的耦合也加強了編程語言的執行時能力。包含 靈活性、可擴展性。

 

2.16 . fluent API： 流暢api

偏向傻瓜式的編程，直接用IDE的代碼輔助就能把代碼敲出來。

java那種展示精美的架構的同一時候，卻要求程序猿本身一塊塊磚搭起來的風格逐漸沒落...

 

 

 

3 參考

atitit.編程語言的將來趨勢與進化結果

Atitit.現代高級語言的特性以及趨勢attilax總結