最近在網上看到leezy_2000的一篇文章，《編程本質》，讀了之後頗有感觸。有些觀點，我非常贊同，但是，有些我卻有不同的看法。覺得在文章之後的討論區不能一吐為快，另外，也早有許多相關的想法想表達，所以就干脆打開Word，敲下了這篇文章。希望能和leezy_2000，以及其他的程序員朋友一同分享。
leezy_2000把程序設計歸結為四大要素：問題、概念、邏輯和技巧，並且舉了一個例子加以說明。問題是程序的目的，概念是在解決問題時用到的抽象事物（或者說是術語），邏輯是描述如何解決問題的，技巧等同於實現，使用何種計算機語言或框架等。這四大要素其實是程序設計的四個步驟，分析、抽象、概要設計、實現。從程序開發的過程上來說，的確如此。
但是，作者把程序的本質歸結為概念和邏輯，我並不贊同。我倒是有些贊同cppTrier的觀點，“編程的本質是問題模型到編程語言的映射”。但是這樣描述的話，程序員變成了翻譯員，抹殺了程序員的創造性。所以我覺得編程的本質更應該是以編程語言的思想描述、解決現實問題。Thinking
in Programming Language。
關於語言和框架，leezy_2000的描述非常的經典。“語言是邏輯的載體和描述工具，框架是對邏輯和概念的一種封裝”。使用不同的語言解決相同的問題，他們的邏輯是不同的。一個極端的例子是Prolog語言，這是我見到過的最奇怪的一種語言，但是用它來解決一些離散數學的問題卻很方便。如果同樣的問題讓一個Prolog程序員和一個C++程序員來解決，他們的邏輯顯然是不同的。大師說“語言磨砺了我們的思維方式，也決定了我們的思考范圍”，就是這個道理（感謝weihere的引用，有時間我要去讀讀《The
C++ Programming Language》）。每一種語言都有它內在的一種描述問題的思想和方法。
作為一個程序員，對於所使用的語言應該有一個全面、深刻的認識，掌握它的思想，學會用它來思考和解決問題。這也是Bruce Eckel在他的系列書籍Thinking
in Java，Thinking in C++所提倡的。
那麼如何掌握語言的思想呢？看看Bruce的書就行了嗎？那樣只能學到一些皮毛。你必須實踐，寫上幾千，幾萬行代碼。只有在水裡才能學會游泳。一本好書只能幫助我們縮短學習的過程，它不能代替實踐。我不能想象一個人如果從來沒有寫過面向對象的程序，他是如何理解UML之類的東西的；更不能想象一個初學C++或是Java的程序員是如何通過讀讀《Design
Pattern》就能掌握設計模式的。
計算機是一門實踐的學科。當我們在討論編程的本質時候，決不能忘記實踐是重要的。本質固然重要，如果少了實踐，就會變得形而上學。即使是微軟的高級副總裁，Rick
Rashid，仍然每年堅持編寫大約50 000行代碼。他認為，用最新的技術編程可以使他保持對計算機最前沿的技術的敏感。（摘自李開復《給中國學生的一封信》）。而在我的周圍，一些只帶幾個程序員的小官，就以編程為恥，他認為象他這樣的官（也叫項目經理）寫程序，太丟份。真讓人汗顏!
我們是程序工人(Coder)還是軟件設計師(Designer)？在回答這個問題之前，我們首先要明白，什麼是設計？設計是工程上的概念，設計的結果是一組文檔，制造團隊可以依據這份文檔，准確的構建出產品。源代碼是滿足這一要求的惟一的軟件設計文檔。和一般工程不同的是，根據源代碼構建產品的成本非常低廉，它無須什麼工人，計算機可以代勞。現在流行的看法，似乎只有畫UML圖才是設計，而使用設計模式編碼的設計倒不算設計。這其實是本末倒置了，UML圖只能算是輔助設計文檔，真正的設計文檔是源代碼。因此，我們都是軟件設計師，我們是在設計軟件，而不是構建軟件。（這一觀點出自於Jack
Reeves的《源代碼就是設計》，《敏捷軟件開發-原則、模式與實踐》附錄D）
設計軟件不是憑空的，你總是要以某一種編程語言來設計。和語言無關的設計，只能算是概要設計，只能做到一定的程度。要做詳細設計必須和某一種語言相關。
以上只是我的一家之言，希望能給其他的初學程序設計的程序員一些幫助。
