Lisp is a programmable programming language.
Lisp 是一种可编程的编程语言。
这可能是 Lisp 最吸引人的特性之一了，
Lisp 语言不仅可以用来编程，甚至连语言本身都是可编程的。
Not only can you program in Lisp (that makes it a programming language) but you can program the language itself.
This is possible, in part, because Lisp programs are represented as Lisp data objects and partly because there are places during the scanning, compiling and execution of Lisp programs where user-written programs are given control.
由于 Lisp 语言具有同像性（homoiconicity），
我们可以像处理数据一样处理 Lisp 代码，所以 Lisp 的宏系统（macro system）就变得异常强大，不再是简单的文本替换了。
读取器宏（reader macro）和编译器宏（compiler macro），给我们提供了植入代码进读取器和编译器的能力。
然而，在 Lisp 社区之外，可编程性（programmable）就不经常被人提及了。
大部分程序员都没想过对编程语言本身动手脚。
但是，虽然如此，他们开发的功能却有意无意的赋予了用户可编程的能力。
编程行为
有不少面向企业内部用户的系统，乐于提供用户可配的功能，
例如，一个业务规则可能是运营根据实际情况配置的，
或者，一个页面可能是非开发者拖拽出来的。
其实，对功能进行配置、拖拽，是一种编程行为，
编程并不一定以文本方式输入，程序也并不一定表现为代码这种形式，
广义的说，程序应当泛指能被计算机重复执行的一段计算过程。
用户通过在系统中配置，或者拖拽得到一个页面，
这些配置，或者拖拽行为，被计算机识别并存储下来，最后当做程序重复执行。
在这种意义下，配置和拖拽就是在对功能进行编程。
功能测试
经常写代码的我们，知道代码要发布上线是需要测试的，
我们必须保证发布的功能符合预期。
然而，由非开发者配置或拖拽得到的功能/页面，却很少会经过测试。
这是有安全隐患的。
非常类似于，运维工程师直接在线上通过命令行操作机器一样。
直接操作线上机器的每一行命令，都是对线上系统状态的重新部署。
而改变系统配置的每一次操作，或者拖动影响页面的每个行为，
也都是完成了对现有系统的一次重新发布。
这些动作如果未经审核就发布上线，是一种不易发觉的安全隐患。
互联网历史上，已经有数不胜数的误删数据库，配错规则导致系统挂掉的案例了。
工程师的定位
如果把工程师理解为实现需求的编码人员，未免就过于狭隘了，
我们应该把软件工程师理解为，功能提供与功能使用的桥接者。
工程师的主要价值在于，降低了用户对功能的使用成本，
只是恰好很多情况是通过自动化的手段实现这一点罢了。
所以，不论是直接提供功能，还是让用户可编程，都应该本着降低成本的原则出发，
我们应该提供怎样的使用方式，为用户避免一些不必要的开销？
让用户对功能可编程，是不是我们期望提供给用户的使用方式？
很多时候，可配的、可拖拽的方式，并不是一种友好的方式，
用户可能并不需要那么高的灵活性，也没有意识到这是在编程或需要测试，
更不想对配置、拖拽行为负责。
DSL
DSL是另一种形式的可编程方案，可能是一些开发者提供给另一些开发者的功能，
但同样不幸的是，使用DSL的开发者用户，
似乎也并没有明显的意识到，写DSL就是在编程也需要测试。
因此，如果不曾创建过自己的编程语言的话，还是不要发明DSL了，
给用户提供如此灵活的功能，却没有让用户意识到危险性，是很不专业的，
很多临时发明的DSL，甚至都没考虑过代码的验证问题。
这不是说DSL本身是一个不好的方案，而是说，
提供方案的工程师，不应该只关注功能的实现，还要关注功能的使用，
不然就会引发一堆大家都料想不到的问题。
结语
有不少人对可配、可拖拽、low code深深的吸引了，
他们可能会认为给用户提供灵活的功能，就能为非开发者赋予编程能力，
但其实这件事是有两面性的。
非开发者使用功能的方式，可能会引发一些安全问题，
这些安全问题需要功能的提供者事先考虑清楚，
能做和做正确，还是有很大差距的。
开发者们喜欢可编程的系统，其他人却未必有这样的兴趣，
或者说，其他人未必有驾驭编程的精力。
这一点确实值得深思啊。