今天，我们发布有关数学，关于COBOL的材料的第二部分翻译，以及为什么这种语言仍然存在。
→
第一部分Müller和COBOL的复发率
让我们看一下COBOL如何处理Müller递归关系。 这是一个实现我们正在研究的递归关系的COBOL程序。
IDENTIFICATION DIVISION. PROGRAM-ID. muller. AUTHOR. Marianne Bellotti. DATA DIVISION. WORKING-STORAGE SECTION. 01 X1 PIC 9(3)V9(15) VALUE 4.25. 01 X2 PIC 9(3)V9(15) VALUE 4. 01 N PIC 9(2) VALUE 20. 01 Y PIC 9(3)V9(15) VALUE ZEROS. 01 I PIC 9(2) VALUES ZEROS. PROCEDURE DIVISION. PERFORM N TIMES ADD 1 TO I DIVIDE X2 INTO 1500 GIVING Y SUBTRACT Y FROM 815 GIVING Y DIVIDE X1 INTO Y MOVE X1 TO X2 SUBTRACT Y FROM 108 GIVING X1 DISPLAY I'|'X1 END-PERFORM. STOP RUN.
如果这是您第一次看到用COBOL编写的程序，那么让我们立即澄清一些事情。 首先，它是所谓的“自由形式” COBOL，它是在2002年引入的，目的是使COBOL更接近现代语言的结构。 传统上，当某些实体放置在某些列中时，COBOL代码具有固定的宽度。 考虑以突出显示行和列的结构形式的代码的想法可能看起来很奇怪，但是这种代码结构旨在模拟打孔卡格式。 在COBOL时代，程序就是用这种方式创建的。 打孔卡有80列-某些列用于某些数据。 对于COBOL，传统方法是相同的。
这段代码中最重要的一点是，如何在这里声明变量：
01 X2 PIC 9(3)V9(15) VALUE 4.
该行开头的代码
01称为级别号。 他告诉COBOL我们正在声明一个新变量。 COBOL允许您绑定或分组变量（经典示例是一个地址，其中可能包含街道，城市和国家的名称作为单独的变量），因此，在这种情况下，级别编号变得很重要。
X2是变量的名称-一切都很简单。 最后，有一个设置变量初始值的结构，看起来像“
VALUE 4. ”。 末尾的点不是错字。 这是在COBOL中结束行的方法。
现在，我们只需要考虑
PIC 9(3)V9(15)的构造是什么。
PIC有点用运算符来描述字符数据类型。 它可以存储字母数字值。 它甚至可以存储十进制数字。 COBOL是一种具有严格静态类型且具有一个不寻常功能的语言，即大多数COBOL类型比其他语言的类型灵活得多。 另外，在声明变量时，必须指定它们可以包含多少个字符。 在我们的例子中，这是括号中的数字。
PIC 9(3)的构造意味着一个变量可以存储三个字符，它们是数字（由数字
9表示）。
因此，构造
9(3)V9(15)应如下：“ 3位数字，后接小数点（v），再后跟15位数字。”
这是该程序的结果：
01|004.470588235294118 02|004.644736842105272 03|004.770538243626253 04|004.855700712593068 05|004.910847499165008 06|004.945537405797454 07|004.966962615594416 08|004.980046382396752 09|004.987993122733704 10|004.993044417666328 11|005.001145954388894 12|005.107165361144283 13|007.147823677868234 14|035.069409660592417 15|090.744337001124836 16|099.490073035205414 17|099.974374743980031 18|099.998718461941870 19|099.999935923870551 20|099.999996796239314
使用具有15个小数位的数字会发生这种情况。 如果我们将变量
X1 ，
X2和
Y的属性更改为
PIC9(3)V9(25) ，则可以继续：
01|004.4705882352941176470588236 02|004.6447368421052631578947385 03|004.7705382436260623229462114 04|004.8557007125890736342050246 05|004.9108474990827932004556769 06|004.9455374041239167250872200 07|004.9669625817627006050563544 08|004.9800457013556312889833307 09|004.9879794484783948244551363 10|004.9927702880621195047924520 11|004.9956558915076636302013455 12|004.9973912684019537143684268 13|004.9984339443572195941803341 14|004.9990600802214771851068183 15|004.9994361021888778909361376 16|004.9996648253090127504521620 17|004.9998629291504492286728625 18|005.0011987392925953357360627 19|005.0263326115282889612747162 20|005.5253038494467588243232985
不同的大型机为COBOL数据类型提供不同的上限。 在IBM（至少-对于我而言）是18位数字。 MicroFocus有38位数字。
准确性要花多少钱？
我们刚才讨论的所有内容旨在表明COBOL的计算性能不比其他更常见的编程语言更好。 由于定点数大小的限制，COBOL实际上可能不如那些使开发人员可以更好地控制正在发生的事情的语言。
但是有一个功能。 事实是Python（和Java）没有对定点数的内置支持。 在COBOL中，这种支持是。
要在Python中执行定点计算，我必须导入
Decimal模块。 如果您曾经使用过具有大量导入命令的项目，则应注意，每个这样的命令都有一定的“价格”。 在像Java这样的语言中（即，那些将要摆脱COBOL的人通常会考虑使用这种语言），合适的库的“价格”可能会
更高 。 实际上，这实际上是一个问题，即导入库的“成本”在您的项目中是否起任何作用。 对于许多程序员而言，考虑导入命令对性能的影响是过早优化的顶峰。
但是，COBOL程序员通常在需要每秒处理数百万甚至数十亿次操作的系统上工作，以准确，可靠地进行处理。 而且，不幸的是，很难为COBOL提出令人信服的论点，或在这种情况下提出反对意见，因为实际上这是无数变化的领域。 选择解决此类问题的语言时，COBOL内置的定点支持是否是决定因素？ 还是可以通过选择处理器，内存，操作系统的正确组合来解决相应的问题？ 或者，也许是为了解决快速，准确和可靠的计算问题，您需要诉诸“手鼓跳舞”吗？ 也许-我们将限制推理？ 我们将简化他们的工作，以找到问题的答案，例如“如果使用相同的硬件，哪个更好-COBOL或Java？”。 但是即使如此，当系统开始每秒执行上述数十亿次操作时，我们仍然很难评估每种语言的缺点将如何影响性能。 结果，我们只能说相同的COBOL和Java是非常不同的语言。
这是他们
在这里写的内容，探讨了从COBOL代码转换来的Java代码的性能。
COBOL是一种使用支持指针和联接的堆栈的编译语言。 在程序执行期间，类型转换不会对系统造成负担。 程序执行期间没有计划或类型转换。 另一方面，Java代码在虚拟机中运行。 它使用一堆，不支持联接。 类型转换在程序执行期间给系统带来压力。 Java在运行时使用动态调度和类型推断。 尽管可以最大程度地减少使用这些功能，但是这通常导致这样的事实，即该代码或多或少与普通Java代码“不同”。 当研究从COBOL转换Java代码的结果时，他们通常会抱怨该代码不可读且不受支持。 这否定了从COBOL到Java的大多数目标。
在您决定用“是的，但是它是Java，Java也不是礼物”这一短语来排除这些论点之前，请记住：大多数现代编程语言绝对不内置对定点计算的支持。 （我认为说现代语言都不支持这种说法会更正确，但是我不能可靠地验证这一点。）当然，您可以选择另一种具有自己的优点和缺点的语言，但是如果在计算中需要准确性的话有一个固定点，并且如果您认为导入实现此类计算的库而导致的少量性能损失会损害您的利益，那么这意味着您唯一的选择-COBOL。
这就是所谓的“现代化”如此复杂的原因：它取决于许多因素。 一些组织将从更改软件平台的投资中获得切实的成果，而另一些组织会发现，他们已经失去了一些重要的东西，以换取“改进”，而实际上并没有太大改善。 如果组织是一个大型金融机构，每秒处理数百万笔交易，并且需要十进制精度的计算，那么实际上，培训专家使用COBOL会比为迁移到更流行的语言而付出的资源和生产力要便宜。 毕竟，普及是暂时的。
总结
因此，在谈到为什么仍然有许多组织仍在使用COBOL时，您需要了解处理程序的任务与创建程序的任务不同。 创建解决方案的程序员具有分阶段实施的优势。 应用程序通常会力求尽可能接近其技术支持的功能极限。 从COBOL迁移的困境不是从一种语言切换到另一种语言的问题。 这是从一种范式转移到另一种范式的任务。 Linux上的Java或Python限制与大型机上的COBOL限制完全不同。 在某些情况下，COBOL应用程序具有现代语言无法提供的功能。 对于这种情况，实际上，在现代大型机上使用COBOL将会是一种更便宜，生产效率更高且更准确的解决方案。
亲爱的读者们！ 您是否认为COBOL确实是一种在某些情况下确实比更现代的语言更好的语言？
