除了旧版软件，还有其他使用COBOL的理由吗？

COBOL仍（大量使用）用于财务计算。这是一种古老的语言，大多数程序员都不喜欢或至少不喜欢COBOL，这是AFAIK。这就带来了一个问题：遗留软件仍在使用COBOL的唯一原因还是它比其他编程语言具有任何真正的优势？

只是好奇。

现在大部分都是遗留的。许多关键业务系统仍然存在于COBOL中，仅仅是因为它们是如此之大和集成，以致于重写成本似乎并不值得。用COBOL编写新系统可能不再可行，因为大多数COBOL开发人员都非常匮乏，以至于他们可以花很多钱来获得专门技能（类似于现在的Foxpro开发人员）。几乎没有理由要保留COBOL应用程序，但是不幸的是，常见的推理是当COBOL应用程序已经就位，可信赖并且与其他系统紧密耦合而无法替换时。正是出于这种原因，才应该替换它，直到必须从80/90年代的Ebay部件中定制运行该应用程序的唯一硬件。

COBOL仍（大量使用）用于财务计算。

是吗？

这取决于您所谓的财务计算。如果您调用由金融机构运行的所有代码，则可能是这样。大多数企业都有60年代和70年代制定的业务规则。将这样的系统升级到新环境的风险+成本是不值得的。我怀疑是否有人在编写新的COBOL代码。例如，当今有一些COBOL编译器集成到.NET堆栈中。通常，有一些工具可以将遗留应用程序集成和利用到现代软件堆栈中，但是对于那些不必使用它们的人来说，这些工具通常是未知的，因为这是一个非常特殊的市场。

现在，如果您称金融计算为类似于定量金融的软件之类的东西，那么我从来没有听说过有人在使用COBOL。C ++在一些特殊的语言（如APL衍生词k）中更为常见。

COBOL现在大多看到了遗留用途。由于没有新的应用程序正在编写，而旧的应用程序正在缓慢但肯定会被淘汰，因此它的用户基础正逐渐减少。

可以快速而便宜地替换的大多数COBOL系统已经被替换了。相对而言，那些没有更新，修理或更换的费用越来越高，但是相对于更新的系统而言，它们的价格却越来越低廉-它们在廉价的过时硬件上运行良好，并且经过多年的服务，不再显示任何新错误。大多数错误已被修复，或者具有很长的历史记录，可以作为解决方法。维护工作通常只需要减少一到两个专门的员工，他们在长时间使用系统后，对系统的了解就会比您想像的更为亲密。

即使从技术角度来看，通常也有一些合理的理由可以保留旧系统。它们相对稳定，大部分已被错误修复，并且为最终用户所熟知/理解。

不过，您会看到系统最终将被替换。通常，此举来自业务方面：

• 当前系统的用户已被年轻用户取代，他们无法说服他们学习如何使用旧界面
• 与其他员工的薪水相比，该公司找不到可雇用的人来维护系统
• 预算巨大的人会发现公司的核心系统运行在可以由笔记本电脑上的虚拟机取代的硬件上感到尴尬
• 随之而来的是一个新的商品系统，开始使用它真的很便宜
• 使用旧系统的公司被收购，破产或以其他方式停止存在
• 新的，迫切需要的功能的关键点，不能便宜地与旧系统进行交互

想知道您所说的“大多数程序员”是什么意思。我在与cobol程序员，Java程序员，.NET程序员（单数），老式VB程序员在同一楼层的一家大型IT商店工作。没有仇恨或厌恶。cobol是一种与任何其他编程语言一样的语言-使用cobol进行编程的人之所以这样做，是因为这对他们而言是一项工作，与使用Java编程或驾驶卡车没什么不同。与在美国流行的概念相反，有很多cobol仍在继续编写，只有大部分在印度，每天都有新的Cobol程序员开始工作。

我认为之所以用Cobol编写太多新的网络新系统的原因是因为适合Cobol的那种系统（大容量文件处理）已经全部编写。如今，很少有新的大型公司成立。这样做的确可能是将薪资和福利等业务外包给运行旧式cobol系统的公司。

PeopleSoft中的大部分核心代码是用COBOL编写的。

凭借20年的COBOL经验，在三个不同的大型机上，我很少见到真正的COBOL程序员，而只有IBM程序员，Sperry（Unisys 2200）程序员，Burroughs（Unisys MCP）程序员和Tandem（HP NonStop）程序员。为了表示对他们的尊重，我还必须提到HP 3000程序员，BULL程序员和DEC程序员。

大多数情况下，COBOL在大型铁箱上运行。按照我自己的标准，也许唯一真正的COBOL程序员是在UNIX机器上编写COBOL的程序员。哇，我要听听这个。

因为硬件是核心，所以大多数编写COBOL的程序员都是通过运行其编写代码的硬件来标识自己的。多年来，在听其他程序员告诉我有关Sperry，Burroughs或Tandem的优点时，我经常想知道如果我将它们围起来并将它们放到一个不能离开的房间里会发生什么样的战争。同意为所有COBOL使用一个硬件平台。我没有提到其他平台，因为我从未在这些平台上工作过。

我已经与许多IBM程序员见过面并进行了交谈，他们将自己称为COBOL程序员。但是，如果让他们参与对话，他们会很快开始参考IBM特定的过程和工具。鉴于COBOL的以硬件为中心的性质，这对于所有硬件平台都是非常容易理解的。

因为COBOL通常绑定到非常昂贵的硬件，所以只要该硬件运行在其上编译的COBOL程序，就不会出于迁移的目的强烈地希望从COBOL进行迁移。但是，随着COBOL程序员的老化，迁移是不可避免的。

由于所有运行COBOL的大型铁箱也将运行Java，因此Java是从COBOL迁移的自然途径。可以以相当经济的价格转换代码，尤其是在经济低迷时期。一旦在昂贵的大型硬件上没有了COBOL，只有Java，那么组织中更高层次的人就会开始怀疑是否有可能将Java代码转移到其他便宜得多的硬件上。

IBM，Sperry，Burroughs和Tandem程序员都知道这一点，因此他们可能永远也不会提出这个想法。对某些人来说这将是一种牺牲。