给新程序员的一些建议
从1993年我第一次在同学家的一台金字塔学习机上用basic编程，至今已经过去18个年头了。
我通常不以程序员自居，因为我学习编程的目标从一开始就不是做一名程序员，而是解决我遇到的那些感兴趣的科学计算问题。
由于早些年接触的是DOS-Windows，我曾经被这些东西严重锁定。对于一个职业程序员来说，这可能很危险，你很难连续多年只在一个平台下开发软件。但由于我并不以程序员自居，所以很久以来我一直不觉得这有什么不妥，只要我能解决那些我试图解决的科学计算问题不就行了么，干嘛要浪费那么多时间和精力学习不同平台的技术呢？
多年之后，我才意识到这是一个多么严重的错误。
由于技术的巨大变迁，不知道多少次，为了解决跟过去类似的问题，我不得不被迫学习和使用一些新的技术，学习在不同的平台下工作。虽然我编程的主要目标是解决感兴趣的科学计算问题，但仍然难逃被迫学习新技术的宿命。
以绘图为例，我最初是在DOS下使用Turbo/Borland C++的GDI，虽然这只是一个玩具绘图接口，但对于我只是想要把科学计算的结果画出来看看而已，这完全能够满足我的要求。Turbo/Borland C++的IDE堪称是经典杰作，极其直观易用，其集成的帮助、调试（Turbo Debugger）和性能剖析（Turbo Profiler）的界面方案在现在看来也并不落后。但DOS时代的Turbo C++没有提供revision control，但这对于当年正在读书只写一些小程序的我而言根本算不上问题。
不久之后我开始接触Windows，Windows编程最初让我非常抓狂，我不得不使用一大堆我压根不想去了解的跟科学计算毫无关系的东西，而且我从一开头就对Microsoft丑陋的GUI框架风格极度排斥。令人沮丧的是Windows下的Borland C++的GUI框架风格也没好到哪里去。最初的一段时间我甚至经常回到DOS下用Turbo/Borland C++完成任务。但很快我遇到了DOS的16位模式下内存尺寸限制，想要解决那些需要大内存的问题，DOS下的Turbo/Borland C++很不方便。对支持32位保护模式的Watcom C++短暂尝试之后，我还是转向了Visual C++，因为对我这种记性很差讨厌命令行方式的不合格程序员来说，Watcom C++实在太不友好了。由于讨厌繁杂的界面编程，我总是用Visual C++创建Console Application的Empty Project，继续我那“纯净”的编程生涯。由于个人兴趣，在公司工作期间，我设法摆脱一切界面程序设计，只负责一些核心组件的纯算法代码编程。我渐渐掌握了一套有效的编写跨平台代码的技能，却几乎只需要在Windows下编程，而且我交付的代码质量也很高，经常能够做到零缺陷交付。在这期间，我掌握了一些配置管理和revision control的工具。当我不需要跟别人合作的时候，我只使用Visual Studio自带的配置管理工具和Visual Source Safe，而代码编辑则使用Source Insight。对于一个人的项目，Visual Source Safe基本可以满足要求，但不幸的是，Visual Source Safe很早就停止维护了，也没办法跟新版本的Visual Studio方便地集成。从本科时代到我再次回到学术圈，Windows的版本变迁经历了95、NT、98、ME、2000、XP、2003、Vista、7。我很懒得紧跟Windows的版本更新，因为每一次操作系统升级换代都可能让我已经依赖的某些软件工具失效或过时，以至于我不得不重新寻找替代品，但另一方面也不能老是不升级，比方说如果你想要平板寻址超过4G内存，就得使用64位操作系统。
如果我能够回到13年前刚刚开始工作的时代，那么我会选择一条很不同的道路。我会采取以下原则：
0.尽可能采用跨平台技术
1.尽可能采用开源的组件
2.避免过度依赖短命技术
如果一种技术只在一个平台下才有实现，当你需要在另一个平台上工作的时候就不得不寻找和重新学习替代品。事实上有大量的多平台GUI组件（Qt、wxWidget、U++等），同时许多软件开发工具本身也是跨平台的（见http://en.wikipedia.org/wiki/Comparison_of_integrated_development_environments，特别是Code::Blocks、Eclipse CDT、GNAT Programming Studio、NetBeans C/C++ pack、KDevelop）。使用这些跨平台的技术开发GUI界面，就不会在更换平台的时候遭遇太多困难。
你的公司可能并不介意为商业组件付费，但你却会。尽可能多采用开源的组件，哪怕是公司软件项目，这样你就可以利用在公司工作的机会学习到一些即便离开这个公司也不会失效的技术。当然，有时候这是做不到的，某些大型商业组件是难以找到开源替代品的，不过你要设法避免自己被公司所采用的外面很少有人用的组件套牢锁定。
某些开源的跨平台组件是靠不住的，比方说那些完全由一两个人所维护而且用户群非常小的项目，有一天维护者可能会失去兴趣，或者忙于自己的生计问题，甚至离开人世。除非有充分的理由，否则不要过度依赖这些东西。
另一方面，即便能够重来一次，我也并不准备改变对GUI的依赖，因为我的记忆力很差，跟本无法记住太多的命令及其语法格式，就连我最熟悉的编程语言C++，隔段时间不编码我都可能要查帮助。我并不想成为一名酷酷的黑客级程序员。虽然许多平台下没有GUI的IDE，但我宁可在有IDE的环境下编程、交叉编译再上传，也不愿多学一种命令行。虽然偶尔我也不得不学习一种新的GUI工具，但GUI工具至少是直观的。GUI工具难以自动化确实是一个问题，不过有许多脚本语言可以部分解决这个问题，许多GUI工具本身也提供了一定的宏记录能力。
在开源社区中选择趁手的开发工具很让人头痛，选项太多且缺乏对比信息，但我们现在有了Wikipedia，许多类别的软件工具都能找到List或者Comparision页面，大大减轻了选择的工作量。
插件比较