Кобол: наука и художественная литература [закрываются]
6 ответов
На первый взгляд, цифры, которые выдает 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 15K line из около 200 строк ввода! Мы берем здесь серьезный пух!
5) А как насчет конкуренции? У COBOL никогда не было серьезной конкуренции в финансовый и страховой секторы. PL/1 была крупной инициативой IBM по созданию единого языка программирования. которые удовлетворяли все возможные вычислительные потребности. Как и все подобные инициативы, она была слишком амбициозной и в значительной степени рухнул внутрь. Я считаю, что IBM по-прежнему использует и поддерживает его сегодня. В 70-е годы несколько других языков должны были прийти на смену COBOL - на ум приходят ALGOL, ADA и C, но ни один из них этого не сделал.Сегодня я слышу то же самое о Java и .Net. Я думаю, что основная причина, по которой COBOL все еще с нами, заключается в том, что он делает то, что он должен делать очень хорошо и огромные многомиллиардные строки кода делают переход на «лучший» язык дорогостоящим и рискованно с точки зрения бизнеса.
Верю ли я в 200 миллиардов строк кода? Я нахожу число высоким, но не невероятно высоким, учитывая количество способов, которыми код COBOL имеет тенденцию «распушить» себя с течением времени.
Я также думаю, что слишком активное участие в анализе этих чисел быстро деградирует в Упражнение «подсчет ангелов» - что-то, что люди могут действительно завести, но не имеют значимость в реальном мире.
EDIT
Позвольте мне обратиться к нескольким комментариям, оставленным ниже...
Никогда не видел программу COBOL, используемую инвестиционным банком. Вполне возможно. Зависит в каких областях применения вы работали. Инвестиционные банки, как правило, имеют большие вычислительные инфраструктуры и использование широкого спектра технологий.Магазин Я работал в за последние 20 лет (хотя и не инвестиционный банк) является одним из крупнейших в страна и она имеет значительный Инвестиции COBOL. Он также имеет значительные инвестиции в Java, C и C ++ как а также карманы практически любой другой технологии известен человеку. Я также встречал здесь некоторых довольно высокопоставленных разработчиков приложений, которые совершенно не знали, что COBOL все еще используется. Я сделал приблизительный подсчет линий через нашу систему управления версиями и обнаружил около 70 миллионов строк производство КОБОЛ. Довольно много людей, которые работали здесь в течение многих лет, совершенно не обращают на это внимания!
Я также знаю, что COBOL быстро сокращается как язык выбора, но факт есть, его все еще много вокруг сегодня. В 1997 году период, к которому этот вопрос Я считаю, что COBOL был бы доминирующим языком с точки зрения LOC. Тем Вопрос в том, могло ли быть 200 миллиардов строк в 1997 году?
Подсчет мэйнфреймов.Даже если бы кто-то смог получить количество мэйнфреймов, он бы это трудно оценить «вычислительную» мощность, которую они представляли. Мэйнфреймы, как и большинство другие компьютеры, поставляются в широком диапазоне конфигураций и вычислительной мощности. Если бы мы могли сказать, что в 1997 году использовались именно мэйнфреймы «X», вам все равно нужно оцените вычислительную мощность, которую они представляли, затем нужно выяснить, что процент рабочей нагрузки был обусловлен запуском программ COBOL и кучи других смешанные факторы. Я просто не вижу, как эта линия рассуждений когда-либо будет дать ответ с приемлемой погрешностью.
Многосчет строк кода. Это была именно моя точка зрения, когда ссылаясь на фактор «пуха» COBOL. Подсчет строк COBOL может быть очень вводящей в заблуждение статистикой просто потому, что значительное его количество никогда не было написано программистами в первенство. Или, если это было так, довольно много этого было сделано с использованием вырезания-вставки-мастера. "шаблон проектирования".
Ваше наблюдение о том, что память была ценным товаром в 1997 году и ранее, верно. Можно было бы подумать, что Это привело бы к использованию наиболее эффективных методов и языков кодирования доступны для максимального его использования. Однако есть и другие факторы: альтернативные издержки наличия приложения Часто считалось, что отставание перевешивает стоимость привлечения большего объема памяти / процессора для решения проблем, превышающих оптимальный код (который можно было бы проверять немного быстрее). Это мышление было дополнительно усилено Наблюдение, что закон Мура приводит к тому, что снижение затрат на аппаратное обеспечение, в то время как затраты на разработку программного обеспечения остаются постоянными. «Логический» вывод было провернуть менее оптимальный код, помечиться некоторое время, а затем пожинать плоды в ближайшие годы (ИМО, урок плохого планирования и жадности, все еще распространенный сегодня).
Толчок к доставке приложений в период с 70-х по 90-е годы привел к росту множества генераторы кодов (сегодня я вижу рамки различных вкусов, выполняющих эту роль). Многие из этих генераторов кодов излучали тонны кода COBOL. Зачем выдавать код COBOL? Почему бы не излучать ассемблер или p-код или что-то гораздо более эффективное? Я считаю, что ответ таков: один из средств снижения рисков. Большинство генераторов кода являются проприетарными частями программного обеспечения, принадлежащими некоторым третья сторона, которая может или не может быть в бизнесе или поддерживать свой продукт через 10 лет. Это очень трудно продать, если вы не можете предоставить железную гарантию того, что сгенерированное приложение может быть поддерживается в далеком будущем. Решение состоит в том, чтобы «генератор» производил что-то. знакомый - COBOL например! Даже если «генератор» умирает, полученное применение может поддерживаться вашим существующим штатом программистов COBOL. Проблема решена ;) (сегодня мы видим открытый исходный код, используемый в качестве аргумента снижения риска).
Возвращаясь к вопросу LOC. Счетные строки кода COBOL, на мой взгляд, открыты для широкая погрешность или, по крайней мере, неправильное толкование.Вот несколько статистических данных из приложения Я работаю над (цитирую приблизительно). Этот приложение было построено и поддерживается с использованием технологии Basset Frame (frame-work), поэтому на самом деле мы не пишем 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 году — но вопрос Остается: Какая реальная польза от этого числа? Что это может на самом деле означать? Понятия не имею. Сейчас Давайте вернемся к проблеме счетных ангелов!
Я бы никогда не стал защищать этих клоунов из Gartner, но все же:
Ваши представления о IBM/370 неверны. 370 была архитектурой, а не конкретной машиной - она была реализована на всем, начиная от монстров с водяным охлаждением и заканчивая маленькими миникомпьютерами (такого же размера, как VAX). Таким образом, количество проданных компьютеров, вероятно, было намного больше, на порядки больше, чем вы предполагаете.
Кроме того, COBOL активно использовался в линейке VAX компании DEC, а до этого в линейках DEC-10 и DEC-20. В Великобритании он использовался на всех мэйнфреймах ICL. Многие другие платформы также поддерживали его.
Ну, вы спрашиваете не в том месте. На этом форуме преобладают программисты .net, со значительным меньшинством java и таким возрастным возрастом, что лишь очень небольшое меньшинство имеет какой-либо опыт работы с cobol.
Рынок инструментов CASE по большей части состоял из генераторов кода на коболе. Большинство инструментов было предназначено только для записи, а не двустороннего. Это гарантирует наличие большого количества строк кода. Этот рынок был несколько новее, чем 70-е годы, поэтому объем кода на коболе быстро рос в 80-е и 90-е годы.
Большая часть разработки коболов выполняется людьми, не имеющими значительного доступа к Интернету и, следовательно, не имеющими видимости. В этом нет необходимости. Программисты Cobol привыкли иметь собственные курсы программирования и бумажную документацию (ее много).
[править] Создание источника кобола имело большой смысл. Кобол очень многословный и низкий уровень. Различные реализации cobol немного отличаются, поэтому настройка генератора кода устраняет множество потенциальных ошибок.
У меня нет цифр, но моя первая «настоящая» работа была на IBM 370s.
Первое: Номер продан. В 1974 году по большой железной дороге ходили три 370-х годов. Но это были большие 370-е, и вы могли купить маленькую гораздо дешевле. (Для сравнения, в то время решение о получении еще одного мегабайта принималось на уровне VP.)
Во-вторых: код COBOL - это то, что вы могли бы назвать «пушистым», поскольку типичное предложение (COBOLese for line) могло быть «ДОБАВИТЬ» 1 НА ГЛАВНЫЙ АККАУНТ ЗАКАЗЧИКА ». В каждой строке будет относительно мало машинных инструкций. (Это особенно верно для IBM 360 и более поздних версий, у которых были машинные инструкции, разработанные для выполнения COBOL.) Кстати, адреса были 16-битными, четыре для обозначения регистра (с использованием нижних 24 бита в качестве базового адреса) и 12 в качестве смещения. . Это означало, что одновременно можно было адресовать что-то менее 64 КБ, поскольку не все из 16 регистров по разным причинам можно было использовать в качестве базовых. Не стоит недооценивать способность людей умещать программы в небольшой объем памяти.
Также не стоит недооценивать количество программ. Программная библиотека будет на диске и на магнитной ленте и, по существу, ограничена только стоимостью и объемом. (Раньше они были на перфокартах, у которых были серьезные проблемы с хранением данных и программ.)
В-третьих: Да, в то время большая часть программного обеспечения была написана вручную для бизнеса. Машины тогда были намного дороже, а люди дешевле. Программы были написаны для автоматизации существующих бизнес-процессов, и идея о том, что вы можете получить стороннее программное обеспечение и изменить свои методы ведения бизнеса, была почти ересью. Конечно, со временем это изменилось.
В-четвертых: программисты могли работать намного быстрее, чем сегодня, по количеству строк кода на человека в год, поскольку это были в основном большие тупые программы для больших тупых задач. По моему опыту, ПОДРАЗДЕЛЕНИЕ ДАННЫХ было большой частью каждой программы на COBOL, и это часто требовало больших описаний макетов файлов и повторения их в каждой программе в серии.
У меня ограниченный опыт работы с генераторами программ, но в то время было очень распространено использовать его для создания приложения и последующего изменения вывода. Отчасти это было просто плохой практикой, а отчасти потому, что генератор программ не мог сделать все необходимое.
Пятое: PL / I мало использовался, несмотря на усилия IBM. Вначале он натолкнулся на плохую прессу, хотя, насколько я знаю, единственной серьезной проблемой, которую нельзя было исправить, было выяснение системы точности. Министерство обороны использовало Ada и COBOL для совершенно разных целей. Вы опускаете ассемблер в качестве конкурента, и многие небольшие магазины использовали BAL (также называемый ASM) вместо COBOL. В конце концов, программисты были дешевыми, компиляторы - дорогими, и было много вещей, которые COBOL не мог сделать. На самом деле это был очень хороший ассемблер, и он мне очень нравился.
Что касается #4: сколько из этого могло быть машинного кода? Я не знаю, часто ли в Cobol использовался код на основе шаблонов, но сейчас я вижу много такого кода, используемого для самых разных вещей. Если в моем приложении есть тысячи LOC, которые были сгенерированы машиной, это мало что значит. Последний скрипт для генерации кода, который я написал, занял 20 минут на написание, 10 минут на форматирование ввода, 2 минуты на запуск, затем час на выполнение набора автоматических тестов, чтобы проверить, что он действительно работает, но код, который он сгенерировал, занял бы несколько дней, чтобы сделать вручную (или время между утренней встречей и обедом, если делать это по-моему ;)). Хорошо, я признаю, что это не всегда так просто, и часто приходится работать вручную, но я все равно не думаю, что метрика LOC имеет большое значение, если генераторы кода активно используются.
Может быть, именно поэтому они сгенерировали так много кода за такое короткое время.
[Обычный отказ от ответственности - я работаю на поставщика 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. В то время было создано множество больших приложений, которые продолжают развиваться - подумайте о крупнейших HR-ERP-системах, крупнейших системах биллинга мобильных телефонов и т. Д. Я хочу сказать, что существует много кода COBOL, которого никогда не было на мэйнфреймах IBM. и часто упускается из виду.
И, наконец, размер кодовой базы может быть больше в магазинах COBOL, чем «средний». Это не только потому, что COBOL многословен (или был - давно уже не было), но и системы просто больше - они находятся в крупных организациях и выполняют большое количество разрозненных задач.Очень часто сайты имеют десятки миллионов LoC.