14

在这个论坛上有一些关于 Cobol 编程语言相关性的主题,例如这个主题链接到它们的集合。我在这里感兴趣的是根据 Gartner 从 1997 年的一项研究得出的一个经常重复的声明:当时有大约 2000 亿行代码在活跃使用中

我想问一些问题来验证或伪造几个相关点。我的目标是了解这个陈述是否有任何真实性,或者它是否完全不现实。

我提前道歉,因为我在表达我的思路和我对我不确定的事情的看法时有点冗长,但我认为这可能有助于将事情放在上下文中,从而突出我所做的任何错误假设和结论.


有时,“2000 亿行”这个数字伴随着一个额外的声明,即这对应于任何正在使用的任何语言的所有编程代码的 80%。其他时候,80% 只是指所谓的“业务代码”(或其他一些模糊的短语,暗示读者不要指望主流软件、嵌入式系统或其他任何 Cobol 实际上不存在的东西)。在下文中,我假设代码不包括重复计算同一软件的多次安装(因为那是作弊!)。

特别是在 y2k 问题之前的时间里,已经注意到很多 Cobol 代码已经有 20 到 30 年的历史了。这意味着它是在 60 年代和 70 年代后期编写的。当时,市场领导者是 IBM 的IBM/370 大型机。IBM 在其网站上发布了历史公告,引用了价格、配置和可用性。根据该表,内存高达 0.5 兆字节的机器的价格约为 100 万美元。

问题一:实际销售了多少台主机?

我没有找到那些时间的任何数字;最新的数字是 2000 年的数据,同样由 Gartner 提供。:^(

我猜实际数字是几百或几千;如果 2000 年市场规模是 500 亿,并且市场像任何其他技术一样呈指数级增长,那么在 1970 年可能只有几十亿。自从 IBM/370 销售了 20 年以来,将导致 20 倍于几千在几万台机器中(这是相当乐观的)!

问题 2:程序的代码行数有多大?

我不知道该架构上的一行源代码会产生多少字节的机器代码。但是由于 IBM/370 是 32 位机器,任何地址访问都必须使用 4 个字节加上指令(2,也许是 3 个字节?)。如果算上操作系统和程序的数据,多少行代码可以放入半兆字节的主内存中?

问题3:没有标准软件吗?

售出的每一台机器是否都运行一个独特的手动编码系统,没有任何标准软件?说真的,即使每台机器都是从头开始编程而没有重用遗留代码(等等……这不是违反我们从一开始就提出的主张之一吗???)我们可能有 O(50,000 loc/machine) * O(20,000 台机器) = O(1,000,000,000 loc)。

那离2000亿还有很远很远!我在这里遗漏了一些明显的东西吗?

问题 4:写 2000 亿行代码需要多少程序员?

我真的不确定这一点,但如果我们平均每天使用 10 个 loc,我们将需要 5500 万人年才能实现这一目标!在 20 到 30 年的时间范围内,这意味着肯定有 2 到 300 万程序员不断地编写、测试、调试和记录代码。那将和我们今天在中国的程序员一样多,不是吗?

编辑:有几个人提出了自动模板系统/代码生成器左右。有人可以详细说明一下吗?我有两个问题:a)我需要告诉系统它应该为我做什么;为此,我需要与计算机通信,计算机将输出代码。这正是编程语言的编译器所做的。所以本质上我正在使用一种不同的高级编程语言来生成我的 Cobol 代码。我不应该使用其他高级语言而不是 Cobol 吗?为什么是中间人?b) 在 70 和 80 年代,最珍贵的商品是记忆。所以如果我有一个编程语言输出一些东西,它应该是简洁的。编辑结束

问题5:比赛怎么样?

到目前为止,我在这里提出了两件事:

1) IBM 有自己的编程语言PL/I。上面我假设大部分代码都是专门使用 Cobol 编写的。然而,在所有其他条件相同的情况下,我想知道 IBM 营销部门是否真的将他们自己的开发推离了市场,转而在他们的机器上使用 Cobol。PL/I 真的没有相关的代码库吗?

2)有时(也在上面引用的线程中的这个板上)我遇到这样的说法,即“2000 亿行代码”对于“政府、银行......”(等等)之外的任何人都是不可见的。实际上,国防部已经资助了他们自己的语言,以提高成本效益并减少编程语言的扩散。这导致他们使用 Ada。如果他们主要使用 Cobol,他们真的会担心拥有这么多不同的编程语言吗?如果在主流计算认知之外的“政府和军事”系统上运行任何语言,那该语言不就是 Ada 吗?

我希望有人能指出我的假设和/或结论中的任何缺陷,并阐明上述说法是否属实。

4

6 回答 6

7

从表面上看,Gartner 产生的数字类似于回答这个问题:有多少天使可以在针头上跳舞?. 除非您获得他们报告的完整副本(花费巨资),否则您永远不会知道他们是如何提出或证明 2000 亿行 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 的行数可能是一个非常具有误导性的统计数据,因为其中很大一部分从一开始就不是程序员编写的。或者,如果是这样,其中相当一部分是使用剪切粘贴修补程序“设计模式”完成的。

您认为记忆在 1997 年及之前是一种有价值的商品的观察是正确的。人们会认为这将导致使用最有效的编码技术和语言来最大限度地利用它。然而,还有其他因素: 拥有应用程序积压的机会成本通常被认为超过了引入更多内存/cpu 以处理非最佳代码的成本(这可能会更快一些)。摩尔定律导致硬件成本不断下降而软件开发成本保持不变的观察进一步强化了这种想法。“合乎逻辑”的结论是编写不是最优的代码,受苦一段时间,然后在未来几年获得收益(IMO,糟糕的计划和贪婪的教训,今天仍然很常见)。

70 年代到 90 年代交付应用程序的推动导致了大量代码生成器的兴起(今天我看到各种风格的框架都在扮演这个角色)。其中许多代码生成器发出了大量的 COBOL 代码。为什么要发出 COBOL 代码?为什么不发出汇编程序或 p 代码或更有效的东西?我相信答案是降低风险之一。大多数代码生成器是某些第三方拥有的专有软件,这些第三方可能会或可能不会在 10 年后开展业务或支持他们的产品。如果您不能提供一个铁定的保证,即生成的应用程序可以在遥远的将来得到支持,那么这是一个非常难卖的东西。解决方案是让“生成器”产生一些熟悉的东西——例如 COBOL!即使“发电机”死了,生成的应用程序可以由您现有的 COBOL 程序员人员维护。问题解决了;)(今天我们看到开源被用作降低风险的论据)。

回到 LOC 问题。在我看来,计算 COBOL 代码的行数会产生很大的误差,或者至少会产生误解。以下是我处理的应用程序的一些统计数据(大约引用)。这个应用程序是使用 Basset 框架技术(框架)构建和维护的,因此我们实际上并不编写 COBOL,而是从中生成 COBOL。

  • COBOL 行数:7,000,000
    • 无程序处:3,000,000
    • 程序科:3,500,000
    • 评论/空白:500,000
    • 非扩展 COPY 指令:40,000
  • COBOL 动词:2,000,000
  • 程序员写程序师:90万
  • 生成的应用程序框架:270,000
  • 生成的企业基础架构框架:2,330,000

如您所见,我们的COBOL程序几乎有一半是非过程划分代码(数据声明等)。LOC 与动词(语句计数)的比例约为 7:2。使用我们的框架以大约 7:1 的比例利用代码生成。那么你应该如何看待这一切呢?我真的不知道 - 除了有很多空间可以弄乱 COBOL 行数。

我过去曾与其他 COBOL 程序生成器合作过。其中一些具有绝对愚蠢的通货膨胀因素(例如前面提到的 200 行到 15K 行的绒毛)。考虑到所有这些通胀因素和 Gartner 使用的计数方法,很有可能在 1997 年“弄乱”多达 2000 亿行 COBOL - 但问题仍然存在:这个数字有什么实际用途?它的真正含义是什么?我不知道。现在让我们回到计数天使的问题!

于 2010-06-01T21:25:35.853 回答
2

我永远不会为 Gartner 的那些小丑辩护,但仍然:

您对 IBM/370 的看法是错误的。370 是一种架构,而不是特定的机器——它被实施在从水冷怪物到小型微型计算机大小的机器(与 VAX 大小相同)的所有设备上。因此,销售的数量可能比您想象的要大得多,数量级。

此外,COBOL 大量用于 DEC 的 VAX 产品线,在此之前用于 DEC-10 和 DEC-20 产品线。在英国,它被用于所有 ICL 大型机。许多其他平台也支持它。

于 2010-06-01T18:53:15.407 回答
2

[通常的免责声明 - 我为 COBOL 供应商工作]

这是一个有趣的问题,而且总是很难得到一个可证明的数字。关于 COBOL 程序员的估计数量——2 到 300 万这个数字可能不会出现数量级的错误。我认为过去估计有 1 或 200 万。在 20 年的职业生涯中,每一个都可以生成大量代码。在印度,每年(也许每个月!)都会有数以万计的新 COBOL 程序员加入到池中。

我认为自动生成的代码可能比想象的要大。例如,PACBASE 是银行业中非常流行的应用程序。我知道一家非常大的全球银行广泛使用它,他们将所有代码生成到 COBOL 中,并估计这个生成的代码占其总代码库的 95%,另外 5% 是手工编码/维护的。我认为这并不罕见。这些系统的维护和开发通常在模型级别完成,而不是您所说的生成代码。

原始问题中缺少一组应用程序 - COBOL 不仅仅是一种大型机语言。Micro Focus 的早期几乎完全是在 OEM 市场上度过的——我们曾经有大约 200 家不同的 OEM(很多早已不复存在的名字,如 DEC、Stratus、Bull ......)。每个 OEM 都必须在他们的机器上安装一个 COBOL 编译器以及 C 和汇编程序。当时构建了许多大型应用程序,并且仍在发展壮大——想想最大的 HR ERP 系统、最大的手机计费系统等。我的观点是,有很多 COBOL 代码从未出现在 IBM 大型机上并且经常被忽视。

最后,COBOL 商店中代码库的大小可能比“平均”大。这不仅仅是因为 COBOL 很冗长(或者曾经是——很长一段时间都不是这样),而是因为系统更大——它们位于大型组织中,执行大量不同的任务。站点拥有数以百万计的 LoC 是很常见的。

于 2010-06-02T13:57:37.970 回答
2

我没有数据,但我的第一份“真正”工作是在 IBM 370 上。

第一:销售数量。1974 年,一条大型铁路在三个 370 上运行。不过,这些都是大的 370,你可以花更少的钱买到一个小的。(从角度来看,当时是否获得另一个兆字节是 VP 级别的决定。)

第二:COBOL 代码就是您可能所说的“蓬松”,因为典型的句子(COBOLese 表示行)可能是“向客户的主帐户添加 1”。每行的机器指令相对较少。(在 IBM 360 及更高版本上尤其如此,它设计了围绕执行 COBOL 的机器指令。)顺便说一句,地址是 16 位,四个用于指定寄存器(使用底部 24 位作为基地址)和 12 作为偏移量. 这意味着一次可以处理 64K 以下的内容,因为由于各种原因,并非所有 16 个寄存器都可以用作基址寄存器。不要低估人们将程序装入小内存的能力。

另外,不要低估程序的数量。程序库将位于磁盘和磁带上,基本上只受成本和容量的限制。(早些时候,他们会在打孔卡上,因为数据和程序存储存在严重问题。)

第三:是的,当时大多数软件都是为企业手写的。那时机器贵得多,人也便宜。编写程序是为了使现有业务流程自动化,而您可以使用外部软件并改变您的业务实践的想法几乎是异端邪说。当然,这随着时间而改变。

第四:程序员可以比现在快得多,以每人每年的代码行数计算,因为这些主要是针对大笨问题的笨拙程序。根据我的经验,它DATA DIVISION是每个 COBOL 程序的很大一部分,并且经常需要对文件布局进行大量描述,并在系列中的每个程序中重复它们。

我对程序生成器的经验有限,但当时使用它来生成应用程序然后修改输出是很常见的。这部分只是不好的做法,部分是因为程序生成器无法完成所需的一切。

第五:尽管 IBM 做出了努力,PL/I 并没有被大量使用。它遇到了早期的坏消息,尽管据我所知,唯一无法解决的真正主要问题是弄清楚精确系统。国防部将 Ada 和 COBOL 用于完全不同的事情。您忽略了汇编语言作为竞争对手,许多小商店使用 BAL(也称为 ASM)而不是 COBOL。毕竟,程序员很便宜,编译器很贵,还有很多 COBOL 做不到的事情。它实际上是一种非常好的汇编语言,我非常喜欢它。

于 2010-06-02T17:37:22.940 回答
1

好吧,你在这里问错地方了。这个论坛由 .net 程序员主导,他们有大量的 Java 少数群体,而且年龄如此之大,以至于只有极少数人有任何 cobol 经验。

CASE 工具市场包含很大一部分 cobol 代码生成器。大多数工具都是只写的,而不是双向的。这确保有很多代码行。这个市场比 70 年代要新一些,因此 cobol 代码的数量在 80 年代和 90 年代快速增长。

许多 cobol 开发是由没有大量互联网访问权限的人完成的,因此没有可见性。没有必要。Cobol prorammers 习惯于拥有内部编程课程和纸质文档(很多)。

[编辑] 生成 cobol 源代码很有意义。Cobol 非常冗长和低级。各种 cobol 实现都略有不同,因此配置代码生成器可以消除很多潜在的错误。

于 2010-06-01T18:36:19.933 回答
0

关于#4:其中有多少可能是机器生成的代码?我不知道基于模板的代码是否在 Cobol 中被大量使用,但我看到它现在很多用于各种事情。如果我的应用程序有数千个机器生成的 LOC,那意义不大。我写的最后一个代码生成脚本花了 20 分钟编写,10 分钟格式化输入,2 分钟运行,然后一个小时执行一套自动测试以验证它是否确实有效,但它生成的代码会花费几天手工(或者早上会议和午餐之间的时间,按照我的方式做;))。好的,我承认这并不总是那么容易,并且经常涉及手动调整,但如果代码生成器大量使用,我仍然认为 LOC 指标没有多大意义。

也许这就是他们在这么短的时间内生成这么多代码的原因。

于 2010-06-01T14:06:40.860 回答