其次，快乐来自于开发对其他人有用的东西。内心深处，我们期望其他人使用我们的劳动成果，并能对他们有所帮助。从这个方面，这同小孩用粘土为 “ 爸爸办公室 ” 捏制铅笔盒没有本质的区别。

第三是整个过程体现出魔术般的力量 —— 将相互啮合的零部件组装在一起，看到它们精妙地运行，得到预先所希望的结果。比起弹珠游戏或点唱机所具有的迷人魅力，程序化的计算机毫不逊色。

第四是学习的乐趣，来自于这项工作的非重复特性。人们所面临的问题，在某个或其它方面总有些不同。因而解决问题的人可以从中学习新的事物：有时是实践上的，有时是理论上的，或者兼而有之。

最后，乐趣还来自于工作在如此易于驾驭的介质上。程序员，就像诗人一样，几乎仅仅工作在单纯的思考中。程序员凭空地运用自己的想象，来建造自己的 “ 城堡 ” 。很少有这样的介质 —— 创造的方式如此得灵活，如此得易于精炼和重建，如此得容易实现概念上的设想。

然而程序毕竟同诗歌不同，它是实实在在的东西；可以移动和运行，能独立产生可见的输出；能打印结果，绘制图形，发出声音，移动支架。神话和传说中的魔术在我们的时代已变成了现实。在键盘上键入正确的咒语，屏幕会活动、变幻，显示出前所未有的或是已经存在的事物。

首先，必须追求完美。因为计算机也是以同样的方式来变戏法：如果咒语中的一个字符、一个停顿，没有与正确的形式一致，魔术就不会出现。（现实中，很少的人类活动要求完美，所以人类对它本来就不习惯。）实际上，我认为学习编程的最困难部分，是将做事的方式往追求完美的方向调整。

其次，是由他人来设定目标，供给资源，提供信息。编程人员很少能控制工作环境和工作目标。用管理的术语来说，个人的权威和他所承担的责任是不相配的。不过，似乎在所有的领域中，对要完成的工作，很少能提供与责任相一致的正式权威。而现实情况中，实际（相对于正式）的权威来自于每次任务的完成。

对于程序员而言，对其他人的依赖是一件非常痛苦的事情。他依靠其他人的程序，而往往这些程序设计得并不合理，实现拙劣，发布不完整（没有源代码或测试用例），或者文档记录得很糟。所以，程序员不得不花费时间去研究和修改，而它们在理想情况下本应该是可靠完整的。

下一个烦恼 —— 概念性设计是有趣的，但寻找琐碎的 bug 却只是一项重复性的活动。伴随着创造性活动的，往往是枯燥沉闷的时间和艰苦的劳动。程序编制工作也不例外。

最后一个苦恼，有时也是一种无奈 —— 当投入了大量辛苦的劳动，产品在即将完成或者终于完成的时候，却已显得陈旧过时。可能是同事和竞争对手已在追逐新的、更好的构思；也许替代方案不仅仅是在构思，而且已经在安排了。

最初接触Boland还是5年前的事了，那个时候用Borland的Pascal编译器学习编程技术的基础。后来的C/C++用的都是Borland的产品。所以说Rene对于编译器的选择上已经有一种Borland情节，我的开发生活也已经永久性地打上了Borland的烙印。我想，学了6年的MFC始终没有学会，至今对于VC一直存在着的那种厌恶感应该也来源于此。说到C/C++的开发，Rene宁愿使用C++3.0这种老土得掉渣的开发工具，呵呵。或者用BC，喜欢BC的那种开发风格。

尽管现在使用Java作为最主要的开放语言。IDE也从Borland的开发线产品专向了IDEA，但是不得不承认，Jbuilder对于Java开发是一个极好的产品。Rene之所以不使用Jbuilder是由于它过于庞大了，或者说是过于强大了。当然，有些时候还是要用到Jbuilder的，比如做GUI的设计或者是对于产品最后封装的时候。

但这三个程序都有一些问题，而且是大问题，甚至可以说，我写的代码根本就没有用。先说说C，这个东西单单运行功能都没有什么差错，尽管功能没有全部实现。但是这是一个Binome的项目，两个人做。所以就有问题了，很早就问女王要另一个人的程序，我要看他的结构定义。但是传说中的程序迟迟没有到来，因此就决定单干。这里面就缺少沟通，一切数据定义、API全部是自己的。现在，那个Binome的程序来了，发现自己做了很多重复的功能，而且最大的问题是整合不能。两个对于基本数据结构定义截然不同的程序怎么可能协同工作呢？不过我的程序本身还是比较完善的，应该可以单单拿我的程序去应付一下吧，具体怎样，Rene也不知道。

至于算法，呵呵，简直是笑话，天大的笑话。我拿到的是一个大项目中的一小部分，但还是老问题，基本结构定义迟迟不来。一个大项目，对于图的算法，图结构定义总要统一吧，但是我就是没看到（前天算是看到了）。那好，自己定义！到整合时又是问题，不过幸好，这个图定义是从文件中读取的，我就在那两个算法中再读了一遍定义，按自己的结构存放。这样算法是对了，但是输出又成问题。API定义是他人的，但是我不知道，结果还要修改。不知道人家改得怎样了

Floyd算是太没面子了，耍酷，玩指针，结果在VC编译下都好的程序，拿到GCC下面一编译、运行。算法根本不对！！估计是int类型的字长在VC和GCC下面的定义不一致引起的，但想想也不对啊！这个问题尚未解决，有待研究。

三个程序，三次失败。这个确实可以作为一个失败的案例了。首先是小组成员之间的沟通不良，造成了重复劳动和API、基本数据结构定义的不一致。其次就是小组中应该使用统一的编译环境。第三就是要把整合期提前，不能到最后再去整合、联调。第三点可以和第一点合并，其实这也是沟通的问题。

现在开始怀念Java，怀念Vincent。怀念Java的Write once, run everywhere自不必说。至于Vincent，貌似我们的合作总是比较成功的。但仔细想来，以前的那些个合作项目，其实还是一个人在具体实现。要么一个人专注新技术研究，另一个做实现。要么两个人做不同的模块，但这两个模块都没有什么耦合性，所以沟通不良的问题尽管有，但不明显。以前喜欢把小组任务单干，应该也是这个原因。毕竟要定义出整个小组都能接受且易用的API和数据结构是需要功力的。功力不够啊！！残念~~

记得以前说过，程序一直不写会手生的。这就是Rene至今仍旧保持着做ACM和TopCoder的缘由。即使不做项目，仍旧能够保持对于Coding的一种模式记忆以及类库使用的熟练程度。没想到如今新问题来了。

前几天，女王让我帮她做一下C的Project。这个项目乍看之下不难，就是做一个函数计算器。尽管要用到一些诸如变量寄存、词法分析的技术，但如果有合适的类库支持的话，并不能算难，就随口说了声C’est facile~~但是这个是出于Java的思考逻辑。C语言没有那么丰富的类库，即使有对于熟悉Java编码风格的Rene来讲，使用起来学习曲线也是很陡峭的。如今没有了Java类库，就如同写C++没有STL一样，纯C，Oh！Mon Dieu！什么都要自己来，所有的，包括数据结构……

本来像变量寄存之类的，弄个HashMap足以解决问题的。可是如何构造哈希表呢？尤其是Hash函数，不像Java中的“一切皆对象”，每个对象都有一个Hash码。刚才写了一个框架，发现连C的语法、格式都有些生疏了。把谭浩强的书翻出来看了（幸亏这本书还在 J）。至于哈希，看了算法导论，没什么启发。难道真的要用性能极差的线性表吗？