類型是了解編程語(yǔ)言的重要一環(huán)。就算是你喜歡動(dòng)態(tài)類型語(yǔ)言，為了想實(shí)現(xiàn)一個(gè)靠譜的東西，那也必須了解類型。舉個(gè)簡(jiǎn)單的例子，我們都知道+和-是對(duì)稱的——當(dāng)然這只是我們的愿望了，在javascript里面，"1"+2和"1"-2就不是一回事。這就是由于不了解類型的操作而犯下的一些滑稽的錯(cuò)誤。什么，你覺(jué)得因?yàn)?1"的類型是string所以"1"+2就應(yīng)該是"12"？啐！"1"的類型是(string | number)，這才是正確的做法。

了解編程語(yǔ)言的基本原理并不意味著你一定要成為一名編譯器的前端，正如同學(xué)習(xí)Haskell可以讓你的C++寫得更好一樣，如果你知道怎么設(shè)計(jì)一門語(yǔ)言，那遇到語(yǔ)言里面的坑，你十有八九可以當(dāng)場(chǎng)看到，不會(huì)跳進(jìn)去。當(dāng)然了，了解編程語(yǔ)言的前提是你是一個(gè)優(yōu)秀的程序員，至少要寫程序，對(duì)吧。于是我這里推薦幾門語(yǔ)言是在此之前要熟悉的。編程語(yǔ)言有好多種，每一種都有其代表作，為了開開眼界，知道編程語(yǔ)言可以設(shè)計(jì)成什么樣子，你至少應(yīng)該學(xué)會(huì)：

1. C++
2. C#
3. F#
4. Haskell
5. Ruby
6. Prolog

其實(shí)這一點(diǎn)也不多，因?yàn)橹皇菍W(xué)會(huì)而已，知道那些概念就好了，并不需要你成為一個(gè)精通xx語(yǔ)言的人。那為了了解類型你應(yīng)該學(xué)會(huì)什么呢？沒(méi)錯(cuò)——就是C++了！很多人可能不明白，為什么長(zhǎng)得這么難看的C++竟然有這么重要的作用呢？其實(shí)如果詳細(xì)了解了程序設(shè)計(jì)語(yǔ)言的基本原理之后，你會(huì)發(fā)現(xiàn)，C++在除了兼容那個(gè)可憐的C語(yǔ)言之外的那些東西，是設(shè)計(jì)的非常科學(xué)的。當(dāng)然現(xiàn)在講這些還太早，今天的重點(diǎn)是類型。

如果你們?nèi)タ聪嚓P(guān)的書籍或者論文的話，你們會(huì)發(fā)現(xiàn)類型這個(gè)領(lǐng)域里面有相當(dāng)多的莫名其妙的類型系統(tǒng)，或者說(shuō)名詞。對(duì)于第一次了解這個(gè)方面的人來(lái)說(shuō)，熟練掌握Haskell和C++是很有用的，因?yàn)镠askell可以讓你真正明白類型在程序里面的重要做喲的同時(shí)。幾乎所有流行的東西都可以在C++里面找到，譬如說(shuō)：

1. 面向?qū)ο?#8594;class
2. polymorphic type→template
3. intersection type→union / 函數(shù)重載
4. dependent type→帶數(shù)字的模板類型
5. System F→在泛型的lambda表達(dá)式里面使用decltype（看下面的例子）
6. sub typing的規(guī)則→泛型lambda表達(dá)式到函數(shù)指針的隱式類型轉(zhuǎn)換

等等等等，因有盡有，取之不盡，用之不竭。你先別批判C++，覺(jué)得他東西多所以糟糕。事實(shí)是，只要編譯器不用你寫，那一門語(yǔ)言是不可能通過(guò)拿掉feature來(lái)使它對(duì)你來(lái)說(shuō)變得更牛逼的。不知道為什么有那么多人不了解這件事情，需要重新去念一念《形式邏輯》，早日爭(zhēng)取做一個(gè)靠譜的人。

泛型lambda表達(dá)式是C++14（沒(méi)錯(cuò)，是14，已經(jīng)基本敲定了）的內(nèi)容，應(yīng)該會(huì)有很多人不知道，我在這里簡(jiǎn)單地講一下。譬如說(shuō)要寫一個(gè)lambda表達(dá)式來(lái)計(jì)算一個(gè)容器里所有東西的和，但是你卻不知道容器和容器里面裝的東西是什么。當(dāng)然這種情況也不多，但是有可能你需要把這個(gè)lambda表達(dá)使用在很多地方，對(duì)吧，特別是你#include <algorithm>用了里面超好用的函數(shù)之后，這種情況就變得常見了。于是這個(gè)東西可以這么寫：

auto lambda = [](const auto& xs)
{
    decltype(*xs.begin()) sum = 0;
    for(auto x : xs)
    {
        sum += x;
    }
    return sum;
};

于是你就可以這么用了：

vector<int> a = { ... };
list<float> b = { ... };
deque<double> c = { ... };

int sumA = lambda(a);
float sumB = lambda(b);
double sumC = lambda(c);

然后還可以應(yīng)用sub typing的規(guī)則把這個(gè)lambda表達(dá)式轉(zhuǎn)成一個(gè)函數(shù)指針。C++里面所有中括號(hào)不寫東西的lambda表達(dá)式都可以被轉(zhuǎn)成一個(gè)函數(shù)指針的，因?yàn)樗緛?lái)就可以當(dāng)成一個(gè)普通函數(shù)，只是你為了讓業(yè)務(wù)邏輯更緊湊，選擇把這個(gè)東西寫在了你的代碼里面而已：

doube(*summer)(const vector<double>&);
summer = lambda;

只要搞明白了C++之后，那些花里胡俏的類型系統(tǒng)的論文的概念并不難理解。他們深入研究了各種類型系統(tǒng)的主要原因是要做系統(tǒng)驗(yàn)證，證明這個(gè)證明那個(gè)。其實(shí)編譯器的類型檢查部分也可以當(dāng)成是一個(gè)系統(tǒng)驗(yàn)證的程序，他要檢查你的程序是不是有問(wèn)題，于是首先檢查系統(tǒng)。不過(guò)可惜的是，除了Haskell以外的其他程序語(yǔ)言，就算你過(guò)了類型系統(tǒng)檢查，也不見得你的程序就是對(duì)的。當(dāng)然了，對(duì)于像javascript這種動(dòng)態(tài)類型就罷了還那么多坑（ruby在這里就做得很好）的語(yǔ)言，得通過(guò)大量的自動(dòng)化測(cè)試來(lái)保證。沒(méi)有類型的幫助，要寫出同等質(zhì)量的程序，需要花的時(shí)間要更多。什么？你不關(guān)心質(zhì)量？你不要當(dāng)程序員了！是因?yàn)槔习宕叩锰o？我們Microsoft最近有招聘了，快來(lái)吧，可以慢慢寫程序！

不過(guò)正因?yàn)榫幾g器會(huì)檢查類型，所以我們其實(shí)可以把一個(gè)程序用類型武裝起來(lái)，使得錯(cuò)誤的寫法會(huì)變成錯(cuò)誤的語(yǔ)法被檢查出來(lái)了。這種事情在C++里面做尤為方便，因?yàn)樗С謉ependent type——好吧，就是可以在模板類型里面放一些不是類型的東西。我來(lái)舉一個(gè)正常人都熟練掌握的例子——單位。

一、類型檢查（type rich programming）

我們都知道物理的三大基本單位是米、秒和千克，其它東西都可以從這些單位拼出來(lái)（大概是吧，我忘記了）。譬如說(shuō)我們通過(guò)F=ma可以知道力的單位，通過(guò)W=FS可以知道功的單位，等等。然后我們發(fā)現(xiàn)，單位之間的關(guān)系都是乘法的關(guān)系，每個(gè)單位還帶有自己的冪。只要弄清楚了這一點(diǎn)，那事情就很好做了。現(xiàn)在讓我們來(lái)用C++定義單位：

template<int m, int s, int kg>
struct unit
{
    double value;

    unit():value(0){}
    unit(double _value):value(_value){}
};

好了，現(xiàn)在我們要通過(guò)類型系統(tǒng)來(lái)實(shí)現(xiàn)幾個(gè)操作的約束。對(duì)于乘除法我們要自動(dòng)計(jì)算出單位的同時(shí)，加減法必須在相同的單位上才能做。其實(shí)這樣做還不夠完備，因?yàn)閷?duì)于任何的單位x來(lái)講，他們的差單位Δx還有一些額外的規(guī)則，就像C#的DateTime和TimeSpan一樣。不過(guò)這里先不管了，我們來(lái)做出加減乘除幾個(gè)操作：

template<int m, int s, int kg>
unit<m, s, kg> operator+(unit<m, s, kg> a, unit<m, s, kg> b)
{
    return a.value + b.value;
}

template<int m, int s, int kg>
unit<m, s, kg> operator-(unit<m, s, kg> a, unit<m, s, kg> b)
{
    return a.value - b.value;
}

template<int m, int s, int kg>
unit<m, s, kg> operator+(unit<m, s, kg> a)
{
    return a.value;
}

template<int m, int s, int kg>
unit<m, s, kg> operator-(unit<m, s, kg> a)
{
    return -a.value;
}

template<int m1, int s1, int kg1, int m2, int s2, int kg2>
unit<m1+m2, s1+s2, kg1+kg2>operator*(unit<m1, s1, kg1> a, unit<m2, s2, kg2> b)
{
    return a.value * b.value;
}

template<int m1, int s1, int kg1, int m2, int s2, int kg2>
unit<m1-m2, s1-s2, kg1-kg2>operator/(unit<m1, s1, kg1> a, unit<m2, s2, kg2> b)
{
    return a.value / b.value;
}

但是這個(gè)其實(shí)還不夠，我們還需要帶單位的值乘以或除以一個(gè)系數(shù)的代碼。為什么不能加減呢？因?yàn)椴煌瑔挝坏臇|西本來(lái)就不能加減。系數(shù)其實(shí)是可以描寫成unit<0, 0, 0>的，但是為了讓代碼更緊湊，于是多定義了下面的四個(gè)函數(shù)：

template<int m, int s, int kg>
unit<m, s, kg> operator*(double v, unit<m, s, kg> a)
{
    return v * a.value;
}

template<int m, int s, int kg>
unit<m, s, kg> operator*(unit<m, s, kg> a, double v)
{
    return a.value * v;
}

template<int m, int s, int kg>
unit<m, s, kg> operator/(double v, unit<m, s, kg> a)
{
    return v / a.value;
}

template<int m, int s, int kg>
unit<m, s, kg> operator/(unit<m, s, kg> a, double v)
{
    return a.value / v;
}

我們已經(jīng)用dependent type之間的變化來(lái)描述了帶單位的量的加減乘除的規(guī)則。這看起來(lái)好像很復(fù)雜，但是一旦我們加入了下面的新的函數(shù)，一切將變得簡(jiǎn)單明了：

constexpr unit<1, 0, 0> operator""_meter(double value)
{
    return value;
}

constexpr unit<0, 1, 0> operator""_second(double value)
{
    return value;
}

constexpr unit<0, 0, 1> operator""_kilogram(double value)
{
    return value;
}

constexpr unit<1, -2,1> operator""_N(double value) // 牛不知道怎么寫-_-
{
    return value;
}

constexpr unit<2, -2,1> operator""_J(double value) // 焦耳也不知道怎么寫-_-
{
    return value;
}

然后我們就可以用來(lái)寫一些神奇的代碼了：

auto m = 16_kilogram; // unit<0, 0, 1>(16)
auto s = 3_meter; // unit<1, 0, 0>(3)
auto t = 2_second; // unit<0, 1, 0>(2)
auto a = s / (t*t); // unit<1, -2, 0>(3/4)
auto F = m * a; // unit<1, -2, 1>(12)

下面的代碼雖然也神奇，但因?yàn)檫`反了物理定律，所以C++編譯器決定不讓他編譯通過(guò)：

auto W = F * s; // unit<2, -2, 1>(36)
auto x = F + W; // bang!

這樣你還怕你在物理引擎里面東西倒騰來(lái)倒騰去然后公式手抖寫錯(cuò)了嗎？類似的錯(cuò)誤是不可能發(fā)生的！除非系數(shù)被你弄錯(cuò)了……如果沒(méi)有unit，要用原始的方法寫出來(lái)：

double m = 16;
double s = 3;
double t = 2;
double a = s / (t*t);
double F = m * a;
double W = F * s;
double x = F + W; //????

時(shí)間過(guò)得久了以后，根本不知道是什么意思了。所以為了解決這個(gè)問(wèn)題，我們得用應(yīng)用匈牙利命名法（這個(gè)不是那個(gè)臭名昭著的你們熟悉的傻逼（系統(tǒng)）匈牙利命名法）。我舉個(gè)例子：

string dogName = "kula";
Person person;
person.name = dogName;

這個(gè)代碼大家一看就知道不對(duì)對(duì)吧，這就是應(yīng)用匈牙利命名法了。我們通過(guò)給名字一個(gè)單位——狗的——來(lái)讓person.name = dogName;這句話顯得很滑稽，從而避免低級(jí)錯(cuò)誤的發(fā)生。上面的unit就更進(jìn)一步了，把這個(gè)東西帶進(jìn)了類型系統(tǒng)里面，就算寫出來(lái)不滑稽，編譯器都會(huì)告訴你，錯(cuò)誤的東西就是錯(cuò)誤的。

然后大家可能會(huì)問(wèn)，用unit這么寫程序的性能會(huì)不會(huì)大打折扣呀？如今已經(jīng)是2013年了，靠譜的C++編譯器編譯出來(lái)的代碼，跟你直接用幾個(gè)double倒騰來(lái)倒騰去的代碼其實(shí)是一樣的。C++比起其他語(yǔ)言的抽象的好處就是，就算你要用來(lái)做高性能的程序，也不怕因?yàn)槌橄蠖鴨适阅堋．?dāng)然如果你使用了面向?qū)ο蟮募夹g(shù)，那就另當(dāng)別論了。

注，上面這段話我寫完之后貼到了粉絲群里面，然后九姑娘跟我講了很多量綱分析的故事，然后升級(jí)到航空領(lǐng)域的check list，最后講到了醫(yī)院把這一技術(shù)引進(jìn)了之后有效地阻止了手術(shù)弄錯(cuò)人等嚴(yán)重事故。那些特別靠譜的程序還得用C++來(lái)寫，譬如說(shuō)洛克希德馬丁的戰(zhàn)斗機(jī)，NASA的衛(wèi)星什么的。

人的精力是有限的，需要一些錯(cuò)誤規(guī)避來(lái)防止引進(jìn)低級(jí)的錯(cuò)誤或者負(fù)擔(dān)，保留精力解決最核心的問(wèn)題。很多軟件都是這樣的。譬如說(shuō)超容易配置的MSBuild、用起來(lái)巨爽無(wú)比的Visual Studio，出了問(wèn)題反正用正版安裝程序點(diǎn)一下repair就可以恢復(fù)的windows，給我們帶來(lái)的好處就是——保留精力解決最核心的問(wèn)題。編程語(yǔ)言也是如此，類型系統(tǒng)也是如此，人類發(fā)明出的所有東西，都是為了讓你可以把更多的精力放在更加核心的問(wèn)題上，更少的精力放在周邊的問(wèn)題上。

但是類型到處都出現(xiàn)其實(shí)也會(huì)讓我們程序?qū)懫饋?lái)很煩的，所以現(xiàn)代的語(yǔ)言都有第二個(gè)功能，就是類型推導(dǎo)了。

二、類型推導(dǎo)

這里講的類型推導(dǎo)可不是Go語(yǔ)言那個(gè)半吊子的:=賦值操作符。真正的類型推導(dǎo)，就要跟C++的泛型lambda表達(dá)式、C#的linq語(yǔ)法糖，或者Haskell的函數(shù)一樣，要可以自己計(jì)算出模板的類型參數(shù)的位置或者內(nèi)容，才能全方位的實(shí)現(xiàn)什么類型都不寫，都還能使用強(qiáng)類型和type rich programming帶來(lái)的好處。C++的lambda表達(dá)式上面已經(jīng)看到了，所以還是從Haskell一個(gè)老掉牙的demo開始講起吧。

今天，我們用Haskell來(lái)寫一個(gè)merge sort：

merge [] [] = []
merge [] xs = xs
merge xs [] = xs
merge (x:xs) (y:ys) = if x<y then x:(merge xs (y:ys)) else y:(merge (x:xs) ys)

mergeSort [] = []
mergeSort xs = merge (mergeSort a) (mergeSort b)
    where
        len = length xs
        a = take $ len `div` 2 $ xs
        b = drop $ len - len `div` 2 $ xs

我們可以很清楚的看出來(lái)，merge的類型是[a] –> [a] –> [a]，mergeSort的類型是[a] –> [a]。到底編譯器是怎么計(jì)算出類型的呢？

1. 首先，[]告訴我們，這是一個(gè)空列表，但是類型是什么不知道，所以他是forall a –> [a]。所以merge [] [] = []告訴我們，merge的類型至少是[a] –> [b] –> [c]。
2. 其次，merge []  xs = xs告訴我們，merge的類型至少是[d] –> e –> e。這個(gè)類型跟[a]->[b]->[c]求一個(gè)交集就會(huì)得到merge的更準(zhǔn)確的類型：[a] –> [b] –> [b]。
3. 然后，merge xs [] = []告訴我們，merge的類型至少是f –> [g] –> f。這個(gè)類型跟[a] –> [b] –> [b]求一個(gè)交集就會(huì)得到merge的更準(zhǔn)確的類型：[a] –> [a] –> [a]。
4. 最后看到那個(gè)長(zhǎng)長(zhǎng)的式子，根據(jù)一番推導(dǎo)之后，會(huì)發(fā)現(xiàn)[a]->[a]->[a]就是我們要的最終類型了。
5. 只要把相同的技術(shù)放在mergeSort上面，就可以得到mergeSort的類型是[a]->[a]了。

當(dāng)然對(duì)于Haskell這種Hindley-Milner類型系統(tǒng)來(lái)說(shuō)，只要我們?cè)诖a里面計(jì)算出所有類型的方程，然后一個(gè)一個(gè)去解，最后就可以收斂到一個(gè)最準(zhǔn)確的類型上面了。倘若我們?cè)诘臅r(shí)候發(fā)現(xiàn)收斂之后無(wú)解了，那這個(gè)程序就是錯(cuò)的。這種簡(jiǎn)單粗暴的方法很容易構(gòu)造出一些只要人夠蛋定就很容易使用的語(yǔ)言，譬如說(shuō)Haskell。

Haskell看完就可以來(lái)看C#了。C#的linq真是個(gè)好東西啊，只要不把它看成SQL，那很多事情都可以表達(dá)的。譬如說(shuō)是個(gè)人都知道的linq to object啦，后面還有linq to xml，linq to sql，reactive programming，甚至是parser combinator等等。一個(gè)典型的linq的程序是長(zhǎng)這個(gè)樣子的：

var w = 
    from x in xs
    from y in ys
    from z in zs
    select f(x, y, z);

光看這個(gè)程序可能看不出什么來(lái)，因?yàn)閤s、ys、zs和f這幾個(gè)單詞都是沒(méi)有意義的。但是linq的魅力正在這里。如果from和select就已經(jīng)強(qiáng)行規(guī)定了xs、ys、zs和f的意思的話。那可擴(kuò)展性就全沒(méi)有了。因此當(dāng)我們看到一個(gè)這樣的程序的時(shí)候，其實(shí)可以是下面這幾種意思：

W f(X x, Y y, Z z);

var /*IEnumerable<W>*/w = 
    from /*X*/x in /*IEnumerable<X>*/xs
    from /*Y*/y in /*IEnumerable<Y>*/ys
    from /*Z*/z in /*IEnumerable<Z>*/zs
    select f(x, y, z);

var /*IObservable<W>*/w = 
    from /*X*/x in /*IObservable<X>*/xs
    from /*Y*/y in /*IObservable<Y>*/ys
    from /*Z*/z in /*IObservable<Z>*/zs
    select f(x, y, z);

var /*IParser<W>*/w = 
    from /*X*/x in /*IParser<X>*/xs
    from /*Y*/y in /*IParser<Y>*/ys
    from /*Z*/z in /*IParser<Z>*/zs
    select f(x, y, z);

var /*IQueryable<W>*/w =
    from /*X*/x in /*IQueryable<X>*/xs
    from /*Y*/y in /*IQueryable<Y>*/ys
    from /*Z*/z in /*IQueryable<Z>*/zs
    select f(x, y, z);

var /*?<W>*/w = 
    from /*X*/x in /*?<X>*/xs
    from /*Y*/y in /*?<Y>*/ys
    from /*Z*/z in /*?<Z>*/zs
    select f(x, y, z);

相信大家已經(jīng)看到了里面的pattern了。只要你有一個(gè)?<T>類型，而它又支持linq provider的話，你就可以把代碼寫成這樣了。

不過(guò)我們知道，把程序?qū)懗蛇@樣并不是我們編程的目的，我們的目的是要讓程序?qū)懙米尵哂型瑯又R(shí)背景的人可以很快就看懂。為什么要看懂？因?yàn)榭傆幸惶炷銜?huì)不維護(hù)這個(gè)程序的，這樣就可以讓另一個(gè)合格的人來(lái)繼續(xù)維護(hù)了。一個(gè)軟件是要做幾十年的，那些只有一兩年甚至只有半年生命周期的，只能叫垃圾了。

那現(xiàn)在讓我們看一組有意義的linq代碼。首先是linq to object的，求一個(gè)數(shù)組里面出現(xiàn)最多的數(shù)字是哪個(gè)：

var theNumber = (
    from n in numbers
    group by n into g
    select g.ToArray() into gs
    order by gs.Length descending
    select gs[0]
    ).First()

其次是一個(gè)parser，這個(gè)parser用來(lái)得到一個(gè)函數(shù)調(diào)用表達(dá)式：

IParser<FunctionCallExpression> Call()
{
    return
        from name in PrimitiveExpression()
        from _1 in Text("(")
        from arguments in
            many(
                Expression().
                Text(",")
            )
        from _2 in Text(")")
        select new FunctionCallExpression
        {
            Name = name,
            Arguments = arguments.ToArray(),
        };
}

我們可以看到，一旦linq表達(dá)式里面的元素都有了自己的名字，就不會(huì)跟上面的xyz的例子一樣莫名其妙了。那這兩個(gè)例子到底為什么要用linq呢？

第一個(gè)例子很簡(jiǎn)單，因?yàn)閘inq to object就是設(shè)計(jì)來(lái)解決這種問(wèn)題的。

第二個(gè)例子就比較復(fù)雜一點(diǎn)了，為什么好好地parser要寫成這樣呢？我們知道，parser時(shí)可能會(huì)parse失敗的。一個(gè)大的parser，里面的一些小部件失敗了，那么大parser就要回滾，token stream的當(dāng)前光標(biāo)也要回滾，等等需要類似的一系列的操作。如果我們始終都讓這些邏輯都貫穿在整個(gè)parser里面，那代碼根本不能看。于是我們可以寫一個(gè)linq provider，讓SelectMany函數(shù)來(lái)處理所有的回滾操作，然后把parser寫成上面這個(gè)樣子。上面這個(gè)parser的所有的in左邊是臨時(shí)變量，所有的in右邊剛好組成了一個(gè)EBNF文法：

PrimitiveExpression "(" [Expression {"," Expression}] ")"

最后的select語(yǔ)句告訴我們?cè)谒行arser都parse成功之后，如何用parse得到的臨時(shí)變量來(lái)返回一顆語(yǔ)法樹。整個(gè)parsing的代碼就會(huì)非常的容易看懂。當(dāng)然，前提是你必須要懂的EBNF。不過(guò)一個(gè)不懂EBNF的人，又如何能寫語(yǔ)法分析器呢。

那這跟類型推導(dǎo)有什么關(guān)系呢？我們會(huì)發(fā)現(xiàn)上面的所有l(wèi)inq的例子里面，除了函數(shù)簽名以外，根本沒(méi)有出現(xiàn)任何類型的聲明。而且更重要的是，這些類型盡管沒(méi)有寫出來(lái)，但是每一個(gè)中間變量的類型都是自明的。當(dāng)然這有一部分歸功于好的命名方法——也就是應(yīng)用匈牙利命名法了。剩下的部分是跟業(yè)務(wù)邏輯相關(guān)的。譬如說(shuō)，一個(gè)FunctionCallExpression所調(diào)用的函數(shù)當(dāng)然也是一個(gè)Expression了。如果這是唯一的選擇，那為什么要寫出來(lái)呢？

我們可以看到，正是因?yàn)橛辛祟愋屯茖?dǎo)，我們可以在寫出清晰的代碼的同時(shí)，還不需要花費(fèi)那么多廢話來(lái)指定各種類型。程序員都是怕麻煩的，無(wú)論復(fù)雜的方法有多好，他總是會(huì)選擇簡(jiǎn)單的（廢話，用復(fù)雜的那個(gè)不僅要加班修bug，還沒(méi)有漲工資。用簡(jiǎn)單的那個(gè)，先讓他過(guò)了，bug留給下一任程序員去頭疼就好了——某web程序員如是說(shuō)）。類型推導(dǎo)讓type rich programming的程序?qū)懫饋?lái)簡(jiǎn)單了許多。所以我們一旦有了類型推導(dǎo)，就可以放心大膽的使用type rich programming了。

三、大道理

有了type rich programming，就可以讓編譯器幫我們檢查一些模式化的手都會(huì)犯的錯(cuò)誤。讓我們重溫一下這篇文章前面的一段話：

人的精力是有限的，需要一些錯(cuò)誤規(guī)避來(lái)防止引進(jìn)低級(jí)的錯(cuò)誤或者負(fù)擔(dān)，保留精力解決最核心的問(wèn)題。很多軟件都是這樣的。譬如說(shuō)超容易配置的MSBuild、用起來(lái)巨爽無(wú)比的Visual Studio，出了問(wèn)題反正用正版安裝程序點(diǎn)一下repair就可以恢復(fù)的windows，給我們帶來(lái)的好處就是——保留精力解決最核心的問(wèn)題。編程語(yǔ)言也是如此，類型系統(tǒng)也是如此，人類發(fā)明出的所有東西，都是為了讓你可以把更多的精力放在更加核心的問(wèn)題上，更少的精力放在周邊的問(wèn)題上。

這讓我想起了一個(gè)在微博上看到的故事：NASA的員工在推一輛裝了衛(wèi)星的小車的時(shí)候，因?yàn)橥浛碿heck list，沒(méi)有固定號(hào)衛(wèi)星，結(jié)果衛(wèi)星一推倒在了地上摔壞了，一下子沒(méi)了兩個(gè)億的美元。

寫程序也一樣。一個(gè)代表力的變量，只能跟另一個(gè)代表力的變量相加，這就是check list。但是我們知道，每一個(gè)程序都相當(dāng)復(fù)雜，check list需要檢查的地方遍布所有文件。那難道我們?cè)赾ode review的時(shí)候可以一行一行仔細(xì)看嗎？這是不可能的。正因?yàn)槿绱耍覀円殉绦驅(qū)懗?#8220;讓編譯器可以檢查很多我們可能會(huì)手抖犯的錯(cuò)誤”的形式，讓我們從這些瑣碎的事情里面解放出來(lái)。

銀彈這種東西是不存在的，所以type rich programming能解決的事情就是防止手抖而犯錯(cuò)誤。有一些錯(cuò)誤不是手抖可以抖出來(lái)的，譬如說(shuō)錯(cuò)誤的設(shè)計(jì)，這并不是type rich programming能很好地處理的范圍。為了解決這些事情，我們就需要更多可以遵守的best practice了。

當(dāng)然，其中的一個(gè)將是DSL——domain specific language，領(lǐng)域特定語(yǔ)言了。敬請(qǐng)關(guān)注下一篇，《如何設(shè)計(jì)一門語(yǔ)言（十）——DSL與建模》。