1. 第一天，計算機誕生了

　　計算機剛誕生的那會兒，是沒有C#、C++、C等高級語言的，甚至沒有匯編，CPU所唯一能夠理解的就是一連串的二進制流，類似如下：

　　10010100010100101

　　10011001101101011

　　這就是最原始的"程序"，其中1表示高電平(或者其他類似的東西)，0表示低電平(或者其他類似的東西)，CPU能讀懂它，并相應的執行一些最原始、最基本如“進位”的操作，至于CPU是如何實現這種操作的，那屬于電氣工程師的范圍，我們的程序員之旅，就以此做為出發點。

　　直到現在，CPU所能夠唯一理解的仍是一連串的二進制流。

　　至于為什么，那已經不屬于軟件的范圍。

　　2. 第二天，程序員說，二進制太麻煩了，于是世界上便有了匯編

　　隨著光陰的流逝，越來越多的人參與了為計算機編寫運行邏輯的工作(編程)，越來越多的人覺得記住那些生澀的0和1是一項令人糾結的工作，于是···這個世界上便有了匯編語言。

　　基本上，匯編語言命令與二進制是一一對應的，他們聯系十分緊密。

　　例如函數調用的 call 指令，對應著二進制的 01010110100 (這個數字是我亂寫的，只為舉例)。

　　這個時候，編譯器也第一次出現了。

　　何謂編譯器? 那時編譯器就是 把 匯編指令轉換為對應二進制流的小工具。

　　值得提出的是，匯編語言，是不能夸平臺的，不能在不同架構的CPU上運行。

　　CPU的架構? 就是不同的CPU能夠識別的二進制流，一般的，不同架構的CPU能夠識別的二進制流是不一樣的。

　　3. 第三天，程序員說，我們要跨平臺，于是高級語言出現了

　　匯編對于二進制的流好處是，把令人崩潰的0和1轉換成了簡單好記的英文字符。

　　匯編有一個最大的缺陷，就是無法跨越平臺，因為通常匯編命令與二進制的流有緊密的對應關系。

　　很可能在A CPU 上進位的指令是 000000001 (數字是亂寫的)。

　　而在B CPU上進位的指令是 111111111(數字也是亂寫的)。

　　那么為A CPU編寫的匯編程序，無法在B上運行，即使有源代碼也不行，因為匯編與二進制的聯系太過緊密，給人靈活的空間太少。

　　于是高級語言便誕生了，其中影響最大的莫過于C。

　　高級語言最大的貢獻，莫過于抽象了完成任務的方式。

　　在以前，用匯編語言，我們的思維方式是 用XXX指令把XXX數值放在地址為XXX的內存上。

　　現在在高級語言中，我們的思維方式是聲明一個變量，然后給它賦值。

　　高級語言的工作方式，更像是一個簡明、高效的指導手冊，它告訴你該如何去做，只要你達到目的就行，無論你是如何實現的。

　　注意：直到現在，CPU所唯一能理解只有二進制的流，也就是說CPU并不理解所謂的高級語言，也不能運行那些高級語言。

　　那高級語言是如何使CPU運作起來的呢? 很簡單，把它轉換成二進制的流。

　　前面說過，高級語言就像是一本指導手冊，告訴你該如何去做，卻不管你是如何實現，而使用這本指導手冊的就是編譯器，正是從這個時期開始，編譯器變得越來越重要，越來越，嗯~ 變態~

　　高級語言說定義一個變量，然后給它賦值 –> 這個語意是與機器無關的。

　　編譯器聽從它的指示，如果是要為A CPU 產生程序，它就用A所能識別的匯編指令編寫指令。

　　使用 XXX 指令把XXXX賦值給XXXX地址上的內存 –> 這個語意是與機器有關的。

　　如果是要為B CPU產生程序，它就用B所能識別的匯編指令編寫指令。

　　使用 XXX指令把XXXX賦值給XXXX地址上的內存 –> 這個語意是與機器有關的。

　　注意：由于匯編與二進制的流的聯系是如此的緊密，所以便把它們當成是同一個對象，下文出現的也是如此。

　　第3.1天 C只是高級語言之一

　　對于許多程序員而言，從一開始進入這個領域，都是與C家族結緣，甚至一輩子，都在使用C家族的語言，這沒什么大不了，C語言足夠優秀，但有時，這也會阻礙我們看世界的眼光。

　　高級語言唯一的任務就是，提供一個唯一的、無歧義的、足夠清晰的語意讓編譯器去理解，去使用匯編代碼實現那個語意。

　　何謂“唯一的、無歧義的、足夠清晰的語意？”

　　判斷的標準，隨著技術的進步而不同。

　　在當前的技術條件下(耶穌歷2010年，共和國歷61年)。

　　“定義一個int類型的變量，并把它賦值為1"，這是一個唯一、無歧義、足夠清晰的語意。

　　“給我編譯一個論壇搶SF的機器人吧~”，這不是一個唯一、無歧義、足夠清晰的語意。

　　不要被C的語意表述方法所局限，我曾有幸見識過一些COBOL語言的代碼，當時給我的感覺，就像是觸電… …

　　同樣在第三天發生的事情。

　　第三天，一切都變得前所未有的好起來，一切又都變得前所未有的糟糕起來。

　　編程的效率已經大大提高了，越來越多的大型項目卻陷入了泥潭。

　　庫，框架，等概念，開始萌芽......

　　程序員們，陷入了思考......

　　程序員說，我們需要一個更聰明的編譯器

　　于是這個世界上，便有了能替我們做更多的編譯器......

　　面對對象的思想開始出現，并迅速的成為潮流，一大推面對對象的編程語言開始出現......

　　其實，這一切的一切，只不過是編譯器的一個把戲，具體的實現，可以參看本人的另一篇博文。

　　有必要的提示:

　　很多時候，真相需要時間才能夠被看清，當我們回顧歷史的時候，經常一眼就看穿前人所犯下的錯誤，這并不是因為我們比那些先驅者更明智，而是因為我們經過了時間的積淀，一切浮華、虛假、謊言都是經不起時間的考驗的。

　　同樣的，生活在我們這個時代的人，也很容易被這個時代的一些東西所困惑。

　　面對對象只是開發軟件的一個方法之一，盡管它是多么的優秀，多么的高效，但它不是神，只是可選的方案之一，任何多余的崇拜或鄙夷，都會使得你心生抵觸，錯過一個又一個看清真相的機會。

　　4. 第四天的成功者之一 C++

　　完全兼容C是C++的成功原因之一。

　　不知是C++兼容C的原因，還是C++本身的原因。

　　C++是一種給人無限可能的語言。

　　同時，也是一門讓人看清真相的語言。

　　盡管，有時候··它的語法很讓人糾結，但還是有必要去了解一下。

　　5. 第五天 不完美的補償

　　還記得Java那句激動人心的口號嗎？

　　“一次編譯，處處運行”

　　這個口號曾經令多少人興奮到夜不能寐，即使所謂的“一次編譯，處處運行”已經變成了現在的"一次編譯，處處調試"，但我想很多人依然記得第一次接觸Java時的那種感嘆，雖然我沒有那個親身的經歷(我是一個C#er :-) )，但我能明白那種感覺。

　　其實，這只是對當初犯錯的一個補償。

　　據說Java的運行，就是在操作系統上加一層虛擬機，抽象掉操作系統的細節。

　　我們犯了一個錯，在操作系統興起的時候，沒有定義統一的、抽象的操作系統功能接口，如果當初那么做了，事情會簡單許多許多!

　　如今不同操作系統之間的隔閡，已經成為割裂程序界的一道巨大傷疤。

　　聰明的程序員，試圖彌補這些，于是便出現了Java，出現了虛擬機，并在這條路上，越走越遠。

　　不去談論java與C#之間的優劣，是一個明智的選擇。

　　而且我完全不懂Java，也沒有那個資格去談論。

　　本博的主要目的，就是談論.NET在第四天所做的事情，于是就不在此多說。

　　唯一要說明的是.NET不只是一個虛擬機~，它還有更多，更讓人驚訝的特性。

　　最后，程序員不是上帝。

　　若要崇拜，迷信某樣東西，那它必須足夠強大，足夠神秘，完全超過人類的認知范圍。

　　很顯然，程序員不是上帝，他很普通，平凡，甚至許多時候很自負。

　　因此，我們并不需要去迷信，去崇拜程序員創造出的世界。

　　試圖去了解它，不要心懷畏懼。

　　一切都會呈現在你面前。

　　only_lonely 原創 轉載請注明出處