编程语言活化石-ABAP

编程语言活化石-ABAP

工作关系最近半年在研究SAP的工程开发，对SAP的主要开发语言ABAP颇下了一番功夫。这门语言是有很久历史，从七十年代到现在快半个世纪了，从中可以看出计算机语言的发展历史，相当有趣，尤其当你知道大量跨国公司用SAP管理供应链、客户关系、财政金融和人力资源，相关商业逻辑还是指望这门语言实现的时候。

在ABAP语言身上，你居然可以看到计算机课上提到的各种发展阶段的例子，而且他们之间还互相兼容，不得不叹服写那些代码的人得多小心才不会踩雷。

我们先从恐龙时代的例子谈起，过程式编程，你会看到像COBOL一样的类似自然语言的语句，表达的却是在字符串里面找字串的意图：

FIND FIRST OCCURRENCE OF 'abc' IN 'abcdef'.

早期的SAP封装了完整的业务逻辑，让人难以置信的是，早在七十年代国际贸易需要处理大量订单，涉及货运责任/保险管理之类的复杂单据业务逻辑就已经完备，那时SAP追求开箱即用，对于客户公司个性化业务逻辑的支持有限。他们希望个性化就是简单的代码，最好业务经理就能自己完成而不是需要专业程序员，颇有今天低代码的意思。当然啦后来完全达不到这个目标，不过像COBOL一样的语句支持就已经成型。后面会提到内建函数完全取代了这类语句，但是兼容性使得今天的新代码里面还是能看到这类语句，SAP甚至没有打算在编译时警告deprecation。

接下来客户公司开始玩花的了，SAP的业务逻辑要直接读写数据库，他们也要。ABAP不得已支持open SQL，这个SQL的子集允许在ABAP代码里面直接写SQL的SELECT/INSERT/DELETE/UPDATE/MODIFY（等价于MERGE）。这迫使ABAP支持一种叫做内部表（internal table）的数据类型和相应的语句。这个东西的麻烦之处通过比较现代语言跟数据打交道的方式就可以看出来：通过底层的像ODBC一类的接口，语言库的包装类可以接受数据库连接之后提交查询或者读写的SQL语句，然后查询/读写的结果被封装在相应的类对象里面，并不需要语言的额外支持；内部表本质上就是一个内存上的数据库表，所以内部表语句居然可以类似SQL查询一样过滤需要的行，甚