浅谈COBOL

2020-06-29 02:59:32

要继续学习并在您的职业生涯中取得进步,请查看O‘Reilly及其合作伙伴出版商提供的免费试用在线培训、视频、书籍、认证准备等内容。

我们都已经看到,全世界(嗯,政府,特别是州政府,更不用说银行了)都在呼唤COBOL程序员-这种呼声大约每五年就会上升一次。不知何故,我们蒙混过关地度过了眼前的危机,然后人们就忘了这曾经是个问题。现在是我们问一问这场危机到底是什么,以及为什么它不断重现的时候了。

COBOL是最早的编程语言之一;它发明于1960年,作为一种只需要最低编程技能的语言迅速声名鹊起。(真正的程序员编写FORTRAN。)。COBOL的发明者不是这样说的,但在某种程度上,这就是他们的意思:一种程序员应该很容易学习的语言,而且业务人员也可以理解。只要看看COBOL代表的是什么:“面向商业的通用语言”(Common Business-Oriented Language)就知道了。一种用于商业的编程语言。

Cobol的影响力在20世纪80年代逐渐消失,现在,政府、银行、企业和其他地方有数十亿行代码在没有人维护的情况下执行基本的商业功能。COBOL程序员已经老了,退休了,之后就没有人来了。

这里的语言是什么样子的?我有机会看过COBOL代码,我的反应并不像我预期的那样。它看起来不像任何“现代”语言。但在人们知道如何设计像样的语言之前,它并不是一件奇怪的古董。COBOL是一种经过深思熟虑的特定于领域的语言。这是一种使用商人语言的商务语言。还记得Ruby拥护者曾经为他们能写出看起来像地道英语的语句而感到自豪吗?他们可以使用元编程来创建使用不同应用程序领域的词汇表和概念的特定于领域的语言吗?这是一个不小的成就。而COBOL在40多年前就做到了。

像其他有用的语言一样,COBOL从未消失过;但它对计算机语言的发展影响之小令人惊讶,这使它看起来像是已经死亡。在10种最具影响力的编程语言中,Hillel Wayne认为COBOL对编程语言的开发影响很小,因为它来自企业界,而学术界对此不感兴趣--对于学术界来说,它“不值得关注”。不管怎样,谁会想要编写银行家和业务人员可读的代码呢?说一种其他人都听不懂的秘密语言的诱惑总是吸引着程序员。

尽管如此,COBOL还是进行了一些重要的创新。它有一个记录的概念(就像数据库中的行),这与层次结构的概念有关,期待C结构,甚至对象。而且它有一个报告生成器-如果这听起来不有趣,请记住Perl最初的应用程序之一是报告生成。另一种几乎被遗忘的早期语言,RPG,纯粹是为了生成报告而发明的。报告不是很吸引人,但它们很重要。

在句法上,COBOL问了一个非常好的问题:为什么我们需要使用数学的混蛋语言来转移资金,比如“TOTAL=TOTAL+DATCH”?把金额从一个账户转到另一个账户不是更自然吗?别太激动了。Move听起来像是一个原始事务,但它不是;它只是一个任务。然而,如果您正在考虑转移资金而不是将其赋值给变量,那么这些想法将使您更早而不是更晚地进行原子事务操作。

当然,COBOL没有提供很多东西。虽然COBOL已经更新了您期望在现代语言中使用的大多数特性(从2002年开始,它甚至是面向对象的),但是COBOL往往会导致非常笨拙的意大利面代码和单块。这是20世纪60年代为你准备的节目。GOTO是每种编程语言的重要组成部分(即使是C语言也有GOTO语句)。模块化即使被理解了,也没有得到很好的理解。图书馆?COBOL的最早版本没有标准库,更不用说用户定义的库了。Web框架?你不会想知道的。微服务?休想。

那么,我们现在处于什么位置,有我们数十亿行的COBOL来管理世界各国的政府和财政呢?我怀疑是否还有很多20世纪60年代的大型机,但是有很多60年代的大型机在云中运行COBOL的仿真比它最初运行的硬件快得多。这是我看到的一种维护COBOL的策略:让它保持原样,在仿真器上运行,将其包装在用某种“现代”语言编写的微服务中,并且希望您永远不需要接触它。这为我们赢得了时间,但是“希望”或许能解决眼前的问题,但却是一个糟糕的长期战略。

真正的问题不仅仅是缺乏精通一门不再流行的语言的程序员。还有一些文化问题需要解决,这些问题的解决方案不仅仅是“培养一批新的COBOL程序员”。首先,90年代和00年代的“语言战争”的一个牺牲品是,我们有越来越多的程序员认同一种语言:他们是JavaScript程序员,或Java程序员,或Python程序员,或Rubyist。戴夫·托马斯(Dave Thomas)和安迪·亨特(Andy Hunt)关于每年学习一门新编程语言的建议和他们第一次编写“实用程序员”时一样有效;但遗憾的是,他们没有注意到这一建议。要成为一名优秀的程序员,您需要让自己接触到新思想、新的思考问题的方式--就COBOL而言,还需要接触旧思想。不能被劝说走出自己的舒适区的程序员不会学习COBOL;但从长远来看,无论他们懂什么现代语言,他们都会被证明是不那么有价值的。

其次,COBOL编程需要了解业务编程。不管是哪种语言,这是一种越来越罕见的特长。你们是如何处理财务数量的,比如美元和美分?如果你说“浮点数”,就到教室后面去。舍入错误会要了你的命。如果你说“使用整数,然后除以100”,那也好不到哪里去。根本问题是二进制数不擅长表示十进制小数值。但这是大多数当前程序员从未学过的知识。(我们甚至还没有开始考虑货币兑换。)。

第三,在20世纪60年代、70年代甚至80年代做出的工程决策不是我们今天要做的决策。这项工程在当时当然是有效的,但现代工程师经常不明白为什么。我听到许多当代程序员将Y2K问题(用两位数表示1900年代的年份)称为“技术债务”。这代表了对原始程序员面临的问题的误解。在一个在80列穿孔卡片上输入数据的环境中,节省2个字符是件大事。在最大的计算机具有千字节(最多只有少量的K)内存的环境中,保存2个字符是一件大事。这不是必须复制的工程,但它确实需要被理解。

第四,旧的商业软件是铁板一块的--而且在很深的意义上也是铁板一块的。它倾向于对人类要填写的表单进行建模,只有在表单完成后才能提交。通常没有办法保存你的工作,因为-你为什么需要保存呢?你亲自去了失业办公室;当你把申请书交给办公桌后面的人时,你就离开了。一张不完整的表格会被扔进废纸篓;为什么要在上面浪费宝贵的存储空间呢?把Web界面放在这些巨石前面会导致一个可预见的结果:冗长、复杂的表单可能需要几个小时才能填写,而且在现代Web上几乎无法使用。在创建加利福尼亚州简化的食品援助申请GetCalFresh时,美国代码发现,旧的表格需要一个小时才能填写完毕-但申请者通常依赖图书馆的公共计算机,这些计算机不允许超过半小时的课程。由于不完整的表格无法保存,申请者无法完成申请。将COBOL应用程序移动到仿真器,在云中运行它,然后将Web前端拼凑在一起,不会解决这样的问题。好消息是,这是一个重新思考你的服务并使其更有效的机会。坏消息是,这不是一蹴而就的办法。

那么,需要什么呢?是的,我们需要更多了解和理解COBOL程序的人。有很多旧代码需要重新编写

编程的未来是重新理解过去,重新发明它来迎接我们目前的挑战。