My future of programming

正常的題目應該是 the future of programming 纔對,
不過我想個人套路終歸會被認爲是旁門左道, 不少人並不喜歡,
再者說, 編程探索的方向有不少, Cirru 只是很窄的一個方向.
大概在編譯器, 文本語法, IDE 這些方向依然會是改進的主流.
半圖形編程嘛, 太奇怪, 並且也不通用, 也許還能把人嚇怕了.
但我仍是想把本身的想法整理出來, 而且但願我是對的.

語法的煩惱

你能夠暫且認爲我有代碼潔癖, 相信不少人也是有的, 甚至各不同,
其實我最初上手的語言是 Python, 縮進的, 語法很簡潔,
無論怎樣, 我對 C 風格的語法一直有反感, 有着很硌腳的感受.
因而我去思考怎麼人類才能寫更少的代碼, 而完成對應的工做.
個人結論大概是, 代碼的佈局應該有算法來控制, 避免人類手寫.

Cirru 出發點就是用 Canvas 繪製語法樹, 而後直接編輯語法樹,
如今爲了方便使用, 實際上用了 DOM, 但仍是儘可能讓佈局更漂亮一些.
而這樣的結構其實很契合 Lisp 的風格, 而同時使用自動佈局算法.
因此這基本就是我對於程序的理解, 寫一棵語法樹, 而後運行,
按照表達式增刪改查, 不是一個個字符一行行文本啊, 而是有結構的樹.

文件的麻煩

"文件"這個概念已經在程序員腦子裏深深紮根, 我要攻擊, 恐怕是叛逆,
來看一些場景吧, 我說 Clojure, namespace 的用法,
namespace 跟文件是對應的, 因此, 其實兩份信息, 其中一份是冗餘的,
若是改變了文件名, 對應的 namespace 也就須要更改,
通常程序當中出現這種狀況, 咱們會設置函數, 響應式地改變第二個值,
但文件這種存在, 脫離於程序語法樹, 沒法被控制, 信息分散在兩個 scope.
這中間確實存在一些麻煩, 或者說冗餘, 只是未必讓人以爲嚴重.

然而站在個人角度看, 或者說, 逆向思惟吧, 若是沒有文件呢?
namespace 是管理代碼的手段, 問題的本源是, 函數太多, 不方便管理,
若是沒有文件, 咱們有沒有辦法管理數量上百上千上萬的函數名?
我以爲能夠, 辦法依然是 Group 的概念, 可是爲何必定要用文件?
好比你在瀏覽器收藏上千個書籤, 能夠用文件夾分割, 但不須要真的文件,
文件是能夠被替換的實現, 僅僅是須要個 Group, 怎麼樣均可以.
並且, 若是咱們能搜索, 好比 Google 當中那麼多數據, 不用文件夾依然能找到.
因此真實的問題是, 大量數據, 怎樣管理, 怎樣查找?

程序是什麼?

從文件的反思就延伸到這個問題, 你究竟怎樣看待程序, 程序是什麼?
咱們知道存在高級語言低級語言的分別, 知道編程語言和機器碼的分別,
我還截了一些圖用來對比 http://weibo.com/1651843872/E...

首先 Quicksort 算法, 有個我徹底看不懂的彙編的版本,
彙編對應的是 CPU 指令, 或者稍微高級一些, 包含簡單的標記, 操做, 移動等等:

而後是稍微高級一些的 C, 函數的概念已經有了, 還有 for/while 的概念,
這就是結構化編程的開始, 這些經常使用的流程控制語句涵蓋了大量場景,
同時咱們不用一直顧慮底層的硬件到底是怎樣工做的, 只要知道程序的結構如何設計:

Ruby 引入了混合範式的抽象, 程序進一步簡化, 這當中是混用的:

最後一個是我最佩服的 Haskell 的例子, 幾乎是數學化的表述,
這是能夠運行的代碼, 性能儘管不高, 可是抽象以後徹底不像是第一種了.

我想說的是 Quicksort 一個算法, 有那麼多種程序的結構, 你想到了什麼?

我對程序的理解

在我看來, 對於程序你們能夠有着不少不一樣的見解, 徹底能夠,
也所以, 我以爲找到適合本身的一種抽象尤其難得.
熟悉個人人知道我鼓吹函數式編程, 也就是偏向 Haskell, 雖然不完全...
在個人眼裏, 程序是數據之間相互依賴的關係造成的複雜結構,
怎麼說, 我舉一個 Clojure 的例子, 好比個人程序計算 c:

(defn c [a b]
  (+ a b))

那麼這裏的 c 依賴 a 和 b, 只要拿到兩個依賴, c 就有解,
找一個具體的例子, 下載文件, 這中間依賴好幾個步驟,
當全部的三個步驟完成, 那麼下載文件的程序也就完成了.
而這裏特殊的是, 它的依賴是用反作用寫的, 並且限定了順序,

(defn download-file [url]
  (request-file url)
  (save-file)
  (print-success))

也就是說, print-success 依賴 save-file, 然後者又依賴 request-url.
在 Haskell 當中反作用被封裝, 這一點尤其誇張... 但確實這個道理.
還有一些並行計算的例子, 這種依賴關係還能派上用場..

以此我認爲程序就是函數和數據等等內容依賴關係造成的複雜形態.
推論就是, 我應該基於函數基於數據的依賴來編寫程序,
這個提及的比較抽象, 可是寫 Clojure 確實慢慢能積累這種感受.

Stack Editor

Stack Editor 的理念, 主要基於函數來管理程序, 同時弱化文件的概念.
當你須要編輯函數, 你儘可能經過函數之間的依賴關係之間打開函數,
你也能夠把函數放在側邊欄, 方便在不一樣的函數之間切換,
而你不須要去管文件怎麼建立, 函數擺放的順序誰先誰後,
你要作的是定義好依賴關係, 而具體怎樣保存, 那是編譯器的工做.

我知道根據依賴關係, 咱們能分析出更多關於程序的細節,
編譯器能夠比咱們更清楚地瞭解程序每個細節, 從而給出指導.
這些將來依然能改進, 這個版本我固然還作不到的.

人腦的極限

還有一點很是重要的是, 咱們須要瞭解本身的弱點在什麼地方,
特別是面對機器所擁有的海量的內存和強大的計算能力,
人類大腦依賴的是神經元信號分析模式, 而後得出一些結果,
而越是抽象的內容, 越是須要消耗腦力去認爲建立大量的聯繫,
很顯然, 人腦並非處理這類問題最合適的計算單元,
於是我認爲編程當中複雜的邏輯關係以及依賴關係不適合人工處理.

而編程當中這類問題並很多, 特別是大型軟件會遭遇的種種問題.
英文社區有篇文章概括了一些, 我很是認同的做者, 大體列舉了這些:
http://www.chris-granger.com/...

• Programming is unobservable

• Programming is indirect

• Programming is incidentally complex

關鍵的問題就是, 編程不像是咱們平常當中遇到的可觀可感的各種問題,
不像是幾十萬年來咱們從生活中積累, 大腦適應去解決的那些問題,
流動在代碼當中複雜的關係, 可讓一個沒有通過編程訓練的人一籌莫展!

於是個人見解, 應該儘量把更適合機器處理的部分分離出來,
而後寫成程序讓計算機完成, 而人類儘可能只作本身擅長的事情.
用工具去生成代碼和管理函數只是開始的幾個步驟,
我應該在將來會更多地思考圖形編程相關的問題, 但願能給出一些成果.

可組合性

用用戶體驗的話說, 應該是"最小學習成本", 用戶不須要學習額外的內容,
但放在計算機的領域當中, 作減法每每不能直接砍掉東西.
好比說編程語言 A 有一系列功能, 但爲了簡單, 不能說就直接去掉某些,
而是, 應該像是數學當中, 若是概念要去掉, 它應該是從其餘概念推導獲得,
那麼, 就像 Scheme 的規範能制定出一個精簡的版本, 同時功能依然全面.

而達成這種目標, 就值得讓每一個單元都具有足夠強大的組合能力,
這樣, 才能最大限度地複用, 最大限度地用有限的元素組合出更多功能.
在我看來"一切皆是表達式"是很是重要的一個特性!
"一切皆是表達式"意味着每一個單元均可以被組合, 能夠在全部恰當的地方使用,
在命令式語言當中, 或者自定義的 DSL 當中, 每每這項功能是殘缺的.

就像是數學, 數字能夠擴展用在幾乎全部的計算當中, 會計算就能上手新事物.
而這項特性一旦喪失, 當你面對新事物, 那就是全新的事物.
顯然咱們但願學到一個 x 就能拿 x 組合已有的 y 創造 x * y 中可能,
而不是一個 x 學完以後, 咱們只有 x + y 中種新的手段.考慮的將來編程會怎樣, 我固然是但願向前者靠攏的, 帶來更多可能.