正如同阳光、空气、水，是生命三元素;我认为程序的三个基本要素是语言、API(Application Programming Interface)、工具。
【语言】
语言通常是中立的，和特定的平台无关(组合语言与系统语言除外);但是，某些语言确实比较适合某些平台。以Apple平台来说，显然Objective-C会是最好的选择;以.NET平台来说，显然C#会是最好的选择。好的语言选择可以让你具有更多资源，和平台有更好的整合，且新版本推出的速度更快。
语言通常也和专业领域无关(当然，像VHDL这样的语言除外)，大多数语言在介绍自己时，用到“General-Purpose”(一般用途)形容自己。但不可否认的，不同语言可能会有不同的适用性，有些语言适合开发Web前端，有些适合开发Web后端，有些适合开发桌面程式。
语言通常会带有作风(paradigm，也称为“范式”)，有些是OOP的范式、有些是FP的范式…。经过多年的融合与演变，大多数的语言至少会同时具有两、三种范式，有些甚至会多达七、八种。语言范式越多时，程式设计师可以依据自己的需求和喜好，采用不同的范式。但范式多不见得是好事，有可能表示这个语言没有中心思想，驾驭的难度可能更高，写程式时犯错的机会可能更大。
语言有高阶和低阶的分别，高阶者比较接近人类，低阶者比较接近机器。很多人误以为越低阶的语言越“难”，事实上可能不是如此。在我使用8086组合语言的时候，我就领悟到，组合语言其实相当好学，因为语言元素(指令)相当少，且变化不大，基本概念都差不多。多数人认定组合语言很“难”，其实是在于“难读”(不容易藉由阅读源码得知原作者的意图)与“难写”(即使要表达一件简单的事，也必须写出很多程式码)，而非“难学”。
对于语言的选择，除了平台、领域、范式之外，还有相当多面向需要考量，其中有一些是许多人所疏忽的，像是可读性、可写性、上手快慢。另外，也要考虑到API，如果你选择的语言没有你需要的API，那么你的麻烦就大了。
【API】
API通常和特定的平台无关，但是和专业领域有关。至于那些和专业领域无关的API(例如排序、字串处理)，我都把它们归纳到语言中，而倾向不认定它们是API。
大多数的API都是以函数的方式存在。OOP的API会将函数集合成类别，将类别集合成框架;FP的API会将函数集合成模组。API的单位很难认定，你可以说一个框架或模组是一个API、一个Class是一个API、或者一个函数是一个API。
我认为语言、API、工具这三者中，API是最难学的。以Java来说，package有上百个，类别有上千个，方法(函数)更是有上万个。API牵涉到专业领域的知识，有特定的呼叫次序和参数需求。
其中最难的API通常是GUI(图形化使用者介面)。资料库的API可能反倒很简单，因为许多资料库API都只是CLI(Call-Level Interface)，只负责将SQL语法送到DBMS。从某种角度来看，不只这些负责连线到资料库的函数是API， SQL语言应该也算是资料库API的一部份。而SQL是一种DSL(Domain Specific Language)。
这又牵涉到这几年开始流行的一个话题 -- 以DSL形式存在的API，例如Ruby-on-Rails。由于DSL是语言，所以使用弹性自然比函数(类别、框架)大，加上语言用途特定，所以很容易学，这些都是DSL式的API受到大家的瞩目的原因。而且，DSL可以让程式码大幅缩短，有助于减少对某些开发工具的依赖。
【工具】
当然，最基本的开发工具是编辑器、编译器(或解译器)、除错器，但这已经是远古时代的事情了。现代的软体开发，用的工具越来越多。尤其是程式产生器的地位越来越重要。
现在的开发工具都很强调程式产生器，利用程式产生器提高生产力。以往只需要UltraEdit就能写程式，不需要这些庞大的开发工具，现在却很难办得到，正是因为程式码产生器的缘故。很多人即使不知道底层的作法，也可以很快地把系统做出来，可以在名片印上“资深软体工程师”，这也是拜程式产生器之赐。
现在的软体开发都已经走火入魔了。开发的速度提升，不是因为需要写的程式变短，而是程式码产生器帮我们产生出更多程式，而这些产生出来的程式，如果没有像Visual Studio这样的工具协助，以后会相当难以维护。
我希望语言能更精简，且支援建立DSL，而DSL类型的API大幅度减少程式码长度，减低我们对于某些工具的依赖。语言、API、工具不应该是三足鼎立，而应该以语言和API为主，工具为辅。
网友评论