Rebol/Red，讓編程回歸人性

首先聲明，本文作者非計算機專業，僅從業餘角度探討編程語言的設計，諸多謬誤之處，還望見諒。

本文主要介紹以下兩種語言：

1、Rebol語言

REBOL是針對互聯網通訊設計的。REBOL是一種高級解釋語言允許你訪問和控制互聯網的資源，而且他的便捷讓你可以開始考慮把互聯網當成你的個人操作系統。（來自百度百科）

2、Red語言

繼承Rebol語言95%的語法，並通過內建Red/System方言，拓展了底層系統的開發能力，目標是成為首個全棧編程語言。（沒有百度百科，我閉著眼睛編的……）

絕大多數同學看到這兩門語言的反應一定是：What，這什麼語言，壓根沒聽說過啊。

沒錯，這是兩門冷門語言，甚至進不了編程語言排行榜前100。

這樣的冷門語言還想搞事情？

馬克思告訴我們，要用發展的眼光看問題。所以在正式開始之前，我們來回顧一些行業的發展歷程：

1. 汽車：方向盤→轉向助力→自動擋→無人駕駛？
2. 計算設備：計算機→微機→移動設備
3. 系統界面：命令行（一維）→圖形界面（二維）→VR？
4. 輸入設備：鍵盤→滑鼠→觸摸屏
5. 輸入法：五筆→智能全拼→搜狗拼音等（and手寫輸入？）

以上這些，揭示了行業發展，尤其是計算機行業的發展趨勢→易用性。那麼，在編程語言的世界裡，易用性帶來過什麼樣的變化呢？

1、VB和Delphi帶來的可視化編程熱潮

2、近幾年Python的崛起

看到這裡，很多同學可能忍不住要為Python鼓掌了，手先放下，我們來看張圖。

（圖片來源：RedMonk http://redmonk.com/dberkholz/2013/03/25/programming-languages-ranked-by-expressiveness/）

這張圖反映了編程語言的表現力排行，從左到右表現力遞減。排名1、2位的是Linux下的工具語言，而排名第3的正是Rebol語言。可以說Rebol是這份表單上表現力最強的通用型編程語言，而更高的表現力帶來的正是更好的易用性。

熱愛Python的同學可能要不服氣了：Python的代碼明明已經很精簡了，憑什麼排的這麼靠後？

首先，我不是很喜歡僅憑代碼行數來判斷一門語言是否簡潔，Python所用的行數少，很大程度上歸功於豐富的庫資源。當然，Python在語言設計方面確實有諸多優點，只可惜，做的還不夠。

不信，拉出來溜溜……

Python里讀取一個文件大概是這樣的：

f = open(/tmp/test.txt)f.read()

Python里讀取網頁內容大概是這樣的：

import requestscontent=requests.get(url).content

而在Rebol里，讀取文件和讀取網頁內容是這樣的：

f: read %./tmp/test.txtcontend: read https://www.baidu.com

前面說了，我們不要比較行數，我們只比較語言的設計。在漢語中，讀取文件和讀取網頁內容都是符合「讀取+對象」這種結構的謂賓短語，而在Python中，讀取文件使用了open和read，而讀取網頁甚至需要import一個庫。在Rebol中，read對應了「讀取」，後面跟著的參數則是要讀取的對象（Rebol似乎很符合自然語言的語言習慣？）。

當然，很多同學會說，Python里完全可以寫一個類似的函數，判斷對象類型，然後調用對應的函數。這當然可以，但我們討論的是語言的原生設計不是？

Python為什麼需要人工判斷讀取對象的類型呢？僅從上述的例子來看，Python中無論是open( )還是requests.get( )，參數的類型都是字元串，至於字元串里是文件地址還是網址，Python可不會管這麼多。

而在Rebol中，情況卻不太一樣，以「%」開頭的表示這是一個文件或者文件夾，包含「://」則表示這是一個網址，同一個函數可以很簡單地判斷參數類型，進而決定要執行的操作。

對比一下，Python3中共有6種標準數據類型，而Rebol3中內置了56種不同的數據類型（喪心病狂……）。

看到這裡，肯定有同學要說了：數據類型這麼多，要記住豈不是很費勁，有這功夫函數名我都背全了。

這就回到了本文的題目——人性化設計，一個好的設計可以讓使用者完全依靠本能和直覺，就能很好的理解和使用產品。

下面列舉一些Rebol里的數據類型：

0 integer！ 整數類型，不然咧

$0 money! 錢數類型，相當於長整數，誰不希望錢多多呢？

0.0 decimal！ 小數類型，Red語言中為float！

0.0.0 tuple！ 元組類型

0x0 pair! 數對類型

#"a" char! 字元類型

"abc" string！ 字元串類型

https://www.baidu.com url! 統一資源定位符，網址類型

xxx@163.com email! 郵箱類型

[ 1 2 「3」 ] block! 方塊類型，類似於數組，無類型限制

<tag> tag! 標籤類型

Rebol里各個數據類型主要依靠符號和其自身格式進行區分，並且充分考慮了使用者的常識，實現一種「人機共識」的設計。對於使用者來說，基本上做到了你看到一組數據，你認為它是什麼類型的，那麼它就是什麼類型。由於這種基於常識的人性化設計，Rebol中雖然數據類型很多，但事實上學習成本基本為0。

而這眾多的數據類型帶來的好處就是，簡化、合併了操作各種數據類型的函數，把類型判斷更多地交給解釋器或者編譯器來完成，進而降低了語言本身的學習成本。可以說Rebol是一種更智能，更易學的編程語言。

Rebol的人性化設計不僅僅止步於此，由於Rebol起源於Lisp家族，傳承了代碼和數據的同像性，也就是代碼即數據，數據即代碼。大概也是由於這個原因，Rebol對於統一和簡化數據的操作有著獨到的心得。

Rebol中集合類型的數據類型主要有series!和object!，其中series!又可分為block!paren! string! file! url! path! lit-path! set-path! vector!hash!binary!tag!email!image!，看名稱大概就能猜到各自代表的數據類型。對集合類型的數據進行操作，需要一種層級表示方式操作集合內的元素，例如Python中，統一用「集合[x]」的形式操作集合內的數據。而Rebol更進了一步，為了降低學習成本，Rebol借鑒了更為廣泛使用的層級表示方式。

在Unix/Linux/URL中，路徑的分隔採用正斜杠「/」，而在Windows系統中路徑的分隔採用反斜杠「」，為了統一操作，Rebol採用了前一種方案，並引入到集合類型的操作中。

可以看到，Rebol中可以通過「集合/序號」的形式獲取集合中的元素，通過「對象/鍵名」的形式獲取對象類型中的元素，並可進行操作。為了便於操作，除了通過序號獲取元素之外，在一些特定類型中，還有其他的操作方式。例如在圖像類型中，可採用更便捷的pair!類型來獲取元素，而在時間類型中，可分別用hour、minute、second獲取時、分、秒的數值。

通過這樣一種零學習成本的人性化設計，Rebol用「路徑」的形式，統一解釋了磁碟文件、網路資源、代碼、數據的層級結構，能夠讓使用者更好地理解和操作Rebol代碼，甚至是Rebol本身。

在Rebol和Red中，通過內建的VID方言，能夠快速地構建GUI，例如在Red中（目前Red的VID更為簡潔，此處以Red為例），一個簡單的「Hello world」窗口代碼如下：

按下回車，你看到的窗口大概是這樣的（不同操作系統有不同的窗口風格）：

這裡我們不討論語言的簡潔性，Red如此簡潔是因為它採用了大量的默認參數。我們來看看這個窗口的實現形式。

後面還有很多，先看這一部分，原來這個窗口作為數據，在Red中的實現形式也是一個object！。接著往下翻，可以看到：

同樣，後面還有很多……這裡我們看到，窗口的各個組件存放在一個叫pane的block！里，而組件本身則是一個個object！。我們試著在console輸入以下代碼：

按下回車，可以看到窗口的文字發生了改變：

當然，在VID中有更便捷的操作GUI組件的方式，這裡僅用於分析Rebol/Red的代碼結構。事實上，Rebol和Red中，object！和block！的運用超乎你的想像。

Rebol/Red中，配置信息和標準庫等都存放在一個叫system的object！中，例如system/words中存放了各種數據類型和各個函數的定義。

為了避免命名衝突，Rebol/Red中有一個context-語境的概念，類似於namespace。在context內部，各個變數可以互相直接調用，而在context外部，則需要用路徑的形式調用。是不是和object！很像？事實上context就是一個object！。

當你打開console輸入代碼的時候，其實你是在一個user語境中進行操作，也就是說，你看到的命令行界面，也是一個object！。

作為一個腳本語言，Rebol實現了跨平台，同一份代碼無需修改，在不同的平台上通過解釋執行，得到的結果完全一致，在2004年的時候Rebol支持的平台數量就達到了43個。

而現在，Red語言更進一步，試圖把Rebol這種人性化的設計帶入到系統級編程當中。通過內建Red/System方言，在保持與Red語言的語法高度一致的情況下，實現了與C語言同級別的運行效率。（目前Red/System在無優化的情況下，比C慢5倍或者更多）

而在做到這些的同時，Rebol和Red保持了極小的體積，Rebol<1M，Red<2M，下載後直接使用，零安裝，零配置，完全人性化的設計。

目前，Red發布了0.63版本，距離正式的1.0版本還有著一段距離，並且開發相當緩慢，多次跳票。近期Red發布了區塊鏈開發工具Red/C3的開發計劃，並發起ICO，目前籌到的ETH市值已超過2億人民幣，希望以此為契機，加快Red開發，給編程的世界帶來一點新鮮空氣，讓編程回歸簡潔，回歸人性。

人生苦短，你用Python……

↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓

高能預警，下面的都是廢話

1、人人學編程是個偽命題？

20年前，打字員是一個高端大氣上檔次的職業，那時候中國的絕大多數人都沒見過電腦，人民日常通訊用的更多的還是信件，那時候的人需要學打字嗎？信息化已經極大地改變了人類社會，而編程語言是實現這一過程的重要工具。當前編程世界已經給各行各業帶來了許多方便、快捷的軟體，但事實上，更多的創造性的工作不應受限於這些軟體。學習編程，能夠進一步催化各個專業項目上的創新。

2、Rebol這麼易學易用，為什麼這麼多年都沒流行起來

因為Rebol有很多缺點，例如效率低、沒有多線程……

但是，我可能要以最壞的惡意去揣測計算機行業，這個行業大概是人類有史以來最賺錢的行業，催生了微軟、蘋果這類巨頭企業和一個個富豪。而Rebol沒能流行起來，可能就是因為它的易學易用。

前面提到了VB帶來過可視化編程的熱潮，然後，退潮了……

1991年4月，微軟推出VB1.0，這時候的Windows系統版本號為3.0，當時的操作系統市場上，群狼環繞，前有蘋果的麥金塔電腦，後有Rebol作者開發的Amiga。為了能在圖形界面操作系統的競爭中勝出，微軟需要構建一個更好的軟體生態系統，於是有了VB。

1998年，微軟推出VB6.0之後，便不再更新。此時微軟已經統治了個人操作系統市場，由此催生的軟體行業也成為了既得利益者，而這個行業的門檻主要是技術壁壘。

在封建統治時代，統治者採用的是愚民政策，焚書坑儒、文言文、八股文，都是統治階級設置的階級壁壘。即使到了近代，在推廣白話文的時候，還有許多秀才提出反對。

話又說回Python，近幾年逐漸火了起來，要知道它比Rebol還要老上5年。直到現在，在軟體行業，Python似乎更多地還是充當一個原型語言的角色（我對Python不熟，很可能錯了）。

3、那麼Red有機會火起來嗎？

機會嘛，肯定是有的，全棧公司目前挑選了區塊鏈應用作為突破，並籌到了不少資金。這個暫且不談，我們來探討一下Red作為開源語言，應該尋找怎樣的突破口。

首先，一門語言能不能火，很大程度上依賴商業公司的推動。而平台類型的商業公司更多地通過流量變現，對技術壁壘的依賴較小，甚至需要簡單可行的編程工具。一個簡單的例子，微信小程序，最近又搞出了微信小遊戲，採用的就是HTML5這種門檻低，易學易用的解決方案。將來Red可以嘗試在這一方面尋求突破。

當然，對於Red來說，現在更重要的是儘快達到1.0。

預祝Red/3C在區塊鏈領域嶄露頭角。

Rebol官網：REBOL Language

Red官網：www.red-lang.org （需要科學上網）

Red中文主站：Red 編程語言