這個系列的起因是這樣的，王垠寫了一篇噴go的博客http://www.yinwang.org/blog-cn/2013/04/24/go-language/，里面說go已經(jīng)爛到無可救藥了，已經(jīng)懶得說了，所以讓大家去看http://www.mindomo.com/view.htm?m=8cc4f95228f942f8886106d876d1b041，里面有詳細的解釋。然后這篇東西被發(fā)上了微博，很多博友立刻展示了人性丑陋的一面：
1、那些go的擁護者們，因為go被噴了，就覺得自己的人格受到了侮辱一樣，根本來不及看到最后一段的鏈接，就開始張牙舞爪。
2、王垠這個人的確是跟人合不來，所以很多人就這樣斷定他的東西“毫無參考價值”。

不過說實話，文章里面是噴得有點不禮貌，這也在一定程度上阻止了那些不學無術(shù)的人們繼續(xù)閱讀后面的精華部分。如果所有的文章都這樣那該多好啊，那么爛人永遠都是爛人，不糾正自己的心態(tài)永遠獲得不了任何有用的知識，永遠過那種月入一蛆的日子，用垃圾的語言痛苦的寫一輩子沒價值的程序。

廢話就說到這里了，下面我來說說我自己對于語言的觀點。為什么要設(shè)計一門新語言？原因無非就兩個，要么舊的語言實在是讓人受不了，要么是針對領(lǐng)域設(shè)計的專用語言。后一種我就不講了，因為如果沒有具體的領(lǐng)域知識的話，這種東西永遠都做不好（譬如SQL永遠不可能出自一個數(shù)據(jù)庫很爛的人手里），基本上這不是什么語言設(shè)計的問題。所以這個系列只會針對前一種情況——也就是設(shè)計一門通用的語言。通用的語言其實也有自己的“領(lǐng)域”，只是太多了，所以被淡化了。縱觀歷史，你讓一個只做過少量的領(lǐng)域的人去設(shè)計一門語言，如果他沒有受過程序設(shè)計語言理論的系統(tǒng)教育，那只能做出屎。譬如說go就是其中一個——雖然他爹很牛逼，但反正不包含“設(shè)計語言”這個事情。

因此，在21世紀你還要做一門語言，無非就是對所有的通用語言都不滿意，所以你想自己做一個。不滿意體現(xiàn)在什么方面？譬如說C#的原因可能就是他爹不夠帥啦，譬如說C++的原因可能就是自己智商太低hold不住啦，譬如說Haskell的原因可能就是用的人太少招不到人啦，譬如說C的原因可能就是實在是無法完成人和抽象所以沒有l(wèi)inus的水平的人都會把C語言寫成屎但是你又招不到linus啦，總之有各種各樣的原因。不過排除使用者的智商因素來講，其實有幾個語言我還是很欣賞的——C++、C#、Haskell、Rust和Ruby。如果要我給全世界的語言排名，前五名反正是這五個，雖然他們之間可能很難決出勝負。不過就算如此，其實這些語言也有一些讓我不爽的地方，讓我一直很想做一個新的語言（來給自己用（？）），證據(jù)就是——“看我的博客”。

那么。一個好的語言的好，體現(xiàn)在什么方面呢？一直以來，人們都覺得，只有庫好用，語言才會好用。其實這完全是顛倒了因果關(guān)系，如果沒有好用的語法，怎么能寫出好用的庫呢？要找例子也很簡單，只要比較一下Java和C#就夠了。C#的庫之所以好用，跟他語言的表達能力強是分不開的，譬如說linq（，to xml，to sql，to parser，etc），譬如說WCF（僅考慮易用性部分），譬如說WPF。Java能寫得出來這些庫嗎？硬要寫還是可以寫的，但是你會發(fā)現(xiàn)你無論如何都沒辦法把他們做到用起來很順手的樣子，其實這都是因為Java的語法垃圾造成的。這個時候可以抬頭看一看我上面列出來的五種語言，他們的特點都是——因為語法的原因，庫用起來特別爽。

當然，這并不要求所有的人都應該把語言學習到可以去寫庫。程序員的分布也是跟金字塔的結(jié)構(gòu)一樣的，庫讓少數(shù)人去寫就好了，大多數(shù)人盡管用，也不用學那么多，除非你們想成為寫庫的那些。不過最近有一個很不好的風氣，就是有些人覺得一個語言難到自己無法【輕松】成為寫庫的人，就開始說他這里不好那里不好了，具體都是誰我就不點名了，大家都知道，呵呵呵。

好的語言，除了庫寫起來又容易又好用以外，還有兩個重要的特點：容易學，容易分析。關(guān)于容易學這一點，其實不是說，你隨便看一看就能學會，而是說，只要你掌握了門道，很多未知的特性你都可以猜中。這就有一個語法的一致性問題在里面了。語法的一致性問題，是一個很容易讓人忽略的問題，因為所有因為語法的一致性不好而引發(fā)的錯誤，原因都特別的隱晦，很難一眼看出來。這里我為了讓大家可以建立起這個概念，我來舉幾個例子。

第一個例子是我們喜聞樂見的C語言的指針變量定義啦：

int a, *b, **c;

相信很多人都被這種東西坑過，所以很多教科書都告訴我們，當定義一個變量的時候，類型最后的那些星號都要寫在變量前面，避免讓人誤解。所以很多人都會想，為什么要設(shè)計成這樣呢，這明顯就是挖個坑讓人往下跳嘛。但是在實際上，這是一個語法的一致性好的例子，至于為什么他是個坑，問題在別的地方。

我們都知道，當一個變量b是一個指向int的指針的時候，*b的結(jié)果就是一個int。定義一個變量int a;也等于在說“定義a是一個int”。那我們來看上面那個變量聲明：int *b;。這究竟是在說什么呢？其實真正的意思是“定義*b是一個int”。這種“定義和使用相一致”的方法其實正是我們要推崇的。C語言的函數(shù)定義參數(shù)用逗號分隔，調(diào)用的時候也用逗號分隔，這是好的。Pascal語言的函數(shù)定義參數(shù)用分號分隔，調(diào)用的時候用逗號分隔，這個一致性就少了一點。

看到這里你可能會說，你怎么知道C語言他爹就是這么想的呢？我自己覺得如果他不是這么想的估計也不會差到哪里去，因為還有下面一個例子：

int F(int a, int b);
int (*f)(int a, int b);

這也是一個“定義和使用相一致”的例子。就第一行代碼來說，我們要如何看待“int F(int a, int b);”這個寫法呢？其實跟上面一樣，他說的是“定義F(a, b)的結(jié)果為int”。至于a和b是什么，他也告訴你：定義a為int，b也為int。所以等價的，下面這一行也是“定義(*f)(a, b)的結(jié)果為int”。函數(shù)類型其實也是可以不寫參數(shù)名的，不過我們還是鼓勵把參數(shù)名寫進去，這樣Visual Studio的intellisense會讓你在敲“(”的時候把參數(shù)名給你列出來，你看到了提示，有時候就不需要回去翻源代碼了。

關(guān)于C語言的“定義和使用相一致”還有最后一個例子，這個例子也是很美妙的：

int a;
typedef int a;

int (*f)(int a, int b);
typedef int (*f)(int a, int b);

typedef是這樣的一個關(guān)鍵字：他把一個符號從變量給修改成了類型。所以每當你需要給一個類型名一個名字的時候，就先想一想，怎么定義一個這個類型的變量，寫出來之后往前面加個typedef，事情就完成了。

不過說實話，就一致性來講，C語言也就到此為止了。至于說為什么，因為上面這幾條看起來很美好的“定義和使用相一致”的規(guī)則是不能組合的，譬如說看下面這一行代碼：

typedef int(__stdcall*f[10])(int(*a)(int, int));

這個時候我們再回頭看一看上面那一段長長的函數(shù)指針數(shù)組變量的聲明，會發(fā)現(xiàn)其實在這種時候，C語言還是希望你把它看成“int* b;”的這種形式的：f是一個數(shù)組，數(shù)組返回了一個函數(shù)指針，函數(shù)返回int，函數(shù)的參數(shù)是int(*a)(int, int)所以他還是一個函數(shù)指針。

我們?yōu)槭裁磿X得C語言在這一個知識點上特別的難學，就是因為他同時混用了兩種原則來設(shè)計語法。那你說好的設(shè)計是什么呢？讓我們來看看一些其它的語言的作法：

C++:
function<int __stdcall(function<int(int, int)>)> f[10];

C#:
Func<Func<int, int, int>, int>[] f;

Haskell:
f :: [(int->int->int)->int]

Pascal:
var f : array[0..9] of function(a : function(x : integer; y : integer):integer):integer;

這些語言的做法，雖然并沒有遵守“定義和使用相一致”的原則，但是他們比C語言好的地方在于，他們只采用一種原則——這就比好的和壞的混在一起要強多了（這一點go也是，做得比C語言更糟糕）。

當然，上面這個說法對Haskell來說其實并不公平。Haskell是一種帶有完全類型推導的語言，他不認為類型聲明是聲明的一部分，他把類型聲明當成是“提示”的一部分。所以實際上當你真的需要一個這種復雜結(jié)構(gòu)的函數(shù)的時候，實際上你并不會真的去把它的類型寫出來，而是通過寫一個正確的函數(shù)體，然后讓Haskell編譯器幫你推導出正確的類型。我來舉個例子：

superApply fs x = (foldr id (.) fs) x

關(guān)于foldr有一個很好的理解方法，譬如說foldr 0 (+) [1,2,3,4]說的就是1 + (2 + (3 + (4 + 0)))。而(.)其實是一個把兩個函數(shù)合并成一個的函數(shù)：f (.) g = \x->f(g( x ))。所以上述代碼的意思就是，如果我有下面的三個函數(shù)：

add1 x = x + 1
mul2 x = x * 2
sqr x = x * x

那么當我寫下下面的代碼的時候：

superApply [sqr, mul2, add1] 1

superApply [(\x->x*x), (*2), (+1)] 1

Haskell代碼的簡潔程度真是喪心病狂啊，因為如果我們要用C++來寫出對應的東西的話（C語言的參數(shù)無法是一個帶長度的數(shù)組類型所以其實是寫不出等價的東西的），會變成下面這個樣子：

template<typename T>
T SuperApply(const vector<function<T(T)>>& fs, const T& x)
{
    T result = x;
    for(int i=fs.size()-1; i>=0; i--)
    {
        result = fs[i](result);
    }
    return result;
}

C++不僅要把每一個步驟寫得很清楚，而且還要把類型描述出來，整個代碼就變得特別的混亂。除此之外，C++還沒辦法跟Haskell一樣吧三個函數(shù)直接搞成一個vector然后送進這個SuperApply里面直接調(diào)用。當然有人會說，這還不是因為Haskell里面有foldr嘛。那讓我們來看看同樣有foldr（reverse + aggregate = foldr）的C#會怎么寫：

T SuperApply<T>(Func<T, T>[] fs, T x)
{
    return (fs
        .Reverse()
        .Aggregate(x=>x, (a, b)=>y=>b(a(y)))
        )(x);
}

C#基本上已經(jīng)達到跟Haskell一樣的描述過程了，而且也可以寫出下面的代碼了，就是無論聲明和使用的語法的噪音稍微有點大……

SuperApply(new Func<T, T>[]{
    x=>x*x,
    x=>x*2,
    x=>x+1
    }, 1);

為什么要在討論語法的一致性的時候說這些問題呢，在這里我想向大家展示Haskell的另一種“定義和使用相一致”的做法。Haskell整個語言都要用pattern matching去理解，所以上面的這段代碼

superApply fs x = (foldr id (.) fs) x

superApply [(\x->x*x), (*2), (+1)] 1

(foldr id (.) [(\x->x*x), (*2), (+1)]) 1

(Point x y) + (Point z w) = Point (x+z) (y+w)
(+) (Point x y) (Point z w) = Point (x+z) (y+w)

(Point x y) `Add` (Point z w) = Point (x+z) (y+w)
Add (Point x y) (Point z w) = Point (x+z) (y+w)

斐波那契數(shù)列的簡單形式甚至還可以這么寫：

f 1 = 1
f 2 = 1
f (n+2) = f(n+1) + f(n)

甚至連遞歸都可以寫成：

GetListLength [] = 0
GetListLength (x:xs) = 1 + GetListLength xs

Haskell到處都貫徹了“函數(shù)和操作符的替換關(guān)系”和“pattern matching”兩個原則來做“定義和實現(xiàn)相一致”的基礎(chǔ)，從而實現(xiàn)了一個比C語言那個做了一半的混亂的原則要好得多的原則。

有些人可能會說，Haskell寫遞歸這么容易，那會不會因為鼓勵人們寫遞歸，而整個程序充滿了遞歸，很容易stack overflow或者降低運行效率呢？在這里你可以往上翻，在這篇文章的前面有一句話“好的語言，除了庫寫起來又容易又好用以外，還有兩個重要的特點：容易學，容易分析。”，這在Haskell里面體現(xiàn)得淋漓盡致。

我們知道循環(huán)就是尾遞歸，所以如果我們把代碼寫成尾遞歸，那Haskell的編譯器就會識別出來，從而在生成x86代碼的時候把它處理成循環(huán)。一個尾遞歸遞歸函數(shù)的退出點，要么是一個不包含自身函數(shù)調(diào)用的表達式，要么就是用自身函數(shù)來和其它參數(shù)來調(diào)用。聽起來比較拗口，不過說白了其實就是：

GetListLength_ [] c = c
GetListLength_ (x:xs) c = GetListLength_ xs (c+1)
GetListLength xs = GetListLength_ xs 0

當你寫出這樣的代碼的時候，Haskell把你的代碼編譯了之后，就會真的輸出一個循環(huán)，從而上面的擔心都一掃而空。

實際上，有很多性能測試都表明，在大多數(shù)平臺上，Haskell的速度也不會被C/C++慢超過一倍的同時，要遠比go的性能高出許多。在Windows上，函數(shù)式語言最快的是F#。Linux上則是Scala。Haskell一直都是第二名，但是只比第一名慢一點點。

為了不讓文章太長，好分成若干次發(fā)布，每次間隔都較短，所以今天的坑我只想多講一個——C++的指針的坑。剩下的坑留到下一篇文章里面。下面要講的這個坑，如果不是在粉絲群里面被問了，我還不知道有人會這么做：

class Base
{
  ...
};

class Derived : public Base
{
  ...
};

Base* bs = new Derived[10];
delete[] bs;

我想說，這完全是C++兼容C語言，然后讓C語言給坑了。其實這個問題在C語言里面是不會出現(xiàn)的，因為C語言的指針其實說白了只有一種：char*。很多C語言的函數(shù)都接受char*，void*還是后來才有的。C語言操作指針用的malloc和free，其實也是把他當char*在看。所以當你malloc了一個東西，然后cast成你需要的類型，最后free掉，這一步cast存在不存在對于free能否正確執(zhí)行來說是沒有區(qū)別的。

但是事情到了C++就不一樣了。C++有繼承，有了繼承就有指針的隱式類型轉(zhuǎn)換。于是看上面的代碼，我們new[]了一個指針是Derived*類型的，然后隱式轉(zhuǎn)換到了Base*。最后我們拿他delete[]，因為delete[]需要調(diào)用析構(gòu)函數(shù)，但是Base*類型的指針式不能正確計算出Derived數(shù)組的10個析構(gòu)函數(shù)需要的this指針的位置的，所以在這個時候，代碼就完蛋了（如果沒完蛋，那只是巧合）。

為了兼容C語言，“new[]的指針需要delete[]”和“子類指針可以轉(zhuǎn)父類指針”的兩條規(guī)則成功的沖突到了一起。實際上，如果需要解決這種問題，那類型應該怎么改呢？其實我們可以跟C#一樣引入Derived[]的這種指針類型。這還是new[]出來的東西，C++里面也可以要求delete[]，但是區(qū)別是他再也不能轉(zhuǎn)成Base[]了。只可惜，T[]這種類型被C語言占用了，在函數(shù)參數(shù)類型里面當T*用。C語言浪費語法罪該萬死呀……

待續(xù)