成品软件包与元编程

大众软件市场为什么是意义最深远的开发方向？

1950-1960 年代: 一个接一个的研究显示用户不会在工资系统、物流控制、帐务处理等系统中使用商用软件包, 需求过于专业, 不同情况差别太大;
80 年代: 这些软件包的需求大为增加, 并得到大规模使用;
不是软件包变了: 它们可能比以前更加通用和更易客户化一些, 但并不太多;
不是应用变了: 今天的商业和学术需要甚至比 20 年前更加不同和复杂;
真正的变化: 计算机硬件/软件成本比率--1960 年买 200 万美元机器的人觉得可以为定制薪资系统再付 250,000 美元; 现在买 50,000 美元办公机器的人很难想象再付这笔费用, 于是把现有软件包调整后使用;
作者自评的遗漏: Ivan Selin 指出作者低估了软件包客户化的程度和重要性--对最终用户而言, "易于定制"是一个非常大的卖点, 他们常常比软件人员更不愿使用软件包;
戏剧性例外: 电子表格和简单数据库系统; 它们出现得如此之晚和如此醒目, 取代了大量原本用 Cobol 或报表生成程序编写的客户程序;

定义: 为部分软件包用户进行功能定制的过程;
不是新概念: 60 年代早期, 很多计算机提供商和 MIS 厂商都拥有小型专家小组, 用汇编语言的宏来装备应用编程语言（如 Eastman Kodak 用 IBM 7080 宏汇编定义的自有应用语言）;
现在的差异: 元编程人员提供要素的规模是宏的若干倍;
例子: Hypercard Stack、Excel 模板、Minicard 的特殊 Pascal 函数、AutoCAD 的 AutoLisp 函数;
为什么针对根本问题: 成品软件包提供大型功能模块和精心定制的接口, 其内部概念结构根本无需再设计;
目标软件包的特征（如 Excel、4th Dimension）: 大型、广为人知、文档化、测试过的模块, 可用来搭建用户化系统;
下一级开发者的收益: 丰富的功能、更短的开发时间、经过测试的组件、良好的文档和彻底降低的成本;
存在的困难: 成品软件是作为独立实体设计的, 元程序员无法改变它的功能和接口; 而把产品变成更大型系统中的模块, 对成品软件开发者似乎缺乏吸引力;

定义: 元编程接口（metaprogramming interface, MPI）;
要求一: 元程序需要在整个软件集的控制之下, 而每个软件通常假设受自己的控制;
要求二: 软件集必须控制用户界面, 而应用程序一般认为这是自己的职责;
要求三: 软件整体必须能够调用任何应用程序的功能, 就像用户使用命令行传递参数那样;
要求四: 它应该像屏幕一样接受应用程序的输出, 但需要把输出解析成适当数据类型的逻辑单元实体, 而不只是显示字符串;
现状: 某些应用程序（如 FoxPro）提供接收命令的后门接口（wormhole）, 但返回的信息不够充分和未被解析;
脚本语言: 拥有能控制应用程序集合之间交互的脚本语言非常强有力; Unix 首先用管道和标准 ASCII 字符串格式提供, AppleScript 是一个优秀例子;

层次	行为
直接使用用户	以简便直接的方式操作, 对设计者提供的功能和接口感到满意
元程序员（模板/函数）	在单个应用程序基础上, 用已提供的接口开发模板或函数, 主要为最终用户节省工作量
外部功能作者	向应用程序中添加自行编制的功能, 本质上是新的应用语言原语; 往往需要命令中断、回调或重载函数技术
元程序员（构件）	使用一个和多个特殊应用程序, 作为更大型系统的构件; 需求没有得到满足, 也是在构建新应用方面收获最大的用法