Почему презрение к COBOL? [закрыто]

Когда люди упоминают КОБОЛ, он обычно встречается с фырканьем или стоном. Я не знаю много о COBOL, но я видел несколько программ, написанных на нем. Я вижу, что это многословно, и для непосвященных глаз, таких как мои, неразборчиво. Но не правда ли, все языки программирования не являются бессмысленным для непрофессионала?

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

COBOL был одним из первых языков, которые я выучил - если вы игнорируете бесчисленные версии Basic, три или четыре языка ассемблера и вариант Forth, то это было в моих первых пяти и выучилось одновременно с Pascal. Я отвечаю по личному опыту использования языка.

РЕДАКТИРОВАТЬ Я должен сказать, древний опыт. Я никогда не использовал этот язык после конца 80-х, хотя я купил новую книгу (вместо старой, которую я с отвращением выбросил), чтобы мне было на что сослаться, чтобы мои ужасные истории не были слишком искажены. Но я понятия не имею, как развивался язык по крайней мере за последние 20 лет.

Очевидно, что для многих людей, это просто , что «старый плохо» вид , что jonsca уже описал - а также гораздо более трети рук пасс меня вниз отношения вещь. Но есть реальные проблемы, лежащие в основе этого.

Быть слишком многословным - настоящая проблема - слишком много путаницы в понимании кода. Это, безусловно, самая большая проблема. Люди , которые смотрят на MOVE, ADDи MULTIPLYт.д. заявления в ужасе имеют несколько преувеличенное представление об этом, правда - COMPUTEутверждение ближе к заданиям на других языках. Но во всех этих разделах и секциях все еще много беспорядка. Одна из первых вещей, которые я узнал в COBOL, - это всегда начинать с копирования стандартного SKELETON.COB размером с страницу A4.

COBOL делает некоторые интересные функции, но эти функции (например, PICвещь) , как правило, вещи, которые в настоящее время более частью СУБД , а не язык программирования, и мне кажется, как правило , быть лучше , чтобы отделить эти обязанности. Кроме того, некоторые библиотеки на других языках используют что-то сопоставимое PIC(например, printf и scanf в стандартной библиотеке C). Возможно, лучшее было сохранено, но худшее упало.

Кроме того, для каждой приятной функции был по крайней мере один невыносимый. Например, независимо от того, насколько тривиален цикл, вы должны переместить тело в отдельную процедуру. PERFORM ... UNTIL ...И подобные заявления являются единичные заявления - не блоковых структур. В некотором смысле, COBOL был вкус структурированного программирования от структурного программирования до того было изобретено - там былоGO TO , но его использование не поощрялось (по крайней мере , когда я использовал COBOL), но цикл , в частности , просто не был обработан , что хорошо.

Фактически, язык, который я использовал после COBOL, который больше всего напомнил мне об этом, был ... dBase. Как и в Ashton-Tate dBase III +. В наши дни люди с большей вероятностью вспомнят все ныне умершие или умирающие клоны (Clipper, FoxPro и т. Д.), Которые привели к общему имени xBase - и в xHarbour все еще есть живой потомок. Дело в том, что это были языки баз данных, но ничего похожего на SQL.

Даже тогда, когда каждая программа на языке COBOL, работающая с конкретной базой данных, должна включать копию спецификации этой базы данных (и копии могут оказаться несовместимыми), это не совсем так в xBase, где база данных знает свою собственную структуру.

Принимая это во внимание, КОБОЛ не так страшен, если вы примете его таким, какой он есть. Но это не язык для написания структур данных. Возможно, именно поэтому COBOL сильно пострадал во времена священных войн C и Pascal - обе стороны могли согласиться с тем, что COBOL не годится для повторного изобретения бинарного дерева.

Да, и одна вещь, которую я никогда не забуду, это то, что мой первый учебник на языке COBOL не описывает SORTкоманду, говоря, что она выходит за рамки книги - очевидно, либо автор не смог справиться с идеей сортировки, либо считал, что это нечто большее, чем крошечные умы студентов, изучающих язык COBOL, могут с этим справиться [см. правку в конце]. Подобные вещи мешали серьезно относиться к COBOL.

Странным аспектом этого было структурированное программирование Джексона, которое я также был вынужден изучать в то же время, особенно для использования с COBOL. Частично это рисовало структурную диаграмму для ввода, затем структурную диаграмму для вывода, а затем рисовало промежуточную структурную диаграмму для кода. Очевидно, что сортировка была уже решенной проблемой - вы не могли получить алгоритм сортировки таким образом. Так что в рекомендованном учебнике было странно сказать, что вся концепция сортировки была за пределами моего крошечного рассудка, и в то же время обучалась чему-то вроде дюжины различных алгоритмов сортировки и способов их реализации в Паскале.

Проблемы, с которыми может справиться JSP, вероятно, являются хорошим руководством для того, что COBOL может делать относительно хорошо. Но даже тогда это не обязательно означает, что JSP или COBOL являются хорошими способами решения этих проблем.

РЕДАКТИРОВАТЬ 30 июля 2014

Я только что получил репутацию, напомнив, что это здесь. Так случилось, что из-за какого-то коллекционирования древних книг, вызванного ностальгией, я теперь могу исправить точку WRT SORTкомандой.

Книга, которую я изначально использовал в качестве рекомендуемого текста при изучении языка COBOL, была «Методическое программирование на языке COBOL» Рэя Уэлленда. Это не распространяется на COBOL 85 (хотя было более позднее издание «Методическое программирование на COBOL-85», которое я до сих пор никогда не видел).

Ниже все добрые комментарии: «Вы должны были отсортировать входные файлы перед их чтением или отсортировать выходной файл после его генерации, используя утилиту сортировки, поставляемую с ОС». От моего ответа на это я пропустил пункт "пришел с ОС". Киндалл предлагал что-то похожее на философию Unix AFAICT, с COBOL, используемым для битов, для которых он хорош, утилитами ОС, такими как утилита сортировки, используемыми для некоторых других вещей, и, предположительно, с использованием языка пакетной обработки / сценариев / оболочки для склеивания битов. Это имеет гораздо больше смысла в древнем мире, где интерактивное программное обеспечение было редким или вообще отсутствовало, поэтому вы все равно будете отправлять партии работ (следовательно, «пакетный язык»).

Ниже приводится цитата со страницы 165-166 "Методического программирования на языке COBOL" ...

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

Существует также возможность сортировки записей из программы на языке COBOL, но это выходит за рамки этой книги по двум причинам:

(а) интерфейс к операционной системе часто довольно сложен и варьируется от системы к системе,

(b) модуль сортировки является необязательной частью ANS '74 COBOL и не может быть реализован в системах COBOL для небольших компьютеров.

Поэтому предполагается, что существуют средства для сортировки файлов в указанном порядке, и будет рассмотрена проблема обновления таких файлов.

Короче говоря, kindall верен - предполагалось, что обычно сортировка выполняется вне COBOL. Возможно, было даже реальное оправдание для исключения сортировки из языка программирования в 1974 году для небольших компьютеров.

То, что я сказал выше, было в основном тем, что вы получите после 20 лет неспособности проверить факты из-за выбрасывания книги.

Тем не менее, я должен отметить, что я официально изучал COBOL из этой рекомендованной книги, которая охватывала стандарт 1974 года (а не стандарт 1985 года) в 1988 и 1989 годах. Третье издание «COBOL для студентов» (Паркин, Йорк, Барнс) - первое издание, охватывающее COBOL 85 - не было опубликовано до 1990 года. Я не уверен, но я думаю, что издание COBOL 85 «Методического программирования» не было опубликовано до 1994 года.

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

Потратив большую часть сегодняшнего дня на написание некоторого COBOL, я думаю, что могу дать некоторые текущие данные.

Сначала ПЛОХОЙ материал: -

• Нет вызовов функций. Современный COBOL имеет некоторые встроенные функции, но это серьезная инженерная работа, чтобы написать свою собственную.
• Нет проверки типов при вызовах подпрограмм. Вы можете передавать (или не пропускать) что-либо в вызове подпрограммы, вызываемая подпрограмма безошибочно предположит, что она имеет правильные параметры, и нет способа обнаружить отсутствующие или недопустимые параметры.
• Нет библиотек. Ни один ноль пшик. Нет стандартных библиотек, нет широко используемых легко доступных библиотек. Вы заканчиваете тем, что кодировали задачи commomplace вручную снова и снова.
• Все реализовано как ключевое слово. Поскольку авторы языка не имеют понятия библиотеки, каждая новая функция в конечном итоге реализуется с новыми ключевыми словами, например, PARSE и RENDER для поддержки XML.

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

• Многословность. Таким образом, вы вводите несколько дополнительных символов! Это не серьезная проблема. Во многих случаях COBOL менее многословен, чем, скажем, Java.

• "COBOL FILES" Вы видите, что этот термин часто встречается. Нет такой вещи, просто COBOL может работать практически с любым форматом файла и практически с любой файловой организацией.

• Нет многопоточности. В средах, где процветает COBOL, многопоточность обычно оставляется для контейнеров приложений, таких как CICS или IMS, которые хороши в этом, а не для программистов, которые склонны плохо это делать.

И хорошая вещь - некоторые аспекты COBOL превосходят другие языки:

• Структуры данных. COBOL имеет краткий и гибкий синтаксис для определения сложных структур данных и нечетных типов данных.
• Десятичная арифметика. Он имеет встроенную поддержку десятичной арифметики, то есть арифметики в понимании бухгалтеров с правильным округлением и т. Д.
• Двигаясь со временем. Некоторые аспекты COBOL удивительно современны. Встроенная поддержка XML, поддержка OO-программирования, возможность использования классов Java и т. Д.
• Интеграция с DB2, CICS и т. Д. Это относится только к COBOL IBM для мэйнфреймов (но это, безусловно, самая большая часть COBOL, все еще работающая), но интеграция с DB2, CICS и другими средами мэйнфреймов упрощает кодирование таких вещей, как базы данных. веб-сервисы, чем в любой другой среде.
• Обработка экрана. Стандартная обработка экрана, реализованная в AS / 400 и MicroFocus Cobol, превосходна.
• Представление. В течение многих лет компиляторы COBOL производили исполняемые файлы с очень высокой производительностью. Только нативный C и нативный Ассемблер победили COBOL на мэйнфрейме IBM.

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

Это, вероятно, до Джикстра. Джикстра заявил, что «использование COBOL наносит вред разуму, поэтому его обучение должно рассматриваться как уголовное преступление». Кобол считался наивным, неструктурированным и многословным. С возможностью самостоятельного изменения кода (практика, которой не одобряют даже программисты на cobol), он также считался довольно сложным для отладки или выполнения.

Кроме того, существует проблема несовместимости версий.

Я бы предложил прочитать раздел критики и защиты в Википедии для языка - http://en.wikipedia.org/wiki/COBOL#Criticism_and_defense

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

Кажется, я вспоминаю, что главная цель IBM при разработке COBOL состояла в том, чтобы «позволить управляющему банка написать программу». Эта цель, очевидно, оказала глубокое влияние на способ, которым был разработан язык, и теперь он развился.

Очевидно, в дикой природе больше коболов, чем на любом другом языке. Однако, проработав в ИТ почти 20 лет (15 в банковской сфере), я никогда не сталкивался ни с одной системой, которая была бы в нем внедрена.

Что такого плохого в Коболе?

Ничего.

Я думаю, что у людей есть предвзятое мнение, что старое - это плохо, «самое новое - самое лучшее». Он по-прежнему используется очень активно, и я уверен, что в течение еще полувека будет достаточно работ по обслуживанию кода.

В 1997 году Gartner Group сообщила, что 80% бизнеса в мире работает на COBOL с более чем 200 миллиардами существующих строк кода и примерно с 5 миллиардами строк нового кода ежегодно. (через википедию )

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

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

Людям не нравится COBOL, потому что он имеет ограниченное применение. Он был разработан для бизнеса, финансов и административных систем для компаний и правительств.

Что у них общего? Данные. Много-много данных.

Угадайте, кто был создан, чтобы обрабатывать данные и иметь много файлов на завтрак? Можете ли вы сказать COMMON бизнес-ориентированный язык ?

50 лет назад COBOL был лучшей вещью для крупных организаций с большим количеством данных для управления. Сегодня существуют более эффективные способы управления большим объемом данных, поэтому COBOL больше не актуален. Либо это?

Давайте рассмотрим правительства. Какие данные нужно отслеживать правительству? Идентификаторы людей, свидетельства о рождении, медицинские карты, налоги (о ... да ... налоги) и т. Д. И т. Д. И они должны хранить эту информацию бесконечно, сегодня и 50 лет назад.

Люди также указывали на банки в некоторых ответах, и банки действительно активно используют КОБОЛ. Почему? потому что в отличие от других типов компаний банки обычно имеют историю. Некоторые существуют сотни лет ( как, например, этот ).

Это означает, что некоторые данные за 50 лет все еще должны быть здесь с нами, сегодня, 7 октября 2011 года. Теперь у нас есть SQL Server и C # или Oracle и Java, но 50 лет назад были COBOL и файлы.

Со временем данные по правительствам и банкам становились все больше и больше, и миграция систем становилась все дороже. Это означает, что они должны оставаться в COBOL и постоянно поддерживаться и развиваться по мере развития бизнеса. Некоторые банки медленно мигрируют, в то время как другие просто прикрепляют красивый интерфейс Web2.0 перед мэйнфреймом (в основном используются c # и Java). Можете ли вы сказать старый код? (COBOL идет рука об руку с (экстремальным) унаследованным кодом, который был тронут многими людьми за десятилетия существования - еще одна вещь, которая нам не нравится программистам: D).

И теперь у вас есть ниша деятельности. COBOL теперь имеет ограниченное применение, и это влияет на ваш опыт .

И люди, которые попадают в COBOL, в конечном итоге обнаруживают, что вы делаете одно и то же снова и снова, год за годом, и к тому времени, когда они просыпаются, они уже не конкурентоспособны на рынке, потому что люди теперь хотят PHP, Java, C # , REST, jQuery и только банки ищут людей COBOL.

На данный момент спрос ниже, чем предложение, и те, кто не делает сокращение, должны перейти к чему-то другому. И они должны начинать с юниоров, так как COBOL действительно наносит вред разуму (верьте, копирование-вставка не является основным стилем разработки в COBOL и объясняет его большую производительность), и теперь они проклинают день, когда они взяли COBOL и не не упускай ни одного случая рассказать об этом своим ужасным историям :). Но вы могли бы рассказать эти истории о любом старом пердунском языке, который больше не востребован в наши дни, но вы несчастный человек, застрявший в нем. Хорошо...

PS и COBOL это плохо по всем другим причинам, упомянутым другими :)

PS2. In 1997, the Gartner Group reported that 80% of the world's business ran on COBOL with over 200 billion lines of code in existence and with an estimated 5 billion lines of new code annually.В самом деле? И как день измерил это? Они пошли, чтобы сделать каждую компанию в слове и спросить их, сколько линий КОБОЛ у них есть или что?

Две особенности

• Утверждение ALTER - это чистое зло. Хотя он редко используется в более современных приложениях COBOL, он интенсивно использовался в «старые времена», потому что он был более эффективным, чем эквивалентная структура «IF-GOTO». Когда компьютеры имели только 32 КБ ОЗУ, каждая инструкция имела значение. Он изменил оператор GOTO, чтобы иметь другое назначение.

  Это сделало некоторый код непрозрачным, потому что сам код был с состоянием.

• Предложение REDEFINES в структуре данных (например, unionв C) является постоянной проблемой. Термин «свободное объединение», т. Е. Наложенные структуры данных без дискриминатора, является способом обобщения проблемы. Два псевдонима REDEFINES не могут быть легко различимы данными; только обширное чтение логики программы может определить значение двух альтернативных интерпретаций байтов.

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

Читаемость англоязычного синтаксиса была нарушена этими двумя конструкциями.

[Модераторы предупреждали меня, что короткие ответы пренебрегают твоим важным и интересным вопросом. Если вы сочтете это пренебрежительным, вы можете попросить детали. Или пометьте, чтобы модераторы могли его удалить.]

Я программировал на COBOL уже несколько хороших лет. Его синтаксис прост по сравнению с современными языками, и вам не нужно много теории, чтобы научиться работать. COBOL очень хорошо работал с CICS IBM (онлайновой системой управления транзакциями), и программист должен отметить в коде масштабирование числа пользователей приложения от 1 до нескольких тысяч. CICS предоставил основанный на символах графический интерфейс, который работал с экраном как единица отображения (без окон). Вы можете отобразить диаграммы с помощью (IBM GDDM) на мэйнфрейме. COBOL может взаимодействовать с индексированными файлами (VSAM и ISAM), а также с DB2 (реляционная система на основе SQL), а также с IMS. COBOL / CICS - очень надежная среда, и вы можете выучить ее за несколько недель. Это означает, что вы сосредоточены на бизнесе, а не на технологии, поэтому вы работаете 7 из 8 часов над программированием, а не изучая MVM, JavaScript и тому подобное.

Проблема с COBOL заключается в плохом маркетинге, который приводит к отсутствию интереса со стороны третьих сторон к разработке инструментов и сред программирования для него. Кроме того, отсутствие поддержки интерфейса, подобного Windows, привело к снижению его популярности после 1993 года. Стоимость мэйнфреймов заставила клиентов искать альтернативы и компиляторы для COBOL, доступные в UNIX и DOS. Язык C привлекал много внимания, поскольку он мог быть более переносимым и имел прямой доступ к функциям ОС, чего у COBOL было очень мало.

Такие языки, как VB, DBase, FoxPro и Clipper, имели лучшие способы доступа к «базам данных» на ПК, чем сопоставимый COBOL в DOS, поэтому COBOL проиграл. CICS долгое время не удешевлялся в DOS или UNIX, поэтому его ценность в этих средах отсутствовала.

Сегодня COBOL поддерживается с .NET, но я думаю, что он проиграл битву на всех платформах, кроме мэйнфрейма (и, возможно, AS / 400), где он все еще там, из-за огромного количества критически важных приложений, которые полностью зависят от Это.

Хех, я учился в колледже в начале 80-х, и люди тогда уже презирали КОБОЛ. Я думаю, что самая большая проблема - это многословие - простое «Привет, мир!» в COBOL, вероятно, более пятидесяти линий, 95% из которых являются обязательными шаблонами. Это просто не очень элегантный или привлекательный язык. Он также был разработан для решения вчерашних проблем и на самом деле не подходит для парадигм разработки, разработанных после 1970 года. Это довольно хороший язык генерации отчетов - если ваши отчеты представляют собой бесконечные столбцы чисел с верхними и нижними колонтитулами. Если вы хотите вставить график или логотип где-нибудь, забудьте об этом. Я думаю, что это все еще самый быстрый язык для задач типа «обработка данных» (возьмите файл фиксированного формата с 5M транзакциями ATM и выполните простую настройку баланса для каждой из них), но сколько разработчиков делают такие вещи больше? И в настоящее время многие системы используют XML или JSON, я не хотел бы думать о попытке разобрать что-либо подобное с помощью COBOL (на самом деле, я бы не хотел думать о синтаксическом анализе вообще в COBOL!)