岁月流转，往昔空明

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，所有的人都会迷惘的。
        第二种是专业为主计算机为辅的。这些人专业功底扎实，很扎实，非常扎实。虽然他们不知道专业的路怎么走，但是他们能清理掉脚边的灌木杂草，在茂密的丛林里探寻出一条路，并且能告诉后人这条道的正确与否。但是他们往往执迷于自己的路上，越走越远，直到有一天他们发现了真正的荆棘林之后，发现自己无法走通，于是悲惨的死在那里，只留下一个凄凉的墓碑。
        第三种是专业为辅计算机为主。这些人不知道路怎么走，也不太清楚对于错，但是他们都知道那个摆在遥远未知的乌托邦，并愿意为之而奋斗。对工具熟练运用的他们是拓荒的中坚力量，如果不是他们披荆斩棘，所有人都走不出茂密的丛林。
        第四种是专业结合计算机科学。注意，我这里说的是计算机科学。这些人是那些迷路在丛林之中的最好的本地向导。他们和第三种或者第二种人一样，不知道真正的方向，甚至连对错都不清楚，但是一旦遇到无法强行撼动的障碍时，他们便会带领团队绕开那些阻碍他们的泥泞。
        第五种是计算机的专业人才。对于先知看到的路，他们一无所知，不知所以。在某条特别的专业小径上，他们只能低着头，跟在前四种人后面，做些苦力的活计，却不能有半点想法，因为他们无法提出正确的想法。这些人实际上是一些悲情的人们，因为如果他们留在自己的家乡，或者出去寻找一些自己能做的活计，他们一样能活得很滋润。但是他们也是值得敬仰的，如果没有他们，单凭前四类那数量稀少的人，也是成不了什么事的。他们是专业领域值得然而没有得到尊敬的垫脚石。
        你属于哪一种人？