Code inertia. Huge amounts of existing code written in COBOL = prohibitive costs to switch everything over to another language. Wikipedia says there are over 200 billion lines of COBOL code in use.
Policy inertia. The places where COBOL is really in deep use tend to be government agencies and large businesses, which are notoriously slow to change.
Human inertia. People who make their living writing code and know many languages are less likely to consider it a big deal to learn a new one. People who learned one language because they needed to know it to perform what's otherwise a "business" job may not even think to switch.
I'm not so sure COBOL is preferred by big business and government. I would say tolerated might
be a better word.
Why?
Because big government/business is
risk adverse when it comes to managing their
financial systems. Screw up here and the whole
enterprise is put into jeopardy. If it ain't broke
don't fix it.
It is difficult to make a solid business case to
replace mission critical systems containing millions of lines
of code over what boils down to a "my language is better
than yours" type of argument – ok its more complex than that
but coming up with a solid business case is difficult.
Transaction volume. COBOL applications tend to be
optimized for throughput. Batch processing large
amounts of data is where COBOL really shines. Java
applications are somewhat harder to optimize for
throughput because of the tendency to have more infrastructure
layers between the program and the "metal" which
adds processing drag. Big business/government have a lot
of data to push through their systems and throughput is essential.
Cost per transaction. COBOL generally has a lower
cost per transaction when all factors are included.
This is partly because processing time
costs money, and COBOL applications are generally more
efficient. However, COBOL applications seem to have
lower development/maintenance costs too.
Before everyone jumps all over me for that last point
let me explain...
I work in
a very large shop and a few years ago an executive
decision was made to build all new systems in Java.
COBOL was going to be retained only for
maintenance of the existing legacy software base. A
complete phased out was planned for a 15 year time
horizon.
Some of the
best and brightest Java minds were brought in
to train, set up Best Practices, build infrastructure
and support for large scale Java development. This
initiative was well planned and executed. Then,
after a number of Java applications had been deployed
the "bean counting" started. The results were that
COBOL applications still cost less to develop,
maintain, support and run - long hard number crunching here
because the result was not welcome!
COBOL is back - but not completely.
The new executive direction is to keep COBOL for
heavy lifting (back end transaction processing) and
batch oriented applications. Basically COBOL is to be
used for number
crunching and business rule implementation. Java comes to the
front to provide GUI type interfaces and light-weight
processing.
I suspect this is probably the industry trend. COBOL isn't
going to disappear any time soon, but it may slip out
of sight behind the scenes where it supports new players up front.
First - I work for Micro Focus - so I am an interested party. However, I would turn the question back on its self. Why not? The inherent assumption is that C++, C# or Java are naturally going to be better because they are newer. However, COBOL has not stood still. Partly because of its wordy syntax, it has proven possible to add new features to COBOL so it has remained competitive. People quite often talk about how 'bad' COBOL is, but are comparing 30 year old COBOL to the latest version of C#, Ruby, etc.!
Indeed, the very history of COBOL is evolving, but it remaining backward compatible is a strong reason for a business to invest in it; the TCO is reduced because there isn't any need to rewrite.
For more on the very latest version of COBOL - check out the community site for Managed COBOL:
因此，几十年来，它是拥有最多编译器供应商支持的语言，也是 ISO 标准化程度最高的语言，只有 FORTRAN 能接近这一水平，但 FORTRAN 显然有一个完全不同的语言。目标受众。
第二个原因：因为即使在今天，对于经常发生的某些业务问题的某些方面，它也比我所知道的任何其他语言都要好。这些方面中最重要的是十进制算术。 Cobol 本身就有它（PL/1 等就是这种情况），但对于那些所谓的“更现代”的语言来说，情况并非如此。顺便说一句：这就是为什么这里有这么多关于“存储货币值的最佳数据类型是什么？”的问题的原因。提出这些问题的人只知道整个 IT 世界由一些 OO 语言和一些 ORM 工具组成，并且不知道为什么“金钱算术”这样的东西对于支持它的计算机语言可能是有用的原生，即计算机语言有一个内置的、原生的数据类型，除了bigint（程序员仍然必须跟踪小数位数）或float（程序员仍然负责在各处添加正确的舍入逻辑）。
Why did it catch on ?
Because in the late 1950's the US government decreed that if a software vendor wanted to sell an app or write an app for the government, the language had to be cobol.
As a consequence, for decades long it was the language that had the largest set of compiler vendors supporting it, and it was the language with the highest degree of ISO standardization, with only FORTRAN getting anywhere near that, but FORTRAN obviously had a completely different target audience.
Second reason : because even today, it is better than any other language I know for certain aspects of certain business problems that occur fairly frequently. The most important of these aspects is decimal arithmetic. Cobol has it natively (as is the case for PL/1 and such), but that is not true of any of those allegedly "more modern" langauges. Incidentally : that is the very reason why there are so many questions here regarding "what is the best data type for storing money values ?". The people asking those questions know no better than that the entire IT world consists of some OO language and some ORM tool, and have no idea of why such a thing a "money arithmetic" might be useful for a computer language to support it natively, i.e. for a computer language to have a built-in, native data type for it, other than bigint (with the programmer still having to keep track of the number of decimals), or float (with the programmer still being responsible for adding the correct rounding logic all over the place).
None of these languages offer what Cobol does -- fast, efficient processing large batches of data. It doesn't need graphics, it doesn't need bit-twiddling, it just needs to do what it does well -- accounting mostly.
C++ and C are ok substitutes for systems style stuff but they fall down on fixed point math and strong support for record oriented I/O. In the space where most financial and business apps live, z/OS, both Cobol and z/assembler have better native support for those things.
Java is good, safe, and workable. And on IBM mainframes, Java and Cobol interoperate very nicely. But some things that are easy to do in Cobol are very hard to do in Java, and the converse is true. They are complementing each other, not replacing each other. Java also does all it's fixed point math via library calls, which are much slower than native opcode support.
Python uses library (aka module) support for fixed point math as well as record I/O. It also suffers from a fatal, IMHO, design flaw of using indentation to delimit scope. This works reasonably ok in the relatively homogenous environment of Mac/Windows/Unix with some variant of ISO8859-1 character sets. It is prone to problems when moving back and forth between an ASCII-centric world and an EBCDIC-centric world where line terminators are not as simple as "\n\r, \r, \n" and any misconfiguration in a file transfer package, character conversion routine, or editing by a terminal configured for a different character set will destroy the scope of your source.
All of the languages you mention have weaknesses in critical business needs where Cobol is the strongest.
It works on machines that can hotswap any piece of hardware, and degrade gracefully if a processor dies. Reliability is everything when working with billions of dollars.
Those machines also support ridiculously large I/O speeds; if you can't handle a day's worth of transactions in real time, you're out of business.
It's been a stable language with very few deprecated bits since 1985.
The code isn't easily ported to another language, because developers didn't "plan" for that to ever happen. Moving the code that's powering systems today to another language is a risk and a very large cost.
Reliability counts for something, and COBOL has it in spades.
It was heavily pushed by IBM. This was a great help for Fortran and COBOL, although not PL/I.
It was available very early on, first appearing before 1960.
It was a lot easier than using assembler, even IBM System/360 assembler (which was a very nice one for business processing). It picked up a lot of people trying to do better than assembler.
It was a very good match for common business computing practices of the time. It was very good at accepting input, doing minor transformations, and spitting out reports. (It still is, for that matter, but businesses have far more diverse needs nowadays.)
It had some special features, such as decimal arithmetic while keeping track of decimal points, and record data types, that worked very well in business.
Cobol was invented to allow people who knew nothing about computer to write programs. This is exactly the kind of bad idea upon which Business, particularity American business thrives.
Good software requires high skill and good tools some of which will actually require real knowledge and understanding to use at all let alone well. High Skill levels tend to demand high pay, thus the search for the sliver bullet continues and high skill is actively discouraged. Don't believe me? Try these links
Many big companies, especially banks, have complex systems written in COBOL, which just simply work. Rewriting and designing such systems is observed by many such institutions as being a waste of resources including time and money. There's also the risk that certain requirement-specific features may be lost along the way. Hence the age old expression, if it ain't broke - don't fix it.
I worked ao c , c++ and java too.
all are advance n having grafical feature.
But when matter of Computing comes, means no hard works only business calculations and speculations. no one beat COBOL in efficiency.. and Huge data procesing,
Prossesing for a day or more then a day .. in Java or other language !!! forget.
its only cobol and mainframe.
the bleach of security. there is no bleach for last morethan 60 year in mainframe.
simplicity of code to handle in emergency or showstoper situation.
hey use front end in java,vb.net all, but for data keeping the rely on DB2.so cobol became must.
its all resons why leading banking firms thinking 10 time before migrate from mainframe to other.
[Vendor Post - but not necessarily the vendor's official statement]
There is certainly inertia, an install base, and risk of change are very valid reasons, but I would say there are good reasons within the language itself. If you want to do batch processing of large sets of data records or want to do financial calculations then the definitions of record layouts and numeric data types are better than any other language.
As NealB describes in his post, I've spoken to users whose natural environment and expertise is Java, but they keep the core logic in COBOL because it's the best tool for the job. They liberally mix Java (primarily for Unicode string manipulation and systems integration) with COBOL within the same application. If they compared the amount of code to do the same work in Java it just didn't make sense. Alex Turner has posted some great examples on another website comparing typical business functions in COBOL with Java.
发布评论
评论（11）
代码惰性。 用 COBOL 编写的大量现有代码 = 将所有内容转换为另一种语言的成本高昂。 维基百科表示正在使用的 COBOL 代码超过 2000 亿行。
政策惯性。 COBOL 真正深入使用的地方往往是政府机构和大型企业，而这些机构的变革速度是出了名的慢。
人类惰性。以编写代码为生并了解多种语言的人不太可能认为学习一门新语言有什么大不了的。那些学习一种语言的人，因为他们需要了解它来完成原本的“商业”工作，他们甚至可能不会考虑转换。
Code inertia. Huge amounts of existing code written in COBOL = prohibitive costs to switch everything over to another language. Wikipedia says there are over 200 billion lines of COBOL code in use.
Policy inertia. The places where COBOL is really in deep use tend to be government agencies and large businesses, which are notoriously slow to change.
Human inertia. People who make their living writing code and know many languages are less likely to consider it a big deal to learn a new one. People who learned one language because they needed to know it to perform what's otherwise a "business" job may not even think to switch.
我不太确定 COBOL 是否受到大企业和政府的青睐。我会说可以容忍
是一个更好的词。
为什么？
因为大政府/企业是
在管理他们的风险方面
金融系统。把这里和整个都搞砸了
企业陷入危险。如果它没有坏掉的话
不要修复它。
很难提出可靠的商业案例来
替换包含数百万条线路的关键任务系统
代码归结为“我的语言更好”
比你的”类型的论证——好吧，它比那更复杂
但提出可靠的业务案例很困难。
交易量。 COBOL 应用程序往往是
针对吞吐量进行了优化。批量处理大
数据量是 COBOL 真正的亮点。爪哇
应用程序有点难以优化
由于倾向于拥有更多基础设施而产生的吞吐量
程序和“金属”之间的层
增加处理阻力。大企业/政府有很多
通过系统传输的数据量和吞吐量至关重要。
每笔交易的成本。 COBOL 通常具有较低的
考虑所有因素后每笔交易的成本。
这部分是因为处理时间
需要花钱，而且COBOL应用程序一般都比较多
高效的。然而，COBOL 应用程序似乎有
开发/维护成本也较低。
在每个人都为我最后一点而欢呼雀跃之前
让我解释一下...
我工作于
一家非常大的商店和几年前的一位高管
决定用 Java 构建所有新系统。
COBOL 将仅保留用于
维护现有的遗留软件库。一个
计划用 15 年时间完全淘汰
地平线。
一些
引进了最优秀、最聪明的爪哇人才
培训、建立最佳实践、建设基础设施
并支持大规模Java开发。这
倡议经过精心策划和执行。然后，
部署了许多 Java 应用程序后
“数豆子”开始了。结果是
COBOL 应用程序的开发成本仍然较低，
维护、支持和运行 - 长期艰苦的数字运算
因为结果不受欢迎！
COBOL 回来了——但还没有完全回来。
新的执行方向是保留 COBOL
繁重的工作（后端事务处理）和
面向批处理的应用程序。基本上 COBOL 是
用于号码
处理和业务规则实施。 Java 来到了
前端提供GUI类型界面，轻量级
加工。
我想这可能是行业的趋势。 COBOL 不是
很快就会消失，但也可能会溜走
它在幕后为新玩家提供支持。
I'm not so sure COBOL is preferred by big business and government. I would say tolerated might
be a better word.
Why?
Because big government/business is
risk adverse when it comes to managing their
financial systems. Screw up here and the whole
enterprise is put into jeopardy. If it ain't broke
don't fix it.
It is difficult to make a solid business case to
replace mission critical systems containing millions of lines
of code over what boils down to a "my language is better
than yours" type of argument – ok its more complex than that
but coming up with a solid business case is difficult.
Transaction volume. COBOL applications tend to be
optimized for throughput. Batch processing large
amounts of data is where COBOL really shines. Java
applications are somewhat harder to optimize for
throughput because of the tendency to have more infrastructure
layers between the program and the "metal" which
adds processing drag. Big business/government have a lot
of data to push through their systems and throughput is essential.
Cost per transaction. COBOL generally has a lower
cost per transaction when all factors are included.
This is partly because processing time
costs money, and COBOL applications are generally more
efficient. However, COBOL applications seem to have
lower development/maintenance costs too.
Before everyone jumps all over me for that last point
let me explain...
I work in
a very large shop and a few years ago an executive
decision was made to build all new systems in Java.
COBOL was going to be retained only for
maintenance of the existing legacy software base. A
complete phased out was planned for a 15 year time
horizon.
Some of the
best and brightest Java minds were brought in
to train, set up Best Practices, build infrastructure
and support for large scale Java development. This
initiative was well planned and executed. Then,
after a number of Java applications had been deployed
the "bean counting" started. The results were that
COBOL applications still cost less to develop,
maintain, support and run - long hard number crunching here
because the result was not welcome!
COBOL is back - but not completely.
The new executive direction is to keep COBOL for
heavy lifting (back end transaction processing) and
batch oriented applications. Basically COBOL is to be
used for number
crunching and business rule implementation. Java comes to the
front to provide GUI type interfaces and light-weight
processing.
I suspect this is probably the industry trend. COBOL isn't
going to disappear any time soon, but it may slip out
of sight behind the scenes where it supports new players up front.
首先 - 我在 Micro Focus 工作 - 所以我是感兴趣的一方。然而，我会把这个问题转回到它本身。为什么不呢？固有的假设是 C++、C# 或 Java 自然会更好，因为它们更新。然而，COBOL 并没有停滞不前。部分原因是由于其冗长的语法，事实证明可以向 COBOL 添加新功能，因此它保持了竞争力。人们经常谈论 COBOL 有多“糟糕”，但却将 30 年前的 COBOL 与最新版本的 C#、Ruby 等进行比较！
事实上，COBOL 的历史正在不断发展，但它保持向后兼容性是企业投资它的一个强有力的理由；由于无需重写，因此降低了 TCO。
有关最新版本 COBOL 的更多信息 - 请查看托管 COBOL 的社区网站：
http://knol.google.com/k/alex-turner/micro-focus-management-cobol/2246polgkyjfl/4
First - I work for Micro Focus - so I am an interested party. However, I would turn the question back on its self. Why not? The inherent assumption is that C++, C# or Java are naturally going to be better because they are newer. However, COBOL has not stood still. Partly because of its wordy syntax, it has proven possible to add new features to COBOL so it has remained competitive. People quite often talk about how 'bad' COBOL is, but are comparing 30 year old COBOL to the latest version of C#, Ruby, etc.!
Indeed, the very history of COBOL is evolving, but it remaining backward compatible is a strong reason for a business to invest in it; the TCO is reduced because there isn't any need to rewrite.
For more on the very latest version of COBOL - check out the community site for Managed COBOL:
http://knol.google.com/k/alex-turner/micro-focus-managed-cobol/2246polgkyjfl/4
为什么它流行起来？
因为在 1950 年代末，美国政府颁布法令，如果软件供应商想要出售应用程序或为政府编写应用程序，则语言必须是 cobol。
因此，几十年来，它是拥有最多编译器供应商支持的语言，也是 ISO 标准化程度最高的语言，只有 FORTRAN 能接近这一水平，但 FORTRAN 显然有一个完全不同的语言。目标受众。
第二个原因：因为即使在今天，对于经常发生的某些业务问题的某些方面，它也比我所知道的任何其他语言都要好。这些方面中最重要的是十进制算术。 Cobol 本身就有它（PL/1 等就是这种情况），但对于那些所谓的“更现代”的语言来说，情况并非如此。顺便说一句：这就是为什么这里有这么多关于“存储货币值的最佳数据类型是什么？”的问题的原因。提出这些问题的人只知道整个 IT 世界由一些 OO 语言和一些 ORM 工具组成，并且不知道为什么“金钱算术”这样的东西对于支持它的计算机语言可能是有用的原生，即计算机语言有一个内置的、原生的数据类型，除了bigint（程序员仍然必须跟踪小数位数）或float（程序员仍然负责在各处添加正确的舍入逻辑）。
Why did it catch on ?
Because in the late 1950's the US government decreed that if a software vendor wanted to sell an app or write an app for the government, the language had to be cobol.
As a consequence, for decades long it was the language that had the largest set of compiler vendors supporting it, and it was the language with the highest degree of ISO standardization, with only FORTRAN getting anywhere near that, but FORTRAN obviously had a completely different target audience.
Second reason : because even today, it is better than any other language I know for certain aspects of certain business problems that occur fairly frequently. The most important of these aspects is decimal arithmetic. Cobol has it natively (as is the case for PL/1 and such), but that is not true of any of those allegedly "more modern" langauges. Incidentally : that is the very reason why there are so many questions here regarding "what is the best data type for storing money values ?". The people asking those questions know no better than that the entire IT world consists of some OO language and some ORM tool, and have no idea of why such a thing a "money arithmetic" might be useful for a computer language to support it natively, i.e. for a computer language to have a built-in, native data type for it, other than bigint (with the programmer still having to keep track of the number of decimals), or float (with the programmer still being responsible for adding the correct rounding logic all over the place).
这些语言都无法提供 Cobol 所提供的功能——快速、高效地处理大批量数据。它不需要图形，也不需要一些琐事，它只需要做它擅长的事情——主要是会计。
C++ 和 C 是系统风格的不错替代品，但它们在定点数学和对面向记录的 I/O 的强大支持方面表现不佳。在大多数金融和商业应用程序所在的领域，z/OS、Cobol 和 z/assembler 对这些东西都有更好的本机支持。
Java 很好、安全、可行。在 IBM 大型机上，Java 和 Cobol 可以很好地互操作。但有些在 Cobol 中很容易做到的事情在 Java 中却很难做到，反之亦然。它们是相互补充，而不是相互取代。 Java 还通过库调用完成所有定点数学运算，这比本机操作码支持慢得多。
Python 使用库（又名模块）支持定点数学以及记录 I/O。恕我直言，它还存在一个致命的设计缺陷，即使用缩进来界定范围。在具有 ISO8859-1 字符集的某些变体的 Mac/Windows/Unix 相对同质环境中，这可以正常工作。在以 ASCII 为中心的世界和以 EBCDIC 为中心的世界之间来回移动时，很容易出现问题，其中行终止符不像“\n\r、\r、\n”那么简单，并且文件传输包中的任何配置错误、字符转换例程或通过配置为不同字符集的终端进行编辑将破坏源的范围。
您提到的所有语言在关键业务需求方面都有弱点，而 Cobol 是最强的。
None of these languages offer what Cobol does -- fast, efficient processing large batches of data. It doesn't need graphics, it doesn't need bit-twiddling, it just needs to do what it does well -- accounting mostly.
C++ and C are ok substitutes for systems style stuff but they fall down on fixed point math and strong support for record oriented I/O. In the space where most financial and business apps live, z/OS, both Cobol and z/assembler have better native support for those things.
Java is good, safe, and workable. And on IBM mainframes, Java and Cobol interoperate very nicely. But some things that are easy to do in Cobol are very hard to do in Java, and the converse is true. They are complementing each other, not replacing each other. Java also does all it's fixed point math via library calls, which are much slower than native opcode support.
Python uses library (aka module) support for fixed point math as well as record I/O. It also suffers from a fatal, IMHO, design flaw of using indentation to delimit scope. This works reasonably ok in the relatively homogenous environment of Mac/Windows/Unix with some variant of ISO8859-1 character sets. It is prone to problems when moving back and forth between an ASCII-centric world and an EBCDIC-centric world where line terminators are not as simple as "\n\r, \r, \n" and any misconfiguration in a file transfer package, character conversion routine, or editing by a terminal configured for a different character set will destroy the scope of your source.
All of the languages you mention have weaknesses in critical business needs where Cobol is the strongest.
它适用于可以热插拔任何硬件的机器，并且在处理器失效时可以正常降级。在处理数十亿美元的业务时，可靠性就是一切。
这些机器还支持高得离谱的 I/O 速度；如果您无法实时处理一天的交易量，您就会破产。
自 1985 年以来，它一直是一种稳定的语言，几乎没有被弃用的位。
代码不容易移植到另一种语言，因为开发人员没有“计划”这种情况的发生。将当今系统的代码转移到另一种语言是有风险的，而且成本很高。
可靠性很重要，COBOL 确实具备这一点。
It works on machines that can hotswap any piece of hardware, and degrade gracefully if a processor dies. Reliability is everything when working with billions of dollars.
Those machines also support ridiculously large I/O speeds; if you can't handle a day's worth of transactions in real time, you're out of business.
It's been a stable language with very few deprecated bits since 1985.
The code isn't easily ported to another language, because developers didn't "plan" for that to ever happen. Moving the code that's powering systems today to another language is a risk and a very large cost.
Reliability counts for something, and COBOL has it in spades.
为什么它流行起来？
它受到 IBM 的大力推动。这对于 Fortran 和 COBOL 来说是一个很大的帮助，尽管不是 PL/I。
它很早就可用，首次出现在 1960 年之前。
它比使用汇编器容易得多，甚至 IBM System/360 汇编程序（对于业务处理来说这是一个非常好的汇编程序）。它吸引了很多人尝试比汇编程序做得更好。
这非常适合当时常见的商业计算实践。它非常擅长接受输入、进行微小的转换以及输出报告。 （就这一点而言，现在仍然如此，但如今企业的需求更加多样化。）
它有一些特殊的功能，例如在跟踪小数点的同时进行十进制算术，以及记录数据类型，这些功能在商业中非常有效。
Why did it catch on?
It was heavily pushed by IBM. This was a great help for Fortran and COBOL, although not PL/I.
It was available very early on, first appearing before 1960.
It was a lot easier than using assembler, even IBM System/360 assembler (which was a very nice one for business processing). It picked up a lot of people trying to do better than assembler.
It was a very good match for common business computing practices of the time. It was very good at accepting input, doing minor transformations, and spitting out reports. (It still is, for that matter, but businesses have far more diverse needs nowadays.)
It had some special features, such as decimal arithmetic while keeping track of decimal points, and record data types, that worked very well in business.
Cobol 的发明是为了让对计算机一无所知的人也能编写程序。这正是商业，特别是美国商业蓬勃发展的坏主意。
好的软件需要高技能和好的工具，其中一些实际上需要真正的知识和理解才能使用，更不用说很好了。高技能水平往往需要高薪，因此对银子弹的寻找仍在继续，高技能水平受到积极阻止。不相信我？尝试这些链接
http://userweb.cs.utexas.edu /users/EWD/transcriptions/EWD12xx/EWD1284.html
Cobol was invented to allow people who knew nothing about computer to write programs. This is exactly the kind of bad idea upon which Business, particularity American business thrives.
Good software requires high skill and good tools some of which will actually require real knowledge and understanding to use at all let alone well. High Skill levels tend to demand high pay, thus the search for the sliver bullet continues and high skill is actively discouraged. Don't believe me? Try these links
http://userweb.cs.utexas.edu/users/EWD/transcriptions/EWD12xx/EWD1284.html
许多大公司，尤其是银行，都有用 COBOL 编写的复杂系统，而且可以简单地运行。许多此类机构认为重写和设计此类系统是浪费资源，包括时间和金钱。还存在某些特定于需求的功能可能会在此过程中丢失的风险。因此，有句古老的说法：如果它没有坏，就不要修理它。
Many big companies, especially banks, have complex systems written in COBOL, which just simply work. Rewriting and designing such systems is observed by many such institutions as being a waste of resources including time and money. There's also the risk that certain requirement-specific features may be lost along the way. Hence the age old expression, if it ain't broke - don't fix it.
我也工作过 c、c++ 和 java。
一切都是先进的并且具有图形特征。
但当计算问题出现时，就意味着没有辛苦的工作，只有商业计算和猜测。在效率和海量数据处理方面，没有人能打败 COBOL，
用 Java 或其他语言处理一天或一天以上！忘记。
它唯一的 cobol 和大型机。
这就是为什么领先的银行公司在从大型机迁移到其他主机之前要考虑十次的原因。
I worked ao c , c++ and java too.
all are advance n having grafical feature.
But when matter of Computing comes, means no hard works only business calculations and speculations. no one beat COBOL in efficiency.. and Huge data procesing,
Prossesing for a day or more then a day .. in Java or other language !!! forget.
its only cobol and mainframe.
its all resons why leading banking firms thinking 10 time before migrate from mainframe to other.
[供应商帖子 - 但不一定是供应商的官方声明]
当然，惰性、安装基础和更改风险都是非常正当的理由，但我想说语言本身也有很好的理由。如果您想要对大量数据记录进行批处理或想要进行财务计算，那么记录布局和数字数据类型的定义比任何其他语言都更好。
正如 NealB 在他的文章中所描述的，我曾与那些自然环境和专业知识都是 Java 的用户交谈过，但他们保留了 COBOL 中的核心逻辑，因为它是完成这项工作的最佳工具。他们在同一应用程序中自由地混合 Java（主要用于 Unicode 字符串操作和系统集成）与 COBOL。如果他们比较在 Java 中完成相同工作所需的代码量，那就没有意义了。 Alex Turner 在另一个网站上发布了一些很好的示例，比较了 COBOL 和 Java 中的典型业务功能。
[Vendor Post - but not necessarily the vendor's official statement]
There is certainly inertia, an install base, and risk of change are very valid reasons, but I would say there are good reasons within the language itself. If you want to do batch processing of large sets of data records or want to do financial calculations then the definitions of record layouts and numeric data types are better than any other language.
As NealB describes in his post, I've spoken to users whose natural environment and expertise is Java, but they keep the core logic in COBOL because it's the best tool for the job. They liberally mix Java (primarily for Unicode string manipulation and systems integration) with COBOL within the same application. If they compared the amount of code to do the same work in Java it just didn't make sense. Alex Turner has posted some great examples on another website comparing typical business functions in COBOL with Java.