正如同阳光、空气、水，是生命三元素；我认为程序三元素是语言、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为主，工具为辅。

妖刀：网络营销创新需要把握时机找对方法 终于通过自己的网站辛苦赚到了第一桶金

评论 (0) All