Scenario 2：講師

剛剛從Esri的論壇上看到一個帖子，大致的意思是抱怨說，國內的講師與國外的差距太大了。

國外的講師的課我沒去聽過，不過據說有一個Survey的專家，他自己說他對GIS了解的不多。這肯定是謙虛了，不過至少說明，專業很NB的人在GIS行當當顧問是沒啥問題的。

扯遠了。回過頭說講師。都說了，國外的講師我沒聽，但是從國內講師的情況來看，中科永生的培訓課要比Esri的技術支持工程師要好。可能是他們講課講的比較多，所以就比較順當吧。

而且不知道是真心的還是僅僅是出于職業習慣，培訓公司的幾名老大都比較的熱情，相比之下Esri的支持就顯得稍微冷淡一點。

在所有的演講里面，給我映像最好的是arcfall的關于GIS柵格存儲模型的講解。不過似乎我這人有點邪門，11月7號，凡是我聽的全部講座的演示，全部都輝煌的失敗了。

Preface
???既然是叫“隨想”，那么也就是想到哪寫到哪，只要能說出我想說的話，就都好了。

Scenario 1：昨天晚間
昨天乘坐晚上的火車，早間回的學校。看見火車剛剛出北京站時北京二環外的燈火通明車流不息，竟然有一種熟悉的感覺，于是我下意識的沖著往來的耀眼的光招了招手。然后想到徐志摩這個老流氓，遂笑。其實哪里是“不帶走一片云彩”呢，其實是“一片云彩都帶不走”啊。
將車窗的布簾拉下，不用看著飛身而過的兩側護欄，單單是聽著鐵軌發出的節奏，我就已經知道，OK，這一周的時光，將永遠只能佇立在原地，看著我的背影漸行漸遠了，即使我偶有回眸，它也不得而知。
于是我的“它”陷入了悲傷之中。
但是，我只是剛剛上路。不能回首。

（后面的暫時沒時間寫了。。。）

前兩天幫別人裝VS2005時，一切都正常的裝完了，但是在新建了一個console app以后，Compile....Link....OK，本來以為萬事大吉，結果沒想到突然蹦出來一個提示：

沒有找到MSVCR80D.dll，因此這個應用程序未能啟動。

我當時心里想，玩完了。于是下了一個Distributed Runtime，問題依舊，SDK，問題依舊。但是后來我將Solution文件夾下面的Debug文件夾刪掉，Compile...Link...Run....一切就都OK了。

這至少算是一個解決辦法。但是我自己的機器上就沒有這樣的問題，這讓我覺得有些詫異。

在網上搜了一下，發現問題可能出現在文件系統上，好像只有FAT32才會出現這樣的問題。

解決方案有三：
1. 在'Project Properties->Configuration Properties->Mainfest Tool->Input and Output->Embed Manifest' 將 YES 改成 NO 就可以了
2. 微軟的解決方案。
　　在“屬性->配置屬性->清單工具->常規“下有一個”使用FAT32解決辦法，設置為"是"
3? 找到你的工程的文件夾，如（myproject），找到其下的myproject\myproject\Debug\，Delete it.

并發程序的范例來自于一片古老的論文<<concurrent programming concepts>>中的一個流處理過程的實例。盡管說并發從語言級別支持要更加容易的多，但是對于C++來說，現階段編寫并發的方式還是以Multithread為主。

程序邏輯很簡單，讀取一個整數（實質上為了方便我直接用的是程序生成，偷懶了，哈哈），然后并行處理。注意處理這一步一定是高度并發的，這里我為了簡單起見使用了sleep的方式來模擬真實時耗，然后數據改變僅僅是在原數上乘以二，最后輸出。

輸入和輸出考慮到通常他們都是序列化的情況選擇了單線程的方式，實際上如果條件允許，輸入輸出也完全可以是并發的。

對于中間的sleep+2乘這一步，才是真正并發的。之所以用sleep，是因為它能等到一定的時間并在此期間基本上不占用CPU，有點類似于MPU的情況。所以拿它還能做出來一些挺有意思的數據來（YY下SMP ^_^）。

工程文件下載

注意記得將boost::thread的庫文件的目錄添加到附加庫目錄下。
只有boost源代碼庫沒有二進制庫的，可以訪問這里下載boost::thread所需要的lib和dll。(VC++8.0使用)
如果想自己編譯boost而又懶得去看E文的，可以看這里的編譯教程。

關鍵字：boost 編譯 安裝

boost編譯。沒啥新東西，老生常談。

先給出英文的編譯幫助，有什么不明白的或者我沒說清楚的請查閱并確認。
www.boost.org/more/getting_started.html
或者你的boost的安裝路徑下的more/getting_started.html

這里以1.33.1為例。

1.下載boost包，并解壓到某個文件夾下。這里用為方面起見$boost_dir代替，在說明路徑的地方如果出現了$boost_dir請用實際的boost的解壓路徑替代。
注：如果你下載了boost的一些增補包，這些包一般是在boost從上一個大版本到新大版本之前被收錄的一些新的庫或者是新的編譯工具，例如新的bjam。請不要以為是重名而把同名文件夾覆蓋了。看準合適位置解壓就是了。
2.打開命令行工具。以下的主要工作都將在命令行中進行。

3.首先是編譯jam工具。
?3.1 使用命令行
??SET PATH=%PATH%;$boost_dir\tools\build\jam_src\;
?設置環境變量。這一步也可以在“我的電腦點右鍵->屬性->高級->環境變量->user variable或system variable中"設置，而且是永久性的。使用set設置的環境變量只對當前命令行有效。
?3.2 ?運行build.bat。在命令行中查看結果。如果結果顯示“update 1 targets successful"這樣的信息，則表明編譯成功。此時“$boost_dir\tools\build\jam_src\”文件夾可發現一個新的文件夾btn.x86，在里面可以發現bjam.exe。（不知道會不會有btn.x64文件夾。。。我是X86的機器，不太清楚）
??將這個文件夾也添加到環境變量中。
??SET PATH=%PATH%;$boost_dir\tools\build\jam_src\btn.x86;
?3.3?如果沒能成功編譯bjam，則可能是編譯器的設置問題。對于Visual C++（2005Express有點特殊）編譯器，找到common7\tools\vcvars32.bat，把它拖到命令行窗口中，運行一下，然后再執行build.bat。對于2005 Express，這個編譯器攜帶的是精簡的編譯環境，你可以同樣找到vcvars.txt，然后更名為vcvars.bat，按照剛才的方式執行一邊即可。

4.bjam編譯好后，就可以利用它編譯庫文件了。將命令行的工作目錄放置到$boost_dir下，然后執行一下bjam --help，看能否正確的執行bjam.exe。如果提示找不到文件，將bjam所在的路徑添加到環境變量path中，實在不行就把bjam復制到$boost_dir下。

5.如果試圖使用boost.python庫，則需要添加安裝python，并設置對應的環境變量，這里的root對應的是你的python的安裝路徑，ver對應的是你的python版本。
SET PYTHON_ROOT=X:\Python2.3.4
SET PYTHON_VERSION=2.3

6.如果使用了boost.iostreams的compress或者unicode功能，請參閱對應的提示。通常你需要zlib和icu這兩個庫。

7.編譯選項：
選項參見$boost_dir\more\getting_started.html，這里有詳細的說明，以下僅列舉一個很具代表性的選項。

bjam -sBOOST_ROOT=. -sTOOLS=vc-7_1 --with-thread "-sBUILD=debug release <runtime-link>static/dynamic"

上面的命令行設置環境變量BOOST_ROOT為當前路徑，使用Visual C++ 7.1編譯器，僅編譯thread庫（因為完整的編譯耗時很長，所以建議使用--with-<library_name>來編譯指定庫。類似的還有--without-<library_name>選項）。

編譯好的庫都在$boost_dir\bin下。你可以進去搜索所有的lib/dll文件然后剪切出來放到一個文件夾中，再把其他的中間文件刪掉就好了。

類似的你還可以編譯其他的類庫，具體的庫可能需要依賴一些其他的庫，你可以參見庫的編譯說明。另外生成的庫運行時鏈接情況也是不一樣的，例如有的庫不能支持靜態鏈接。這一點請詳細閱讀幫助文件。

8.使用：
這里可能不太好舉例。先將$boost_dir加入到編譯器的include目錄列表中。然后我編譯好了thread庫，并且將所有的相關文件都統一放置到了$boost_dir\bin\thread\目錄下，我便可以在我的工程中將該目錄添加到鏈接文件的路徑中。然后依據情況選擇是否手工添加庫文件。在幫助的“Automatic Linking on Windows”一節，文檔說，很多需要編譯的庫，boost都使用了#pragma指示字指明了庫名稱，也就是說只需要加上庫所在的路徑就好了。

最后是關于運行時庫的問題。最好把你的工程選用的CRT與編譯boost庫時使用的CRT一致起來。這一點可以根據boost文件的名稱判斷。否則的話可能會出現內存的使用錯誤（尤其是分配和釋放不在一個堆的時候更是如此）。

最后是一篇中文文檔。這篇也不錯。如果不清楚，E文也不是太好的可以參看它
http://blog.csdn.net/billdavid/archive/2005/03/07/313347.aspx

     摘要: 沒有什么實際意義（boost.threads已經加入了讀寫鎖好像），只是說明一下condition的用法。鎖由Mutex和Lock構成。Mutex是由condition實作而成的，Lock和ScopedLock區別不是很大，分讀寫鎖而已。以下是Mutex的代碼class?read_write_mutex{????mutex?mtx_;????int?read_cnt_;????condition?...  閱讀全文

?扯了這么多，再次回到開始，C++有那么重要么？
?是或者不是，這個答案并不重要，而我也不能正確地給出答案。如果真要說我只能刷刷奸猾，告訴大家“因人而異”。
?重要的是，我們用什么樣的思路，用什么樣的態度來衡量、評價、解決這個問題。
?下面一段又是個老生常談，隨便到哪個搜索引擎上都能搜到一堆的話題：C++是怎么來的，它為什么而設計的，實際上人們又拿它來做什么，它有什么優缺點。我接觸編程6年，其中C++占到4年，而且是我用的最好，也是最喜歡的語言。每次說到歷史這個話題我總是有一大堆羅嗦的話要說。但是實際上我對C++的感覺到的最大的特點，卻是書多，相關的書非常多，經典的著作相比較其它語言而言也算得上是最豐產的了。書多不外乎三種原因，一是流行面廣，而是流行時間長，三是難度大。C++就那一點點編譯器規則，一本ISO C++的手冊搭配其發明者Bjarne Stroustrup的《The C++ Programming Language》就把語言機制講的很清楚了，為什么它又有那么多的書來闡述一些所謂的Advanced Topics呢？因為靈活。C++極度靈活，這種靈活并不是動態語言的那種靈活，而是在于它承載了太多的需要，導致它變得極度靈活化，靈活的負面意思就是太多，太復雜，使得人們太容易混淆與各種語言機制的Chaos中。似乎南師大的榮耀教授在采訪BS的時候還是BS在什么地方說過，如果C++要像現在的老師們這樣教他自己都不會去學。
?然后BS就舉了一個Hello World的例子來說明他所認為的啟蒙C++與一般授課使用的C++差別在什么地方，并以此說明C++其實并不復雜。好吧，我們就承認純正的C++并不難學。但是不能忘了，我們的C++的對與錯不是由我們決定的，而是編譯器。工程上用的C++編譯器絕對不會說不支持單純的，蹩腳的C-Style（不是說CStyle蹩腳，而是說C中蹩腳的部分），不會不讓你使用指針訪問內存（指非必要的訪問，例如動態數組），甚至不會拒絕你使用一些類似于Hacker的代碼來完成一些極具技巧性和挑戰性的工作。好吧，既然C++都支持，那么便不能拒絕你寫出有此類特性的代碼。更加致命的事情是，它的很多高階機制，都是建立在底層機制基礎上。最明顯的例子就是Boost和STL。一旦編譯出錯，那么它的提示可能出在任何層面上，為了解決這些問題便又需要去學習那些較為底層的知識。C++的大坑就是這樣一點一點挖出來的。
?C++可供選擇的東西太多。所以BS就出了一本書，叫《The Design and Evolution of C++》，專門討論了每種機制在C++當中被采納的背景、他們當時的考慮、這些機制的適用范圍。雖然說這本書屬于“入門教材”的行列，但是實際上我更加傾向于將這本書看成是在你品嘗了C++大餐后的甜點。也就是說，盡管看起來有道理，但是作為預備知識同樣不適合，于是你只能一邊牢記大量的語言機制，一邊應用，一邊體驗，一邊讀那些專著來糾正你的錯誤并填補你的不足，不可能有機會讓你只走你需要走的路，大量的知識構成了一個扁平的知識框架，為了達到相對自由運用的水平，你需要學習的知識、需要獲得的體驗、需要彌補的弱點太多了。
?
?如果說，只有C++可選的話，那么也就沒什么辦法了，大家只能去學那個能讓人死去活來的東西。但是實際上我們并不如我們自己認為的那樣無奈。大量的語言，總有比C++更加適合一般學生的。靈活的腳本語言Python/VBSP/JSP/Perl/Ruby/Lisp，半動態的（我是這么叫的。。。）Java/C#/VB/VB.NET/CLI，高效的 Ada/Fortran，桌面開發用功能強大的Delphi（人家的語言叫Object Pascal，但是也就那么一個編譯器，所以無所謂了），這其中的絕大部分語言學習難度都要低于C++。
?一般來說，有不少學校對于除了與電子和信息相關的專業都選擇的是VB(以下說的VB均不指.NET)/VFP作為計算機二級的突破口。而這點教學，往往就成為了一個工科研究生僅有的編程基礎。VFP這種被淘汰的使用范圍狹隘的環境不討論，VB作為RAD來說著實是個不錯的選擇。但是為應付計算機二級所教授的課程來看，并不能教會除了語法外的什么，況且所使用的VB6嚴格來說是Message Driven兼Object Based的一個開發環境，這都不利于學生從程序結構的高度（不是數據結構）去思考所撰寫的代碼。在短暫的學習以后我們會誤認為界面框架就是軟件的構架，于是我們便可以看見在畢業設計時候，那數百行可憐的代碼都擁擠于Command1Click這樣的字里行間。Object Based的語言既不能教會我們用過程的方式開發，也不能支持面向對象的程序設計方法。這些都是VB對進階學習的最大障礙。
?但是畢竟我們熟悉了VB的語法，知道了程序設計語言是怎么一回事。這已經花費了沒有接觸過編程的同學的相當長的時間，如果說我們還要去牽扯入C++那可怕的內存海洋中，還要被C++那恐怖的前后++所威脅，但是實際上我們不需要它也能過得很好，我們是不是有些冤大頭了？
?實際上，對于研究生階段，最重要的就是要讓我們學到的那一點點東西在盡可能少學別的東西的情況下發揮最大的價值。
?前面我把VB一通好臭，我想VB都會不理我了。那么我們就另結新歡吧。找誰呢？

?VB的弱點已經有點數了（很有數的話你我就不會在這兒瞎混了，早被M$請去了），那么便要去找一門結構性比VB好，概念又不比VB艱深太多的語言（不是說它不能艱深，而是說，不理解那些艱深的東西我們一樣能用的挺歡，最主要的是用起來要舒服，什么亂七八糟的內存管理問題，讓編譯器和RTL/VM去替你擦屁股吧）。JAVA/C#/Delphi/VB.net都算是不錯的選擇。雖然從我的角度來說，很不喜歡，非常不喜歡，特別不喜歡微軟，但是我仍然將C#作為我的第一建議。
?因為C#的開發環境好，速度也還算不錯，桌面開發、企業級開發都很方便，微軟的支持也很到家，但是對面向對象的支持有些強迫性了，可能初期會有些難度。
?JAVA跨平臺，工業基礎好，從嵌入式到大型的分布式系統都能拿來做，但除了和C#一樣的不利因素外，開發環境和程序庫要比C#難用一些。
?Delphi對對象和過程的程序設計方法都能支持良好，語言干凈利索，檢測嚴格，能培養出一個人好的編程習慣，但是它以后用途偏窄。
?VB.NET就不用說（人家都叫VB了），跟VB比較接近，語法跨越小，但是太小了會有學習惰性，會低估語義和程序設計方法上的差異，弄點不倫不類的東西出來。

?C++在程序控制上的能力，基本上都有了，而在在企業級開發方面，C++的弱勢也得到了新語言不錯的彌補。C++的另一個優勢，效率方面呢？
?MATLAB。這個工具生來就是為了計算。作為研究生的工程運算來說，無論效率上還是功能上來說，通常都是夠用的，而且也非常方便，避免了自行編程所面對的極為復雜的算法選擇、編寫、調試的問題（工程計算程序的調試難度是很大的）。
?再加上VBA/VBSP。為什么要帶上VBA/VBSP？其實很多你需要完成的功能，往往都在軟件中可以通過調用某些組件來完成。除了脫機編寫完整的應用程序以外，對于大部分的問題的解來說，都可以直接使用系統所提供的環境方便的完成。使用這個環境所采用的語言，就是軟件的腳本宏，而現有很多的軟件所采用的宏語言都是VBA/VBSP。它的語法、架構、程序的設計都與VB非常接近，用來快速的構造原形或為編寫實驗提供幫助的程序來說，都能比較好的完成任務。

?好了，在一門通用語言+VBSP+MATLAB的幫助下（VBSP基本上是白送的，MATLAB經常是必須掌握的，如果你不需要掌握MATLAB，那么你的工作很可能也用不到C++的高效率），你還需要C++么？
?如果你的答案是肯定的，那么我只能相信這個世界真的有愛情存在。我欽佩你的執著。那么請允許我告訴你我走過的路。
?《The C++ Primer》/《The C++ Primer Plus》??不是一本書，但是都是入門的。別為它的厚度嚇倒，能看多少算多少，不難的。
?《The C++ Programming Language》???手冊。隨身必備，供查閱。
?Platform SDK???????MSDN是個不錯的選擇，講解相近，查閱方便。
?
?《Thinking in C++》??????從C++開始，接觸OOP的深入解析
?《Effective C++》《More Effective C++》
?《Exceptional C++》《More Exceptional C++》??技巧、技術和技藝，編寫C++程序必須注意的若干事項。
?
?基本上到這里就差不多了，后面的就是諸如泛型、并發、元編程、模版、設計模式一類的話題了，不同的話題都有不同的問題背景和應用范圍，這些往往對于大部分語言來說都是相同或者類似的。恭喜你，你們的愛情長跑到站了。
?從此以后，研究生和C++過著磕磕碰碰卻幸福的生活。

意見僅供參考，如果有不同意的，歡迎留言討論~~~

?不能不承認，這個世界上就是有全才。數學、物理界這種人出的最多，牛頓，高斯，萊布尼茲。偏文方面還有那個巨無霸的Da Vinci。單純論數學界而言，自龐加萊以后，就再沒出現過全才了。我的一個學數學的朋友在談到龐加萊的時候那是心神往之，佩服得不得了。

?但是我們總不能巴望著自己是全才吧，是全才，那就一定是天才，是天才，就不會待我們學校了。大家以后都不是什么圣人、天才，大家都是要混飯吃的，所以，醒醒吧。

?我們的老師很知道這一點，所以他們總會好心的勸我們舍棄一部分，以免落個極度平庸的下場。這一點來說，老師們都是很明智的。但是很多的時候，原則上能把握的東西到了實際中就一定正確選擇么？選擇本身是一種放棄，是智慧，也是智慧的悲劇。難道有的時候我們沒有覺得，自己放棄的東西太多，或者自己放棄的東西太少，以至于我們在離目標只有毫厘之差的時候餓死或者累死？這個度是這樣的難以捉摸，使得我們往往會做出過于樂觀或者過于保守的判斷。

?工科的人通常會做著悲觀的估計，保守的行動，卻又期待著樂觀的結果。

?今年我們專業碩士學位的GIS方向引進了一個據說開發做得非常好的人，南大的博士。然后說別的學院也搶著要他。從我們系主任眉飛色舞的情況來看，他是很中意這個人的。據說這個人能獨立開發一套接近于商業軟件品質的作品。當然是不是有些吹牛的成分無從考證，也不重要，關鍵是，這個人的編程水平，包括軟件工程素養都是不錯的。再加上我們一個碩士學位卻因為計算機水平很好而被破格留校的老師的例子來看，其實大家需要的是那些專業好，計算機更好的人。但是為什么所有老師都只會告誡我們，要學好專業課，而又讓那些基本上不怎么會計算機的人去做一些難度比較高的程序呢？

?因為他們忽視了第二種人和第三種人的差距。他們所做的一切，都是讓第二種人越俎代庖去完成第三類人完成的任務。只所以忽視這種差異，恐怕是因為根深蒂固的工具無用論的思想。結果大部分試圖跨過看來不起眼的禮器的人，都被絆了一跤，少數成功“代庖”的人便成為這種培養模式的豐功偉績的貞節碑。但是實際上這種成功具備代表性嗎？一點也不。而那些被絆倒的人很無辜的就被抹殺了。那些成功跨過去完成任務的幸運兒還回過頭來向那些剛剛站到祭臺上的可憐蟲們招手，而那些可憐的人兒連腳下的路都不去看上一眼，沖動的撲過去，轟隆一下，摔得很慘。

?所以說，正確認識計算機技術及計算機科學在工學界的地位、作用和他們的參與方式，才能使我們更好的對待、使用它。所有的科學、技術都是公正的靈魂，尊重了它，你就會得到相應的報酬。當然我知道我在我所在的專業只是一介平民，甚至連平民都不如，所以這話盡管我認為是正確的，但是說得就沒有什么底氣。

?一個碩士研究生，究竟要對計算機掌握到什么樣的程度？

?工學碩士，是需要在自己專業有所造詣的人才能被授予這個學位的，很自然的，專業要被放到第一位。OK，這跟老師們的說法是一樣的。但是，不可能有兩個第一，所以計算機，尤其指編程能力，就一定要放到第二位。（當然，有想法的除外，碩士，甚至是博士都可以專業第二計算機第一，但是這樣要付出更加艱辛的努力以克服跨專業帶來的壓力）從一開始，就不要指望他/她的編程能力能怎么樣，核心放在解決問題，而不是給自己制造編程方面問題上。這一點其實大家都很容易看清，但是，即使看清了，仍然會做出一些不理智的事情，例如一個只會用用matlab腳本完成一些最簡單計算的人非要去寫一定規模的代碼。但是實質上規模稍微一大，就會容易出漏子，歲月皆蹉跎。這一點以前我還可以說是很多人是形勢逼迫。但就像學生都在一邊控訴應試教育，一邊拼了老命的抓分，老師稍微有些“素質教育”都要被質疑動機是一樣，有些人已經習慣于一面控訴老師對編程的要求，一面將自己趕鴨子上架給自己活罪受。不是所有人都能在編程學習的煉獄中熬成正果的。所以學多少，自己的心里面一定要有個數，我個人的觀點是，能解決問題（如果你的計算機爛到連自己的最基本的問題都搞不定，那還是別想著什么“適可而止”這種自欺欺人的話，好好學學才是正道），又不給自己帶來新問題就好，不同專業不同領域，不同追求的要求都不一樣，所以這個東西一定是因人因事而異的。

?而那些希望在程序上有所突破，成為專業輔助計算機為主的人，在強化計算機的同時，不能放棄自己的專業素養，尤其是一些好不容易培養出來的專業感覺。這些感覺，一旦喪失，沒有了環境的浸淫，想再培養起來就比較困難了。

在上一個屬性類的基礎上改進了類型的注冊方式，并且在開啟RTTI的情況下可以選擇自動注冊類型并使用RTTI信息來對類型名稱字符串化。工程文件請在http://blog.gameres.com/show.asp?BlogID=170&column=0
下載。

研究生，請你拒絕C++的愛（上）

????????昨天晚上，考研考的無聊了便沖到實驗室去寫了一點構思已久的代碼，在實驗室里面聽見一個老板說里面有個女生看見我的一個師兄學C++便也要去學。我真的是覺得這個女生勇氣可嘉。
????????細細想來，夸張點說我都有點悲從中來。那個女生應該是做遙感方向的，被逼到C++這條絕路上讓我頗有些覺得悲涼，更主要的是她是自愿跳C++這個大坑的，這甚至讓我有些想荊軻同志去做Suicide?Bomber時“風呼啦啦啊易河凍死人”的感受。當然，我承認我的這份感覺是摻雜了95%以上的故弄玄虛的水分的。只是我很想問那個學姐，C++有那么重要么？
????????我所在的學校是一個非常一般的以工科為主的高校，有特色學科，但是不是什么特色學校。按照我的感覺，現在的工科專業對于計算機這個Tool來說，完全是一種極度功利化的態度，這種態度讓我感覺很有些不爽。實質上在現有的工科專業中，計算機大約和數學是差不多的，都屬于工具性的學科，只不過數學更要基礎一點而已，大家似乎都對數學帶有著很敬畏的態度，而對計算機則是有些鄙夷。不合不分，不親不離，工科專業和計算機之間的關系很是尷尬，就有些像色情小說，是個男人總希望去窺探那么一把然而又恥于讓人知道。于是這種鄙夷+需要便構成了工科專業對計算機有些畸形的態度。正像我的老板一邊對我說，你學那么多計算機有什么用，一邊又讓我幫助那些不太會編程的師兄師姐們解決一些問題。
????????但是事情真的是這個樣子的么？大家都喜歡中庸的文化，所有的老師都建議我這樣對計算機有特殊偏好的人對計算機的追求要“適可而止”，要精深專業而粗通“The?Art?of?Computer?Programming”。然后給我舉出一大堆的理由，告訴我單純的編程好的人有多么多么的無能，他們面臨專業問題的時候多么多么的無奈。我親愛的老師們啊，在您勸導我不要走上一個極端的時候，為什么您要走上另外一個極端？
????????這個極端便是“極端的中庸”。不可否認，現代科學，尤其是工程科學是建立在大量的數學規則、海量計算和一些看起來合理或者不那么合理的推測和限制之上的。科學是講究絕對理性的，而這個理性的基礎卻是感性（公理系統），而工程問題上，感性這一點表現的更為明顯，有很多的問題實質上是半理性半感性所構成的，例如一些理想化的經濟學模型，感性這個東西是有很多講究的。和諧，美，合理化是理性化的感性所永遠追求的主題。對不起，扯遠了。也就是說，計算機在這里充當的角色通常有2種，進行海量計算，或者是使用理性去分析感性的模型。然而計算機本身也是個感性的東西。隨著工程問題的日益龐大，相關的計算機軟件也越做越大。當軟件或者軟件參與的計算復雜到一定程度的時候，便需要有理性化的感性去組織我們的工作使之容易為我們所用，往大了說就是要在工程中構造一種和諧的美。如果沒有這種美，那么工程本身就可能會被魔鬼拖向深淵。
????????很可惜，有的時候人對美的感覺并不一定是天生的，后天的訓練往往對于美感起到超乎想象的作用。訓練本身不一定能讓任何人都對審美達到一個不可逾越的高峰，但是至少它可以讓大多數人都知道什么是美的，什么是丑的，這樣才能樹立正確的方向。
????????軟件也是如此，沒有相當的訓練，寫出來的一堆?Bad?Smell?濃烈的代碼任誰都是不敢用的。然而我們的傳統觀念恰恰在培養這些到處遺留?Bad?Smell?Code的人。如同雞肋，食之無肉，棄之有味。
????????換過來來說，如果一個編程水平扎實然而專業基礎太差的人負責整個專業軟件的開發，這個軟件的可靠度，易用性，功能完善度，用戶友好度都有待考量。
????????我們該怎么辦？這樣的怪胎誕生自受過高等教育的人的手里，究竟是誰之過？
????????根本在于，我們忽略了“和諧”這樣一個關鍵的詞。和諧，而不是平均，這點在政治上，在美學上都已經是有了定論的，美的極致不是0.5，而是0.618。怎樣去尋找那0.618？
????????先來說說，我們現在有些什么樣的人才。
????????簡單來說，工科和計算機的結合不外乎以下五種。
????????第一種是純專業化的，除了專業，別的都不懂。現在除了一些做純學術的人外這樣的人已經不多了，但是不可否認的是，即使他們不懂計算機，他們仍然是專業領域里面的探路者。道路艱險，雖然他手無縛雞之力，但是他們的助手，同事，學生都會幫助他劈開荊棘，而如果失去了能看見那來自允諾之地的光的prophet，所有的人都會迷惘的。
????????第二種是專業為主計算機為輔的。這些人專業功底扎實，很扎實，非常扎實。雖然他們不知道專業的路怎么走，但是他們能清理掉腳邊的灌木雜草，在茂密的叢林里探尋出一條路，并且能告訴后人這條道的正確與否。但是他們往往執迷于自己的路上，越走越遠，直到有一天他們發現了真正的荊棘林之后，發現自己無法走通，于是悲慘的死在那里，只留下一個凄涼的墓碑。
????????第三種是專業為輔計算機為主。這些人不知道路怎么走，也不太清楚對于錯，但是他們都知道那個擺在遙遠未知的烏托邦，并愿意為之而奮斗。對工具熟練運用的他們是拓荒的中堅力量，如果不是他們披荊斬棘，所有人都走不出茂密的叢林。
????????第四種是專業結合計算機科學。注意，我這里說的是計算機科學。這些人是那些迷路在叢林之中的最好的本地向導。他們和第三種或者第二種人一樣，不知道真正的方向，甚至連對錯都不清楚，但是一旦遇到無法強行撼動的障礙時，他們便會帶領團隊繞開那些阻礙他們的泥濘。
????????第五種是計算機的專業人才。對于先知看到的路，他們一無所知，不知所以。在某條特別的專業小徑上，他們只能低著頭，跟在前四種人后面，做些苦力的活計，卻不能有半點想法，因為他們無法提出正確的想法。這些人實際上是一些悲情的人們，因為如果他們留在自己的家鄉，或者出去尋找一些自己能做的活計，他們一樣能活得很滋潤。但是他們也是值得敬仰的，如果沒有他們，單憑前四類那數量稀少的人，也是成不了什么事的。他們是專業領域值得然而沒有得到尊敬的墊腳石。
????????你屬于哪一種人？