为什么对COBOL轻视？[关闭]

当人们提到COBOL时，通常会打喷嚏或吟。我对COBOL不太了解，但是我已经看过其中写的一些程序。我可以看到这很罗word，而且对于像我这样的初学者来说，这是难以理解的。但是，真的，不是所有的编程语言都对一个外行人来说完全是胡言乱语吗？

我了解它可以正常工作，并且在其设计的行业中仍在广泛使用。这些不是一门好语言的标志吗？COBOL有什么不好的呢？

COBOL是我学习的最早的语言之一-如果您忽略无数的Basic版本，三种或四种汇编语言以及Forth的一种变体，那么它就是我的前五种，并且是与Pascal一起学习的。IOW，我是从使用该语言的个人经验中回答的。

编辑我应该说古老的经验。80年代末后，我再也没有使用过这种语言，尽管我确实买了一本新书（以取代我厌恶扔掉的那本旧书），所以我可以参考一些东西，这样我的恐怖故事就不会太扭曲。但是我不知道这种语言至少在最近20年中是如何发展的。

显然，对于很多人来说，它是只是“老坏”查看jonsca已经描述-也更是一个三手传递我向下态度的事情。但是存在真正的问题。

过于罗word是一个真正的问题-理解代码的方式过于混乱。这是迄今为止最大的问题。人谁看MOVE，ADD和MULTIPLY惊恐等语句对此有略带夸张的观点，真正的-该COMPUTE声明是在其他语言更接近分配。但是在所有这些部门中仍然有很多混乱情况。我在COBOL中学到的第一件事就是始终从复制标准的A4长的SKELETON.COB页开始。

COBOL 确实具有一些有趣的功能，但是那些功能（例如，PIC事物）趋向于成为如今已成为DBMS而不是编程语言的一部分的事物，在我看来，这通常是分离这些职责的更好方法。同样，其他语言的某些库使用的内容与之相当PIC（例如，C标准库中的printf和scanf）。可以说，最好的保留了，但是最坏的保留了。

此外，对于每一项好功能，至少有一个无法忍受的功能。例如，不管循环多么琐碎，您都必须将主体移到单独的过程中。在PERFORM ... UNTIL ...和类似表述是单一语句-不会阻塞结构。从某种意义上说，COBOL是结构化程序设计的结构，从编程前一尝被发明-那里是一个GO TO，但它的使用是不鼓励（至少当我用COBOL），但特别是循环刚没有处理好的。

实际上，在 COBOL 之后使用的最让我想起的语言是dBase。与Ashton-Tate dBase III +中一样。如今，人们更有可能记得所有导致通用名称xBase的现已死去或垂死的克隆（Clipper，FoxPro等），并且xHarbour中仍然有活着的后代。关键是这些是数据库语言，但与SQL完全不同。

即使这样，在特定数据库上运行的每个 COBOL程序都需要包括该数据库规范的副本（并且副本最终可能会不一致），而在xBase中实际上并不是这种情况，因为xBase知道数据库是自己的结构。

因此，考虑到这一点，如果您接受它，那么COBOL并不那么糟糕。但是它不是一种用于编写数据结构的语言。这可能就是为什么COBOL在C与Pascal的圣战时期遭受了很多痛苦的原因-双方都可以同意，COBOL不利于再次重塑二叉树。

哦，我永远不会忘记的是，我的第一本COBOL教科书是如何不描述该SORT命令的，并说这不在本书的讨论范围之内- 显然，作者无法应付排序的想法，或者认为这超出了COBOL学生的小头脑所能应付的范围（请参阅最后的编辑）。这种事情使认真对待COBOL变得非常困难。

一个奇怪的方面是杰克逊结构化编程，我也被迫在大约同一时间学习，特别是与COBOL一起使用。其中一部分是绘制输入的结构图，然后绘制输出的结构图，然后绘制代码的中间结构图。显然，排序是一个已经解决的问题-您无法以这种方式派生排序算法。因此，在推荐的教科书中得知排序的整个概念超出了我的小脑子，这很奇怪，而同时却教给了诸如十几种不同的排序算法以及如何在Pascal中实现它们的知识。

JSP可以解决的问题可能是COBOL可以做得相对好的事情的一个很好的指南。但是即使那样，这也不一定意味着JSP或COBOL都是解决这些问题的好方法。

2014年7月30日编辑

由此，我的声誉得到了提升，提醒我它就在这里。碰巧的是，由于收集了一些怀旧的古代书籍，我现在可以更正WRT SORT命令了。

我最初在学习COBOL时用作推荐的书是Ray Welland撰写的“ COBOL中的方法编程”。这并不涵盖COBOL 85（尽管我还从未见过更高版本的“ COBOL-85中的方法编程”）。

kindall在下面的评论中说：“您应该在读取输入文件之前对其进行排序，或者使用操作系统随附的sort实用程序对生成的输出文件进行排序”。从我的答复中，我错过了“使用操作系统”的观点。Kindall提出了与Unix哲学AFAICT类似的建议，其中COBOL用于它所擅长的位，OS实用程序（例如用于其他用途的sort实用程序），大概使用批处理/脚本/ shell语言将这些位粘合在一起。这在一个古老的世界中更为有意义，在这个古老的世界中，交互软件很少见，因此您将提交大量的工作（因此称为“批处理语言”）。

以下是“ COBOL中的方法编程”第165-166页的引文...

使用有序的串行文件意味着必须要有一种通过密钥将文件中的记录按某种指定顺序排序的方法。大多数大型计算机系统都有一个排序实用程序，该实用程序将根据构成密钥的每个数据项的位置，类型和大小对文件进行排序。

还可以从COBOL程序中对记录进行排序，但这超出了本书的范围，原因有二：

（a）操作系统的接口通常很复杂，并且因系统而异，

（b）排序模块是ANS '74 COBOL的可选部分，可能无法在小型计算机的COBOL系统中实现。

因此，将假定存在用于将文件分类为指定顺序的工具，并且将考虑更新此类文件的问题。

简而言之，kindall是正确的-假设通常在COBOL之外进行排序。甚至在1974年左右，对于小型计算机，从编程语言中排除排序可能甚至是有道理的。

我上面所说的基本上是您由于扔掉书而无法检查事实大约20年后得到的。

不过，我仍然应该指出，我从这本推荐的书中正式学习了COBOL，该书涵盖了1988年和1989年的1974年标准（而不是1985年标准）。“学生的COBOL”第三版（帕金，约克，巴恩斯）-关于COBOL 85的第一版直到1990年才发行。我不确定，但是我认为直到1994年才发行“方法编程”的COBOL 85版。

但这并不一定代表COBOL世界在拖延脚步-嗯，无论如何，并没有那么多。对于任何一种语言来说，采用新标准都需要花费时间，即使是现在。

今天大部分时间都在写一些COBOL，我想我可以提供一些当前的意见。

首先是坏东西：

• 没有函数调用。现代COBOL具有一些内置函数，但是编写自己的函数需要认真的工程工作。
• 子例程调用无类型检查。您可以在子例程调用中传递（或不传递）任何内容，被调用子例程会毫无疑问地假设其具有正确的参数，并且无法检测到丢失或无效的参数。
• 没有图书馆。无零压缩。没有标准库，没有广泛使用的易于使用的库。您最终要一遍又一遍地编码社区任务。
• 一切都实现为关键字。因为语言作者没有库的概念，所以每个新功能最终都使用新的关键字（例如支持XML的PARSE和RENDER）实现。

误解，即那些通常针对无效或无关紧要的古老语言的批评。

• 详细。因此，您输入了一些额外的字符！这不是一个严重的问题。在许多情况下，COBOL的详细程度不如Java。

• “ COBOL FILES”您会看到这个词有很多歧义。仅仅是COBOL可以处理几乎任何文件格式和任何文件组织都没有。

• 没有多线程。在COBOL蓬勃发展的环境中，通常将多线程留给擅长于此的应用程序容器（如CICS或IMS），而不是倾向于擅长于此的程序员。

好东西-COBOL的某些方面优于其他语言：-

• 数据结构。COBOL具有简洁灵活的语法，用于定义复杂的数据结构和奇数数据类型。
• 十进制算术。它具有对十进制算术的原生支持，即会计所理解的算术，以及适当的舍入等。
• 与时俱进。COBOL的某些方面令人惊讶地是现代的。内置XML支持，对OO编程的支持，使用Java类的能力等。
• 与DB2，CICS等集成。这仅适用于IBM大型机COBOL（但这是迄今为止仍在运行的最大COBOL块），但与DB2，CICS和其他大型机环境的集成使编写诸如数据库支持之类的内容变得更容易Web服务比在任何其他环境中都好。
• 屏幕处理。在AS / 400和MicroFocus Cobol上实现的标准屏幕处理效果非常好。
• 性能。多年来，COBOL编译器一直在生产非常高性能的可执行文件。在IBM大型机上，只有本机C和本机Assembler击败了COBOL。

因此，对于1950年代一个委员会将其整合在一起的事情而言，它的所有方面都做得很好。如果现有的应用程序是在COBOL中实现的并且可以完成工作，则没有理由重新编写它。但是，除非有确凿的理由，否则我看不出任何新项目使用COBOL的理由。

这可能取决于Djikstra。Djikstra表示：“使用COBOL会使心灵瘫痪；因此，应将其教导视为刑事犯罪。” Cobol被认为是幼稚的，无组织的和冗长的。由于具有自我更改代码的能力（即使在cobol程序员中也不鼓励这样做），因此也很难调试或遵循。

然后，版本之间也存在很大的不兼容性。

我建议阅读Wikipedia中的批评和辩护部分以获取该语言-http://en.wikipedia.org/wiki/COBOL#Criticism_and_defense

年龄和冗长是导致人们对此it吟的典型原因。

我似乎记得，IBM在设计COBOL时的主要目的是“应该允许银行经理编写程序”。这个目标显然对语言的设计产生了深远的影响，并且现在它还在发展。

显然，野外使用的COBOL比其他任何语言都多。但是，在IT部门工作了近20年（在银行业工作了15年）之后，我再也没有遇到过实施过其中一个系统的系统。

COBOL有什么不好的呢？

没有。

我认为人们有一个先入为主的观念，即旧是坏的，“最新是最好的”。它仍在使用中，我敢肯定，再过半个世纪，代码方面将有足够的维护工作。

1997年，Gartner集团报告说，全世界80％的业务都是使用COBOL运行的，现有的代码行超过2000亿行，并且每年估计有50亿行新代码。（通过维基百科）

在编码中，必须始终为工作选择最佳工具，并且对于某些与某些硬件结合的行业，该语言是最佳的。我从没在银行工作过，听说这很流行，但是Sean的回答表明情况并非如此。

如果遗留代码看起来陈旧有问题，只要您可以在其前面放一个UI或Web界面，大多数用户甚至都不知道其中的区别。

人们不喜欢COBOL，因为它的应用范围有限。它设计用于公司和政府的业务，财务和管理系统。

所有这些有什么共同点？数据。很多数据。

猜猜谁设计的数据很紧，早餐时有很多文件？您能说COmmon商业导向语言吗？

50年前，对于需要管理大量数据的大型组织而言，COBOL是最好的选择。如今，有更好的方法来管理大量数据，因此COBOL不再相关。还是？

让我们考虑一下政府。政府需要跟踪哪些数据？人们的身份证，出生证明，病历，税收（哦……是……税收）等。而且，他们必须无限期地保存这些信息，今天和50年前也是如此。

人们还提到银行在某些答案中，实际上银行是COBOL的重度用户。为什么？因为与其他类型的公司不同，银行通常都有历史。有些已经存在了数百年（例如这一年）。

这意味着50年后的某些数据必须仍然存在，今天，2011年10月7日。现在我们有SQL Server，C＃或Oracle和Java，但是50年前有COBOL和文件。

随着时间的流逝，政府和银行的数据越来越大，迁移系统的成本越来越高。这意味着它们必须保留在COBOL中，并随着业务的发展而不断地维护和发展。一些银行正在缓慢迁移，而另一些银行只是在大型机前面保留了一个不错的Web2.0接口（c＃和Java是最常用的）。你能说遗留代码吗？（COBOL与（极端）遗留代码齐头并进，其中一些在几十年的历史中被许多人所感动-我们程序员不喜欢的另一件事：D）。

现在您有了一个利基的活动。现在COBOL的应用受到限制，您的经验受到影响。

进入COBOL的人们最终发现，一年又一年又一次又一次地重复做同样的事情，直到他们醒来时，他们已不再在市场上具有竞争力，因为人们现在想要PHP，Java，C＃ ，REST，jQuery和仅有的银行会寻找COBOL人员。

在这一点上，需求低于供应，那些没有削减的人必须转移到其他地方。而且他们必须从初级开始，因为COBOL确实会削弱思想（相信复制粘贴不是COBOL的主要开发风格，并说明了COBOL的高生产率），现在他们诅咒他们选择COBOL的那一天，并且不不要浪费任何机会讲述他们的恐怖故事了：）。但是，您可以讲讲那些如今不再需要的任何古老的放屁语言的故事，但是您是不幸的人。好吧...

由于其他人提到的所有其他原因，PS和COBOL不好：)

PS2。 In 1997, the Gartner Group reported that 80% of the world's business ran on COBOL with over 200 billion lines of code in existence and with an estimated 5 billion lines of new code annually.真？一天如何衡量呢？他们是否一字不漏地问每个公司，问他们有多少行COBOL？

两个特点。

• ALTER语句是纯粹的邪恶。尽管很少在更现代的COBOL应用程序中使用，但在“古老的时代”中大量使用它，因为它比等效的“ IF-GOTO”结构更有效。当计算机只有32K的RAM时，每条指令都很重要。它修改了GOTO语句以具有不同的目的地。

  因为代码本身是有状态的，所以这使某些代码变得不透明。

• 数据结构（如unionC中的REDEFINES子句）是一个永久性的问题。术语“自由联合”（即没有区分项的覆盖数据结构）是一种总结问题的方法。不能通过数据简单区分两个REDEFINES别名。只有广泛阅读程序逻辑才能确定字节的两种替代解释的含义。

  这使许多数据结构变得不透明，因为没有代码就无法理解数据。

这两种结构使英语式语法的可读性下降。

[主持人警告我说，简短的答案无视您的重要而有趣的问题。如果您发现此问题不屑一顾，则可以要求提供详细信息。或对其进行标记，以便主持人可以将其删除。]

我已经在COBOL中编程了好几年了。与当今的语言相比，它的语法很简单，您不需要太多的理论就可以开始学习。COBOL与IBM的CICS（在线事务管理系统）配合得很好，程序员需要注意代码以将应用程序的用户数量从1个增加到数千个。CICS提供了基于字符的GUI，该GUI将屏幕作为显示单位（没有窗口）使用。您可以在大型机上使用（IBM的GDDM）显示图表。COBOL可以与索引文件（VSAM和ISAM）以及DB2（基于SQL的关系）以及IMS进行通信。COBOL / CICS是一个非常强大的环境，您可以在几周内学会它。这意味着您专注于业务而不是技术，因此您需要8个小时中的7个小时从事编码工作，而不是学习MVM，JavaScript等。

COBOL的问题是营销不善，导致第三方缺乏为它开发工具和编程环境的兴趣。而且，由于缺乏对Windows之类的界面的支持，导致其在1993年以后的流行度下降。大型机的成本导致客户寻找替代品，并且在UNIX和DOS中提供了COBOL的编译器。C语言吸引了很多希望，因为它具有更高的可移植性，并且可以直接访问OS功能，而COBOL很少使用。

与DOS上的同类COBOL相比，VB，DBase，FoxPro和Clipper等语言在PC上具有更好的访问“数据库”的方式，因此COBOL丢失了。长期以来，CICS在DOS或UNIX上并不便宜，因此在这些环境中其价值不存在。

如今，.NET支持COBOL，但我猜想它已经失去了在所有平台上的战斗力，除了大型机（可能还有AS / 400），因为大型任务关键型应用程序完全依赖大型机（因此仍然存在）它。

嘿，我在80年代初上了大学，那时人们对COBOL一直很鄙视。我认为最大的问题是它的冗长程度-一个简单的“ Hello，world！” 在COBOL中可能超过五十行，其中95％是必需的样板。这不是一种非常优雅或吸引人的语言。它的设计还可以解决昨天的问题，并且实际上并不适合于大约1970年以后开发的开发范例。这是一种非常好的报告生成语言，只要您的报告是无数列的页眉和页脚即可。如果您想将图形或徽标粘贴在某处，请忽略它。我认为它仍然是用于“数据处理”类型任务的最快语言（使用具有5M ATM交易的固定格式文件，并对每个任务进行简单的余额调整），但是又有多少开发人员做这些事情呢？如今，许多系统都使用XML或JSON，我不愿意考虑尝试使用COBOL解析此类内容（实际上，我不愿考虑在COBOL中进行一般的解析！）