关于Cobol编程语言在这个论坛上的相关性有一些线索,例如这个线程链接到它们的集合.我对此感兴趣的是基于Gartner 1997年的一项研究经常重复的声明:当时有大约2000亿行代码正在使用中!
我想问一些问题来验证或伪造几个相关点.我的目标是了解这个陈述是否有任何真相,或者它是否完全不切实际.
我提前道歉是因为我对我不确定的事情表达我的思路和自己的看法有点冗长,但我认为这可能有助于把事情放在上下文中,从而突出我做出的任何错误的假设和结论.
有时候,"2000亿行"数字伴随着增加的声称,这相当于所有正在使用的语言中所有编程代码的80%.其他时候,80%只是指所谓的"商业代码"(或者其他一些模糊的短语,暗示读者不会算上主流软件,嵌入式系统或其他任何Cobol几乎不存在的东西).在下面我假设代码不包括对同一软件的多个安装的重复计算(因为这是作弊!).
特别是在y2k问题之前的时间,已经注意到许多Cobol代码已经有20到30年的历史了.这意味着它写于60年代末和70年代.那时,市场领导者是IBM和IBM/370大型机.IBM 在他的网站上公布了价格,配置和可用性的历史性公告.根据该表,对于具有高达半兆字节内存的机器,价格约为一百万美元.
问题1:实际销售了多少台大型机？
那段时间我没有找到任何数字; 的最新数据由Gartner对于2000年,再次.:^(
我猜想实际数字是数百或数千; 如果2000年的市场规模是500亿,并且市场像其他任何技术一样成倍增长,那么1970年可能仅仅几十亿.自IBM/370销售二十年以来,将产生二十万的二十倍在几万台机器中(这非常乐观)!
问题2:代码行中的程序有多大？
我不知道该架构上的一行源代码产生了多少字节的机器代码.但由于IBM/370是一台32位机器,所以任何地址访问都必须使用4个字节加上指令(2个,可能是3个字节？).如果算上该程序的操作系统和数据,那么有多少行代码可以放入半兆字节的主内存中？
问题3:没有标准软件吗？
每台售出的机器都运行一个独特的手动编码系统而没有任何标准软件吗？说真的,即使每台机器都是从头开始编程而没有重用遗留代码(等等......没有违反我们从一开始就开始使用的索赔之一),我们可能有O(50,000 loc/machine)*O(20,000台机器)= O(1,000,000,000 loc).
那仍然远远超过200亿!我错过了一些明显的东西吗？
问题4:我们需要多少程序员编写2000亿行代码？
我真的不确定这个,但如果我们平均每天10个位置,我们需要5500万人年来实现这一目标!在20到30年的时间范围内,这意味着必须有200到300万程序员不断编写,测试,调试和记录代码.那将是和我们今天在中国一样多的程序员,不是吗？
编辑:有几个人提出了自动模板系统/代码生成器等.有人可以详细说明这个吗？我有两个问题:a)我需要告诉系统它应该为我做什么; 因为我需要与计算机通信,计算机将输出代码.这正是编程语言的编译器所做的.所以基本上我使用不同的高级编程语言来生成我的Cobol代码.我不应该使用其他高级语言而不是Cobol吗？为什么中间人？b)在70年代和80年代,最珍贵的商品是记忆.因此,如果我有一个编程语言输出的东西,它应该更简洁.编辑结束
问题5:比赛怎么样？
到目前为止,我在这里提出了两件事:
1)IBM有自己的编程语言,PL/I.上面我假设大部分代码都是使用Cobol专门编写的.然而,在所有其他条件相同的情况下,我想知道IBM营销是否真的将自己的开发推向了市场,而不是Cobol在他们的机器上.PL/I真的没有相关的代码库吗？
2)有时候(也在上面引用的主题中的这个板上)我遇到了"2000亿行代码"对于"政府,银行......"(以及诸如此类)之外的任何人都是不可见的说法.实际上,国防部已经资助了他们自己的语言,以提高成本效益并减少编程语言的扩散.这导致他们使用Ada.如果他们主要使用Cobol,他们真的会担心拥有这么多不同的编程语言吗？如果在主流计算感知之外的"政府和军事"系统上运行任何语言,那么这种语言不会是阿达吗？
我希望有人可以指出我的假设和/或结论中的任何缺陷,并阐明上述声明是否有任何真相.
从表面上看,Gartner产生的数字类似于回答这个问题:有多少天使可以在别针头上跳舞？.除非你获得他们报告的完整副本(花费很多钱),否则你永远不会知道他们如何提出或证明了200亿行COBOL索赔的合理性.话虽如此,Gartner是一家备受尊重的信息技术研究和咨询公司,所以我认为如果没有正当理由或解释,他们就不会提出这样的要求.
这项研究多年来一直被引用是令人惊讶的.谷歌搜索"2000亿行COBOL"给我带来了大约19,500次点击.我对它们进行了一些采样,并且大多数将这个数字直接归因于1997年的Gartner报告.显然,这个数字引起了许多人的注意.
您用来"揭穿"声明的方法存在一些问题:
1)已售出多少大型机这本身就是一个很大的问题,可能与回答2000亿行代码问题一样困难.但更重要的是,我没有看到如何确定大型机的数量可以用来约束在它们上运行的代码行数.
2)代码行中的程序有多大？COBOL程序往往很大.一个适度的程序可以运行到几千行,一个大到几万行.COBOL程序员经常制作的一个笑话是,只编写了一个COBOL程序,其余的只是它的修改副本.和许多笑话一样,其中有一些道理.大多数商店都有大量的程序库存,而且很多程序都是通过相互切割和粘贴来构建的.这真的"松懈"了你的代码库的大小.
您假设程序必须适合物理内存才能运行是错误的.尺寸问题以几种不同的方式解决(例如程序覆盖,虚拟存储器等).在60年代和70年代,在具有微小物理记忆的机器上运行大型程序并不罕见.
3)没有标准软件吗？很多COBOL都是从头开始或从模板中编写的.70年代和80年代的软件公司开发了许多财务软件包.其中大部分都是作为源代码库分发的.然后,客户复制并修改源以满足其特定的业务需求.更加"松散"的代码库 - 特别是考虑到一旦包"已经配置",该代码的大部分在逻辑上是不可执行的.
4)我们需要多少程序员编写2000亿行代码而不是你想象的那么多!鉴于COBOL往往冗长且高度复制,程序员可以拥有巨大的"生产力".程序生成系统在70年代和80年代初流行.我曾经使用过一种产品(幸运的是已经不存在了),它让我编写了"业务逻辑",它生成了所有"锅炉板"代码 - 生成一个功能齐全的COBOL程序.它生成的代码是礼貌的,极端冗长.我可以从大约200行输入产生15K线COBOL程序!我们在这里严肃起来!
5)比赛怎么样？COBOL从未真正在金融和保险领域进行过如此激烈的竞争.PL/1是IBM的一项主要计划,旨在生成满足各种计算需求的编程语言.像所有这些举措一样,它过于雄心勃勃,而且几乎已经崩溃了.我相信IBM今天仍在使用和支持它.在70年代期间,预计其他几种语言将取代COBOL - ALGOL,ADA和C会浮现在脑海中,但没有一种语言可以解决.今天我听到了Java和.Net的相同说法.我认为COBOL仍然在我们身边的主要原因是,它做了它应该做得非常好的事情,并且巨大的数十亿行代码遗产使得转向"更好"的语言从商业角度来看既昂贵又有风险.
我相信2000亿行代码故事吗？考虑到COBOL代码随着时间的推移会使自己"松散"起来的方式,我发现这个数字很高但不可能高.
我也认为过分参与分析这些数字会迅速降级为"计数天使"练习 - 人们可以真正卷入其中但在现实世界中没有任何意义.
编辑
让我谈谈下面留下的一些评论......
从未见过投资银行使用过的COBOL程序.很有可能.取决于您所在的应用领域.投资银行往往拥有大型计算基础设施,并采用各种技术.我过去20年来一直在工作的商店(虽然不是投资银行)是该国最大的商店之一,它有大量的COBOL投资.它还拥有重要的Java,C和C++投资,以及人类已知的几乎所有其他技术.我还遇到了一些相当高级的应用程序开发人员,他们完全没有意识到COBOL仍在使用中.我通过源控制系统进行了粗略计算,发现了大约7000万行COBOL.在这里工作多年的相当多的人完全没有注意到它!
我也意识到COBOL作为一种选择语言正在迅速衰落,但事实是,今天仍然有很多.1997年,这个问题涉及的时期,我相信COBOL在LOC方面将成为主导语言.问题的关键是:1997年可能有2000亿行吗？
计算大型机.即使能够获得大型机的数量,也很难评估它们所代表的"计算"能力.与大多数其他计算机一样,大型机具有广泛的配置和处理能力.如果我们可以说1997年正在使用"X"大型机,那么你仍然需要估计它们所代表的处理能力,那么你需要弄清楚运行COBOL程序和其他一些工作负载的百分比.混淆因素.我只是不明白这种推理如何能够产生一个可接受的误差范围的答案.
多计数代码行.当提到COBOL"绒毛"因素时,这正是我的观点.计算COBOL行可能是一个非常误导性的统计数据,因为其中大部分都是程序员从未编写过的.或者如果是的话,使用cut-paste-tinker"设计模式"完成了相当多的工作.
你观察到记忆在1997年和以前是一种有价值的商品是真的.人们会认为这会导致使用最有效的编码技术和可用语言来最大化其使用.但是,还有其他因素:应用程序积压的机会成本通常被认为超过了引入更多内存/ CPU以处理不太理想的代码(可能会更快地加速)的成本.摩尔定律导致硬件成本不断下降而软件开发成本保持不变的观察进一步强化了这种思路."合乎逻辑"的结论是制定出不是最优的代码,受到一段时间的影响,然后在未来几年中获益(IMO,这是一个糟糕的计划和贪婪的教训,今天仍然很常见).
在70年代到90年代推动应用程序的推动导致了大量代码生成器的兴起(今天我看到各种风格的框架都在履行这一职责).其中许多代码生成器都发出了大量的COBOL代码.为什么要发出COBOL代码？为什么不发出汇编程序或p代码或更高效的东西？我相信答案是风险缓解.大多数代码生成器都是由某些第三方拥有的专有软件,这些第三方可能会或可能不会在10年后开展业务或支持其产品.如果你不能提供一个铁壳保证,生成的应用程序可以在遥远的未来得到支持,这是一个非常难的销售.解决方案是让"发电机"产生熟悉的东西 - 例如COBOL!即使"发电机"死了,最终的应用程序可由您现有的COBOL程序员工维护.问题解决了;)(今天我们将开源视为风险缓解论证).
回到LOC问题.在我看来,计算COBOL代码的行是容易出错或者至少是误解.以下是我工作的应用程序的一些统计数据(大约引用).这个应用程序是使用Basset Frame Technology(框架工作)构建的,因此我们实际上并没有编写COBOL,而是从中生成COBOL.
如您所见,几乎一半的COBOL程序都是非程序分部代码(数据声明等).LOC与动词的比率(语句计数)约为7:2.使用我们的框架可以将代码生成利用大约7:1的比例.那么你应该怎么做呢？我真的不知道 - 除了有很多空间来填补COBOL线数.
我过去曾与其他COBOL程序生成器合作过.其中一些具有绝对愚蠢的通货膨胀因素(例如前面提到的200线到15K线的起毛).考虑到Gartner使用的所有这些通货膨胀因素和计数方法,1997年很可能"淹没"高达2000亿行的COBOL - 但问题仍然存在:这个数字的实际用途是什么？它究竟意味着什么？我不知道.现在让我们回到计数天使的问题!