我寫這篇文章以及接下來的一系列文章的目的是希望向國內廣大程式設計師們進行一些程式語言相關的「科普」。說是科普是因為我意識到，對於絕大多數國內的程式設計師來說，他們對於程式語言的認識，隨著專案經驗的增加而增長得非常有限。很多經歷過許多大專案、自稱精通許多程式語言的程式設計師們其實對他們手邊天天使用的語言並沒有乙個甚至基本的了解。他們依賴所謂的「程式設計正規化」、信奉經驗主義、用夜以繼日的加班、過勞來試圖修復他們**中的眾多問題，卻沒有思考過造成這些問題的基本問題，造成問題的問題，就如同描述資料的資料——元資料一樣，這些「元問題」很多時候都能本質上地改變程式設計師的工作強度與工作方式。一旦解決了「元問題」，很多現有的問題將不復存在。
「科普」的另一層含義是在接下來的文章裡我只管介紹，而不會指導你去如何學習，因此你大可抱著看熱鬧的心情去看我接下來的文章，但如果你想要系統地學習它，sorry，我沒有這個能力，你可以閱讀相關的書籍，我的文章可能可以幫助你理解這些問題，但真的要深入了解、掌握程式語言的本質的話，還是需要你自己的努力。
要了解程式語言的本質，最直接的辦法，就是去了解程式語言的直譯器的執行機制。很多人會問，我知道php、python是解釋性語言，可以用直譯器去執行它們的**，但如果是c、c++、objective-c這樣的編譯性語言呢？你的科普是不是就不通用了？
關於這一點，首先我想先闡明乙個事實，沒有一門程式語言可以被稱為「解釋性語言」或者「編譯性語言」，程式語言僅僅是程式設計師和機器之間進行交流的一種規範的、有條理的、形式化的媒介。就好比自然語言是用於人與人之間交流的媒介一樣。所謂的php、python是解釋性語言、c、c++是編譯性語言，只不過是因為它們最主流的實現方式分別是邊解釋邊執行（解釋性，其實這一說法並不嚴密）、以及先編譯後執行（編譯性）。你大可以寫出乙個php的編譯器或者c語言的直譯器（其實這兩種實現都存在），只不過它們不是最主流的實現方式而已。
其次，不管是用gcc、clang去編譯c語言，還是用zend引擎去解釋php，它們在前期的工作都是類似的，都需要逐字逐句地解析程式設計師寫的**，並將其轉換為一種內部的資料結構。所不同的是，在解析完**之後，編譯器會將這一種內部資料結構再次轉換成新的一種**，比如gcc的編譯器將c**轉換為彙編**，因此，編譯的過程本質上就是一種轉換的過程；而直譯器則根據不同的資料結構來指揮機器做不同的工作，直到解釋結束。
在實際的實現中，基於效率問題，多數語言的直譯器都並不直接解釋執行**（包括php和python），而是先將它們轉換為一種便於機器理解、執行的中間**，這本質上也是一種編譯，再去執行。其此，實際上主流的程式語言實現中並不存在純粹的「直譯器」，只有先編譯，稍後執行的直譯器（也就是我們常說的編譯器）；以前先編譯、之後立即執行的直譯器。
其實，學習直譯器的構造對乙個程式設計師的成長來說是很有好處的，除了之前說的，你可以通過學習直譯器來認識程式語言的本質之外，你還可以對你自己現在的或者將來的專案有著更好的掌控。這是因為隨著現代軟體的複雜性不斷提高，很多程式與直譯器已經越來越接近了，使用者與程式互動的過程，就如同**與直譯器互動的過程；程式裡的業務邏輯需要一系列例如生命週期、迭代、狀態記錄、中斷流程與恢復之類的行為的實現，在直譯器內部也有著相應的體現。有時候，你的工程雖然本身並不是乙個直譯器，卻已經在無意識間實現了直譯器的某些功能。
寫給未來的程式設計師
寫給未來的程式設計師 l 不要死記語法 很多初學者試圖把各種語法背下來，其實這是極其錯誤的，程式開發的語法，規範特別多，不可能都記得下來，你只要知道有這麼乙個功能就可以了，需要時候翻閱書籍，或者找幫助檔案，這樣省時省力。l 多動手，多練習 只知道死啃書本的人，是不會成為開發高手的，只有多上機編寫程式...
程式設計師的自我救贖（前言）
程式設計師的自我救贖 前言 記得第一次登陸的時候，在個人資料裡寫近期願望是當上專案經理。轉眼間7年過去了，我也當了四年多專案經理。驀然回首之間，也不再糾結被別人叫程式設計師還是叫軟體工程師。其實在當專案經理的4年裡，前兩年確實很忙。到第二年的時候，我開始不再碰 恰好微軟在.net這一塊也開始流行 使...
寫給《程式設計師》雜誌的編輯
平時看 程式設計師 也好，電腦報 也好，這類 it 類的書報時，總是會不經意地看到一些錯字 別字。有時候覺得，也許這只是自己學中文出身，對這方面過於敏感造成的。畢竟編輯們又不是神人，不可能面面俱到，也不可能做到一點疏忽都沒有。所以大部分時候也就 一笑而過 了。但是當我看到2007年第7期的程式設計師...