论程序的三个基本要素-语言、应用编程接口和工具.docVIP

PAGE 1 PAGE 1 论程序的三个基本要素:语言、应用编程接口和工具 语言 语言通常是中性的，独立于特定的平台(汇编语言和系统语言除外)；然而，有些语言比其他语言更适合某些平台。有了苹果平台，显然客观-C会是最好的选择；NET平台，显然C#会是最好的选择。好的语言选择可以让你有更多的资源，更好的与平台融合，新版本可以更快的推出。 通常，语言与专业类别无关(除了像VHDL这样的语言。当然)。大多数语言在自我介绍时都使用“通用”来描述自己。但不可否认，不同的语言可能有不同的实用性。有些语言适合开发Web前端，有些适合开发Web后端，有些适合开发桌面程序。语言通常有一种风格(范式，也叫“范式”)，有些是00P的范式，有些是FPP的范式。经过多年的整合和演变，大多数语言至少同时拥有两三个范式，有的甚至多达七八个范式。语言范式越多，程序员可以根据自己的需求和爱好采用不同的范式。但是，很多范式不一定是好事。可能说明语言没有中心思想，可能更难掌握，写程序的时候出错的几率可能更大。 高阶语言和低阶语言是分开的。高阶语言的特异力接近于人，低阶语言的特异力接近机器。很多人误以为语言水平越低，就越“难”。事实上，情况可能并非如此。当我应用8086汇编语言的时候，我意识到汇编语言其实挺好学的，因为语言元素(指令)挺少的，月变化也很少，基本概念差不多。大部分人认为汇编语言“难”，其实是“难读”(翻山越岭浏览源代码不容易学会原作者的意图)和“难写”(即使要表达一件简单的事情，也要写很多程序代码)，而不是“难学”。 语言的选择除了平台、范畴、范式之外，还有很多方面需要考虑，其中有些被很多人忽略了，比如可读性、可写性、易用性。否则，考虑应用编程接口。如果你选择的语言没有你需要的[API]，那么你就有大麻烦了。 应用程序接口 API通常独立于特定平台，但与专业类别相关。至于那些与专业类别无关的API(比如排序和字符串处理)，我把它们归纳成语言，但更倾向于不把它们当成API。 大多数应用编程接口都是作为函数存在的。00P API将功能聚合成类别，类别聚合成框架；FP的API将函数聚合成模块。原料药的单位很难识别。你可以说框架或模块是一个应用编程接口，类是一个应用编程接口，或者函数是一个应用编程接口。 我认为在语言、API和工具中，API是最难学的。在Java中，有数百个包、数千个类别和数万个方法(函数)。API涉及专业知识，有具体的调用顺序和参数要求。 最困难的应用编程接口通常是图形用户界面。素材库的API可能很简单，因为很多素材库API只是CLI (Cal1级接口)，只负责向DBMS发送SQL语法。从某种角度来说，不仅这些负责连接素材库的函数是API，而且SQL语言也应该被认为是素材库API的一部分。SQL是一种特定于领域的语言。 这也涉及到了近年来的一个热门话题DSL情况下的API，比如Ruby on-Railso。因为DSL是一种语言，它的应用灵活性自然大于函数(类别、框架)。此外，由于语言的特定用途，学习起来很容易。这些都是DSL API吸引人们关注的原因。而且DSL可以大大缩短程序代码，有助于减少对一些开发工具的依赖。 工具 当然，最基本的开发工具是编译器、编译器(或解释器)和调试器，但这已经是古代的事情了。现代软件开发使用越来越多的工具。尤其是程序生成器的地位越来越重要。 现在所有的开发工具都强调程序生成器，应用生成器提高了生产力。过去只需要U1traEdit来写程序，不需要这些宏大的开发工具，现在却很难得到，恰恰是因为有了程序代码生成器。很多人即使不知道底层的做法，也能很快算出系统，还能在名片上印上“高级软件工程师”，这也要感谢程序生成器。 现在软件开发已经疯了。开发速度提升，不是因为需要编写的程序变短了，而是因为程序代码生成器帮助我们生成了更多的程序，如果没有Visual Studio这样的T工具的帮助，这些生成的程序在未来会相当难保护。 我希望语言能更简洁，我支持DSL的建立，DSL类型的API大大减少了代码长度和我们对一些工具的依赖。语言、API和工具不应该占主导地位，而应该以语言和API为主，工具为辅。