论程序的三个基本要素：语言，API和工具

语言

语言通常是中立的，和特定的平台无关(汇编语言与系统语言除外);但是，某些语言确实比较适合某些平台。以Apple平台来说，显然objective-C会是最好的选择;以NET平台来说，显然C#会是最好的选择。好的语言选择可以让你具有更多资源，和平台有更好的整合，且新版本推出的速度更快。

语言通常也和专业领域无关(当然，像VHDL.这样的语言除外)，大多数语言在介绍自己时，用到「General-Purpose」 (一般用途)形容自己。但不可否认的，不同语言可能会有不同的适用性，有些语言适合开发Web前端，有些适合开发Web后端，有些适合开发桌面程序。语言通常会带有作风(paradigm,也称为「范式」), 有些是00P的范式、有些是FPP的范式…。经过多年的融合与演变，大多数的语言至少会同时具有两、三种范式，有些甚至会多达七、八种。语言范式越多时，程序设计师可以依据自己的需求和喜好，采用不同的范式。但范式多不见得是好事，有可能表示这个语言没有中心思想，驾驭的难度可能更高，写程序时犯错的机会可能更大。

语言有高阶和低阶的分别，高阶者比较接近人类，低阶者比较接近机器。很多人误以为越低阶的语言越「难」，事实上可能不是如此。在我使用8086汇编语言的时候，我就领悟到，汇编语言其实相当好学，因为语言元素(指令)相当少，月变化不人，基本概念都差不多。多数人认定汇编语言很「难」，其实是在于「难读」(不容易借山阅读源码得知原作者的意图)与「难写」(即使要表达一件简单的事，也必须写出很多程序码)，而非「难学」。

对于语言的选择，除了平台、领域、范式之外，还有相当多面向需要考量，其中有-些是许多人所疏忽的，像是可读性、可写性、上手快慢。 另外，也要考虑到API，如果你选择的语言没有你需要的[API],那么你的麻烦就大了。

API

API通常和特定的平台无关，但是和专业领域有关。至于那些和专业领域无关的API (例如排序、字串处理)，我都把它们归纳到语言中，而倾向不认定它们是API。

大多数的API都是以函数的方式存在。00P的API会将函数集合成类别，将类别集合成框架;FP的API会将函数集合成模组。API的单位很难认定,你可以说一-个框架或模组是一一个API.一个Class是一个API、或者一个函数是一个 API。

我认为语言、API、 工具这三者中，API是最难学的。以Java来说，package 有上百个，类别有上千个，方法(函数)更是有上万个。API牵涉到专业领域的知识，有特定的呼叫次序和参数需求。

其中最难的API通常是GUI (图形化使用者界面)。资料库的API可能反倒很简单，因为许多资料库API都只是CLI (Cal1-Level Interface)，只负责将SQL语法送到DBMS。从某种角度来看，不只这些负责连线到资料库的函数是API，SQL 语言应该也算是资料库API的一部份。而SQL是一种DSL (Domain Specific Language)。

这又牵涉到这几年开始流行的一一个话题-以DSL形式存在的API,例如Ruby-on-Railso由于DSL是语言，所以使用弹性自然比函数(类别、框架)大，加上语言用途特定，所以很容易学，这些都是DSL式的API受到大家的瞩目的原因。而且，DSL 可以让程序码大幅缩短，有助于减少对某些开发[工具]的依赖。

工具

当然，最基本的开发工具是编辑器、编译器(或解译器)、除错器，但这已经是远古时代的事情了。现代的软件开发，用的工具越来越多。尤其是程序产生器的地位越来越重要。

现在的开发工具都很强调程序产生器，利用程序产生器提高生产力。以往只需要U1traEdit就能写程序，不需要这些庞大的开发工具，现在却很难办得到，正是因为程序码产生器的缘故。很多人即使不知道底层的作法，也可以很快地把系统做出来，可以在名片印上「 资深软件工程师」，这也是拜程序产生器之赐。

现在的软件开发都已经走火入魔了。开发的速度提升，不是因为需要写的程序变短，而是程序码产生器帮我们产生出更多程序，而这些产生出来的程序，如果没有像Visual Studio 这样的T具协助，以后会相当难以维护。

我希望语言能更精简，且支援建立DSL,而DSL类型的API大幅度减少程序码长度，减低我们对于某些工具的依赖。语言、API、工具不应该是三足鼎立，而应该以语言和API为主，工具为辅。