Cobol: наука и вымысел

Существует несколько тем о релевантности языка программирования Cobol на этом форуме, например. этот поток ссылается на их коллекцию. Меня интересует часто повторяющееся выражение, основанное на исследовании Gartner от 1997 года: в то время в активном использовании было использовано около 200 миллиардов строк кода.

Я хотел бы задать несколько вопросов для проверки или фальсификации нескольких связанных моментов. Моя цель состоит в том, чтобы понять, имеет ли это утверждение к нему какую-либо правду или если это совершенно нереально.

Я заранее извиняюсь за то, что я немного подробно излагаю свою мысль и мое собственное мнение о том, о чем я не уверен, но я думаю, что это могло бы помочь поместить вещи в контекст и таким образом подчеркнуть любые неправильные предположения и выводы Я сделал.

Иногда число "200 миллиардов строк" сопровождается добавленным утверждением, что это соответствовало 80% всего кода программирования на любом используемом языке. В других случаях 80% просто относятся к так называемому "бизнес-коду" (или к какой-то другой неопределенной фразе, намекающей, что читатель не должен подсчитывать основное программное обеспечение, встроенные системы или что-то еще, где Cobol практически не существует). В следующем случае я предполагаю, что код не включает двойной подсчет нескольких установок одного и того же программного обеспечения (так как это обман!).

В частности, за время, предшествующее задаче y2k, было отмечено, что много кода Cobol уже составляет от 20 до 30 лет. Это означало бы, что это было написано в конце 60-х и 70-х годов. В то время лидером рынка был IBM с мэйнфреймом IBM/370. IBM опубликовала историческое объявление на своем веб-сайте, где указаны цены, конфигурация и доступность. Согласно листу, цены составляют около миллиона долларов за машины с объемом памяти до половины мегабайта.

Вопрос 1: Сколько мейнфреймов действительно продано?

Я не нашел никаких чисел за эти времена; последние номера относятся к 2000 году, снова Gartner.: ^ (

Я бы предположил, что фактическое число находится в сотнях или низших тысячах; если в 2000 году размер рынка составлял 50 млрд., а рынок вырос по экспоненте, как и любая другая технология, это могло быть всего лишь несколько миллиардов назад в 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: Сколько программистов нам нужно было написать 200 миллиардов строк кода?

Я действительно не уверен в этом, но если мы возьмем в среднем 10 л.о. в день нам понадобится 55 миллионов человеко-лет, чтобы достичь этого! В сроки от 20 до 30 лет это означало бы, что должно существовать от двух до трех миллионов программистов, постоянно занимающихся написанием, тестированием, отладкой и документированием кода. Это будет примерно столько же программистов, сколько у нас в Китае сегодня, не так ли?

EDIT:Несколько человек подняли автоматические системы шаблонов/генераторы кода или так далее. Может ли кто-нибудь это уточнить? У меня есть две проблемы: a) мне нужно сообщить системе, что она должна делать для меня; для этого мне нужно связаться с компьютером, и компьютер выведет код. Это именно то, что делает компилятор языка программирования. Поэтому по существу я использую другой язык программирования высокого уровня для генерации кода Cobol. Должен ли я работать с другим языком высокого уровня вместо Cobol? Почему средний человек? б) В 70-е и 80-е годы самым ценным товаром была память. Поэтому, если у меня есть язык программирования, выведите что-то, лучше лучше. Используя мой гипотетический метаязык, я бы действительно создал многословный и повторяющийся код Cobol с ним, а не bytecode/p-code, как это делали другие компиляторы того времени? КОНЕЦ РЕДАКТИРОВАНИЯ

Вопрос 5: Как насчет конкурса?

До сих пор я придумал две вещи:

1) У IBM был собственный язык программирования, PL/I. Выше я предполагал, что большая часть кода написана исключительно с использованием Cobol. Тем не менее, при прочих равных условиях мне интересно, действительно ли маркетинг IBM действительно вытолкнул свое собственное развитие с рынка в пользу Cobol на своих машинах. Разве действительно не существует соответствующей кодовой базы PL/I?

2) Иногда (также на этой доске в приведенной выше теме) я сталкиваюсь с утверждением, что "200-миллиардные строки кода" просто невидимы для кого-либо за пределами "правительств, банков..." (и еще чего), Фактически, Министерство обороны финансировало свой собственный язык, чтобы повысить эффективность затрат и сократить распространение языка программирования. Это приводит к их использованию Ады. Будут ли они действительно беспокоиться о том, чтобы иметь так много разных языков программирования, если они использовали преимущественно Cobol? Если бы какой-либо язык работал на "правительственных и военных" системах за пределами восприятия основных вычислений, разве этот язык не был бы Адой?

Я надеюсь, что кто-то может указать на какие-либо изъяны в моих предположениях и/или выводах и пролить свет на то, имеет ли эта претензия истина к ней или нет.

Ответ 1

На поверхности цифры, полученные Gartner, сродни ответу на вопрос: Сколько ангелов может танцевать на голове булавки?. Если вы не получите полную копию своего отчета (стоимость больших долларов), вы никогда не узнаете, как они подошли с или оправданием 200 миллиардов строк заявки COBOL. Сказав это, Gartner - это хорошо уважаемые исследовательские и консультационные поэтому я думаю, что они не сделали бы такое требование без каких-либо оснований или объяснение.

Удивительно, как это исследование цитировалось на протяжении многих лет. Поиск Google для "200 миллиардов строк COBOL" получил меня около 19 500 хитов. Я пробовал кучу их, и большинство из них приписывают номер непосредственно отчету Gartner за 1997 год. Ясно, что эта цифра привлекла внимание многих.

Метод, который вы использовали для "развенчивания" претензии, имеет несколько проблем:

1) Сколько мейнфреймов было продано Это большой вопрос сам по себе, возможно, такой же сложный как ответ на 200 миллиардов строк кодового вопроса. Но что более важно, я не вижу, как определить количество мейнфреймы могут использоваться для ограничения количества строк кода, запущенных на них.

2) Насколько велики программы в строках кода? Программы COBOL имеют тенденцию быть большими. Скромная программа может бежать до нескольких тысяч строк, большой на десятки тысяч. Один из шуток программистов COBOL часто делают, что только одна программа COBOL когда-либо была написана, остальные просто изменены его копии. Как и во многих анекдотах, в нем есть доля правды. В большинстве магазинов есть большой инвентарь программы и многие из этих программ были созданы путем резки и вставки друг от друга. Это действительно "пушит" размер вашей базы кода.

Ваше предположение о том, что программа должна вписываться в физическую память для запуска, неверна. Проблема размера была решена несколькими различными способами (например, программными оверлеями, виртуальной памятью и т.д.). Это было необычно в 60 и 70 для запуска больших программ на машинах с малыми физическими памятью.

3) Не было ли стандартного программного обеспечения? Много COBOL написано с нуля или от шаблонов. Ряд финансовых пакетов был разработан программными домами 70 и 80-х годов. Большинство из них были распространены как библиотеки исходного кода. Затем клиент скопировал и соответствуют их конкретному бизнесу требование. Более "распухание" базы кода - особенно учитывая, что большие сегменты этого кода была логически неисполнена после того, как пакет был "настроен".

4) Сколько программистов нам нужно было написать 200 миллиардов строк кода Не так много, как вы думаете! Учитывая, что COBOL имеет тенденцию быть многословным и сильно тиражируется, программист может иметь огромную "производительность". В 70-х и начале 80-х годов были разработаны системы создания программ. Я когда-то работал с продуктом (теперь, к счастью, не работает), который позволяет мне писать "бизнес-логику", и это генерирует весь код "котельной пластины" вокруг него - создает полностью функциональную программу COBOL. Код он был создан, чтобы быть вежливым, подробным в крайнем случае. Я мог бы создать программу COBOL на 15 тыс. Строк из около 200 строк ввода! Мы принимаем здесь серьезный пух!

5) Что относительно конкуренции? COBOL никогда не испытывала серьезной конкуренции в финансового и страхового секторов. PL/1 была основной инициативой IBM по выпуску одного языка программирования которые отвечали всем возможным вычислительным потребностям. Как и все подобные инициативы, это было слишком амбициозно и в значительной степени рухнул внутрь. Я считаю, что IBM все еще использует и поддерживает его сегодня. В 70-е годы было предсказано, что несколько других языков заменит COBOL - ALGOL, ADA и C, но нет есть. Сегодня я слышу то же самое о Java и .Net. Я думаю, что главная причина, по которой COBOL по-прежнему с нами заключается в том, что она делает то, что он должен делать очень хорошо и огромные многомиллиардные линии наследия кода делают переход на "лучший" язык как дорогостоящим, так и рискованно с точки зрения бизнеса.

Я верю 200-миллиардные строки кодовой истории? Я считаю, что число высокое, но не невероятно высокое количество способов, с помощью которых код COBOL имеет тенденцию "пушиться" со временем.

Я также считаю, что слишком активно анализировать эти цифры быстро ухудшается упражнение "подсчет ангелов" - что-то, что люди могут действительно получить, но не имеет значение в реальном мире.

ИЗМЕНИТЬ

Позвольте мне затронуть несколько комментариев, оставшихся ниже...

Никогда не видел программу COBOL, используемую инвестиционным банком. Вполне возможно. Зависит в каких областях применения вы работали. Инвестиционные банки, как правило, имеют больших вычислительных инфраструктур и использует широкий спектр технологий. Магазин Я работал в за последние 20 лет (хотя и не инвестиционный банк) является одним из крупнейших в стране, и она имеет значительный Инвестиции COBOL. Он также имеет значительные инвестиции на Java, C и С++, поскольку а также карманы практически любой другой технологии известный человеку. Я также встретился с некоторыми довольно старшими разработчиками приложений здесь, что полностью не осознавали, что COBOL все еще используется. Я сделал приблизительный подсчет линии через нашу систему управления исходным кодом и нашел около 70 миллионов строк производство COBOL. Довольно много людей, которые работали здесь годами, совершенно не обращают на это внимания!

Я также знаю, что COBOL быстро уменьшается как язык выбора, но факт есть, все еще много этого вокруг сегодня. В 1997 году, период, на который этот вопрос я считаю, что COBOL был бы доминирующим языком с точки зрения LOC. точка вопроса: может ли в 1997 году быть 200 миллиардов строк?

Подсчет мейнфреймов. Даже если бы можно было получить количество мэйнфреймов, это трудно оценить "вычислительную" мощность, которую они представляли. Мейнфреймы, как и большинство другие компьютеры, входят в широкий спектр конфигураций и вычислительной мощности. Если бы мы могли сказать, что в 1997 году использовались только мэйнфреймы X, вам все равно нужно оценить объем обработки, который они представляли, тогда вам нужно выяснить, что процент рабочей нагрузки был связан с запуском программ COBOL и рядом других смешанные факторы. Я просто не понимаю, как эта линия рассуждений будет когда-либо дать ответ с допустимым пределом погрешности.

Многосчисляющие строки кода. Это была моя точка зрения, когда ссылаясь на коэффициент COBOL "пух". Линии подсчета COBOL могут быть очень вводящей в заблуждение статистикой просто потому, что значительная его часть никогда не была написана программистами в первое место. Или, если это было, совсем немного было сделано, используя вырезку-вставку "шаблон проектирования".

Ваше наблюдение, что память была ценным товаром в 1997 году и ранее, верна. Можно было бы подумать, что это привело бы к использованию наиболее эффективных методов кодирования и языков доступный для максимального использования. Однако существуют и другие факторы: альтернативные издержки на получение заявки частое отставание часто воспринималось, чтобы перевесить затраты на привлечение большего объема памяти/процессора, чтобы иметь дело с меньшим оптимальный код (который можно было бы выкрутить довольно быстро). Это мышление было еще наблюдение, что закон Мура ведет снижая затраты на оборудование, тогда как затраты на разработку программного обеспечения остаются неизменными. "Логический" вывод должен был выкачать менее оптимальный код, немного пожить, а затем воспользоваться преимуществами в ближайшие годы (ИМО, урок плохого планирования и жадности, все еще распространенный сегодня).

Толчок для доставки приложений в течение 70 - 90 лет привел к появлению множества генераторы кода (сегодня я вижу рамки различных вкусов, выполняющих эту роль). Многие из этих генераторов кода излучали тонны кода COBOL. Зачем испускать код COBOL? Почему бы не испустить ассемблер или p-код или что-то гораздо более эффективное? Я считаю, что ответ одна из мер по снижению риска. Большинство генераторов кода являются собственными частями программного обеспечения, принадлежащими некоторым третье лицо, которое может или не может заниматься бизнесом или поддерживать свой продукт через 10 лет. Это очень сложно продать, если вы не можете обеспечить гарантированную железом гарантию того, что сгенерированное приложение может быть поддерживается в отдаленном будущем. Решение состоит в том, чтобы "генератор" что-то произвел знакомый - COBOL например! Даже если "генератор" умирает, полученное приложение может поддерживаются вашим существующим персоналом программистов COBOL. Проблема решена;) (сегодня мы видим открытый источник, используемый в качестве аргумента по снижению риска).

Возврат к вопросу LOC. Подсчет строк кода COBOL, на мой взгляд, открыт для широкий предел ошибки или, по крайней мере, неправильное толкование. Вот несколько статистических данных из приложения Я работаю (цитируется примерно). Эта приложение было построено и поддерживается с использованием технологии Basset Frame (рамочная), поэтому мы на самом деле не пишем COBOL, но мы генерируем COBOL из него.

Линии COBOL: 7 000 000
- Непроцедурный отдел: 3 000 000
- Отдел процедур: 3,500,000
- Комментарий/пробел: 500 000
- Нераспределенные директивы COPY: 40 000
Глаголы COBOL: 2 000 000
Программист, написавший процедуру. Отдел: 900 000.
Сгенерирован фрейм приложения: 270 000
Создан корпоративный инфраструктурный фрейм: 2,330,000

Как вы можете видеть, почти половина наших программ COBOL - это непроцедурный код отдела (декларация данных и тому подобное). Отношение LOC к глаголам (количество отсчетов) составляет около 7: 2. Использование нашей структуры увеличивает производство кода примерно в 7: 1. Итак, что вы должны сделать из всего этого? Я действительно не знаю - кроме того, что есть много места для распушите количество линий COBOL.

Я работал с другими генераторами программ COBOL в прошлом. Некоторые из них были абсолютно глупые факторы инфляции (например, упоминавшиеся ранее 200 строк на 15K линии пуха). Учитывая все эти инфляционных факторов и методологии подсчета, используемой Gartner, вполне может быть было возможно "пухнуть" до 200 миллиардов линий COBOL в 1997 году, но вопрос остается: Какое реальное использование - это число? Что может означать действительно? Понятия не имею. Теперь вернемся к проблеме счетных ангелов!

Ответ 2

Я бы никогда не защитил этих клоунов в Gartner, но все же:

Ваши идеи о IBM/370 неверны. 370 - это архитектура, а не конкретная машина - она была реализована на всем, от монстров с водяным охлаждением до маленькой мини-компьютерной машины (такого же размера, как VAX). Таким образом, количество проданных было, вероятно, намного больше, по порядку, чем вы подозреваете.

Кроме того, COBOL был сильно использован в линейке DEC VAX, а до этого на линиях DEC-10 и DEC-20. В Великобритании он использовался на всех мейнфреймах ICL. Многие другие платформы также поддерживали его.

Ответ 3

[Обычный отказ от ответственности - я работаю для поставщика COBOL]

Это интересный вопрос, и всегда сложно получить доказуемое число. По числу оценок программистов COBOL - количество 2 - 3 миллионов может не быть порядком по ошибке. Я думаю, что в прошлом были оценки 1 или 2 миллиона. И каждый из них может генерировать много кода в 20-летней карьере. В Индии десятки тысяч новых программистов COBOL добавляются в пул каждый год (возможно, каждый месяц!).

Я думаю, что автоматически сгенерированный код, вероятно, больше, чем можно было бы подумать. Например, PACBASE - очень популярное приложение в банковской отрасли. Очень большой глобальный банк, который я знаю, широко использует его, и они генерируют весь свой код в COBOL и оценивают, что этот сгенерированный код составляет 95% от общей кодовой базы, а остальные 5% - вручную. Я не думаю, что это необычно. Техническое обслуживание и развитие этих систем обычно выполняется на уровне модели, а не сгенерированный код, как вы говорите.

Существует группа приложений, которые отсутствовали в исходном вопросе - COBOL - это не только язык мэйнфреймов. Первые годы работы Micro Focus почти полностью проводились на рынке OEM - у нас было что-то вроде 200 разных OEM-производителей (много давно названных имен, таких как DEC, Stratus, Bull,...). Каждый OEM должен был иметь компилятор COBOL на своем поле рядом с C и Assembler. В то время было создано множество крупных приложений и по-прежнему сильны - подумайте о крупнейших системах управления персоналом, крупнейших системах биллинга мобильных телефонов и т.д. Я хочу сказать, что существует много кода COBOL, который никогда не был на мэйнфрейме IBM и часто упускается из виду.

И, наконец, размер базы кода может быть больше в магазинах COBOL, чем "средний". Это не только потому, что COBOL является многословным (или был - это не так давно), но системы просто больше - они находятся в крупных организациях, выполняя большое количество разрозненных задач. Очень часто для сайтов есть 10 миллионов LoC.

Ответ 4

У меня нет цифр, но моя первая "настоящая" работа была на IBM 370.

Сначала: номер продан. В 1974 году большая железная дорога шла на три 370-х годов. Это были большие 370, однако, и вы могли бы получить небольшую сумму намного меньше. (Для перспективы, в то время, было ли получение другого мегабайта, было решение на уровне VP.)

Во-вторых: код COBOL - это то, что вы можете назвать "пушистым", поскольку типичное предложение (COBOLese для строки) может быть "ДОБАВИТЬ 1 К ГЛАВНОМУ СЧЕТУ ЗАКАЗЧИКА". Было бы относительно немного машинных инструкций в каждой строке. (Это особенно верно для IBM 360 и далее, в которых были машинные инструкции, разработанные для выполнения COBOL.) Кстати, адреса были 16 бит, четыре - для обозначения регистра (используя нижние 24 бита в качестве базового адреса) и 12 в качестве смещения, Это означало, что что-то под 64 КБ могло быть рассмотрено одновременно, поскольку не все из 16 регистров могут использоваться в качестве базовых регистров по разным причинам. Не стоит недооценивать способность людей поместить программы в небольшую память.

Кроме того, не стоит недооценивать количество программ. Библиотека программ была бы на диске и на магнитной ленте и по существу ограничивалась только затратами и объемом. (Раньше они были на перфокартах, у которых были серьезные проблемы с хранением данных и программ.)

В-третьих: Да, большинство программ было написано для бизнеса в то время. Машины были намного дороже, и люди были дешевле. Были написаны программы для автоматизации существующих бизнес-процессов, и идея, что вы могли получить внешнее программное обеспечение и изменить свою деловую практику, была почти ересью. Конечно, это изменилось со временем.

В-четвертых: программисты могли идти гораздо быстрее, чем сегодня, в строках кода на человеко-год, поскольку это были в значительной степени большие немые программы для больших немых проблем. По моему опыту, DATA DIVISION был большой частью каждой программы COBOL, и это часто принимало большие описания макетов файлов и повторяло их в каждой программе из серии.

У меня ограниченный опыт работы с генераторами программ, но в то время было очень часто использовать его для создания приложения, а затем для изменения вывода. Это было отчасти просто плохой практикой, а отчасти потому, что генератор программ не мог делать все, что нужно.

В-пятых: PL/I не использовалась, несмотря на усилия IBM. Он натолкнулся на раннюю плохую печать, хотя, насколько мне известно, единственная серьезная проблема, которая не могла быть исправлена, заключалась в выяснении системы точности. Департамент обороны использовал Ada и COBOL для совершенно разных вещей. Вы опускаете язык ассемблера в качестве конкурента, а множество небольших магазинов используют BAL (также называемый ASM) вместо COBOL. В конце концов, программисты были дешевы, компиляторы были дорогими, и было много вещей, которые COBOL не мог сделать. Это был очень хороший ассемблерный язык, и мне это очень понравилось.

Ответ 5

Хорошо, вы спрашиваете здесь не то место. В этом форуме доминируют программисты .net, со значительным меньшинством java и таким возрастом, что только очень маленькое меньшинство имеет опыт работы с коболом.

Рынок инструментов CASE состоял из значительной части генераторов кобольных кодов. Большинство инструментов были только для записи, а не для двухсторонних. Это гарантирует, что существует много строк кода. Этот рынок был несколько новее, чем 70-е годы, поэтому объем кобольского кода быстро вырос в 80-х и 90-х годах.

Многие разработки кобола выполняются людьми, не имеющими значительного доступа в Интернет и, следовательно, видимость. В этом нет необходимости. Проболомеры Cobol используются для проведения внутренних курсов программирования и бумажной документации (много из них).

[edit] Создание источника коболов сделало большой смысл. Cobol очень многословный и низкий. Различные реализации коболов все немного разные, поэтому настройка генератора кода устраняет множество потенциальных ошибок.

Ответ 6

Что касается №4: сколько из этого могло быть машинным кодом? Я не знаю, был ли код на основе шаблонов много использован с Cobol, но я вижу, что он много используется для всех видов вещей. Если мое приложение имеет тысячи LOC, которые были сгенерированы машиной, это не означает многого. Последний код генерирующий script, который я написал, занял 20 минут, чтобы написать, 10 минут для форматирования ввода, 2 минуты для запуска, а затем час, чтобы выполнить набор автоматических тестов, чтобы проверить, действительно ли он работал, но код, который он сгенерировал, взяли несколько дней, чтобы сделать вручную (или время между утренней встречей и обедом, сделайте это по-моему;)). Хорошо, я признаю, что это не всегда так просто и часто используется ручная настройка, но я до сих пор не думаю, что метка LOC имеет большое значение, если генераторы кода сильно используются.

Возможно, это так, как они генерировали столько кода за столь короткое время.