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

52

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

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

Барри Браун
источник
8
COBOL подходит для работы с иерархическими базами данных или плоскими файлами и для выкачки данных в большие текстовые отчеты на гигантском матричном принтере. Но большая часть данных в настоящее время находится в РСУБД, и большинству менеджеров нравятся симпатичные отчеты. Кобол просто не справляется с этим.
фунтовые
1
@ Steve314: Да! Те! За исключением того, что у нас была Линия Матрица, и я не пил кофе этим утром, когда писал это. - en.wikipedia.org/wiki/Line_matrix_printer
фунтовые
3
Если вы не выберете COBOL, если вы будете немного искать, я думаю, вы заметите, что многие языки, специфичные для предметной области, не очень популярны (если не сказать больше); COBOL, Fortran, VB6, MATLAB ... все очень хорошие языки, просто не годятся для преподавания компьютерных наук и их абстракций.
Ладья
4
@Rook - действительно ли они считаются языками, специфичными для предметной области? Даже MATLAB, IIRC, по-прежнему способен к программированию общего назначения. Я думал, что DSL в основном применяется к таким вещам, как yacc, lex и т. Д. - к языкам, которые действительно способны выполнять довольно узкие задачи, что приводит к другому общему названию «маленькие языки». Мне никогда не приходило в голову, что COBOL, Fortran или VB можно назвать доменными. Конечно, каждый из них, как правило, используется в определенных областях, но я думал, что они все еще обычно считаются языками общего назначения.
Steve314
1
@ Steve314 - Да, хорошо, можно сказать, что есть две стороны. Один говорит, что дом.спец. одни - только те, о которых вы упомянули, другая - более общая и учитывает ту, которую я тоже упомянул, но при этом сохраняет их в категории общего назначения. Но практически везде, где вы упоминаете инженерию и науку. сост. вы получите Fortran или MATLAB, бизнес ... COBOL ... используйте терминологию, которая кажется вам наиболее логичной. Я использую этот, потому что я считаю, что он подходит большинству людей. В любом случае, они получают справедливую долю ударов по какой-то причине от сообщества CS в целом.
Грач

Ответы:

68

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, тянущий его ноги - ну, не так много в любом случае. Принятие новых стандартов требует времени для любого языка, даже сейчас.

Steve314
источник
5
+1 Для того, чтобы действительно знать, о чем ты говоришь. Хотел бы я дать тебе еще один +1 за JSP. Вы когда-нибудь использовали «Дельта»? Это был генератор Cobol, такой, что вы могли записать свой JSP в код в стиле, подобном определениям памяти (01 - 03 - 05), а затем записать свой Cobol в пробелы. И весело, и чертовски неприятно.
фунтовые
3
Страница Википедии на JSP - en.wikipedia.org/wiki/Jackson_Structured_Programming . Когда я это узнал, все было сделано на бумаге.
Steve314
1
Причиной того, что сортировка рассматривалась как решенная проблема, было то, что она была. Насколько я помню, COBOL действительно не рекомендовал иметь в памяти более одной или двух записей одновременно (текущую и, возможно, предыдущую). Вы должны были отсортировать входные файлы перед их чтением или отсортировать выходной файл после его генерации, используя утилиту сортировки, поставляемую с ОС.
любезно
1
Я сделал немного COBOL за пару лет (для справки, мне всего 26), и я могу уточнить одну вещь для вас. Вам больше не нужно определять абзацы для каждого цикла, теперь вы можете встроить его PERFORM UNTILв END-PERFORMблоки. Я действительно ненавижу это, я знаю это.
AgentConundrum
1
@NealB Я просто разъяснил ему вопрос, так как он признает, что его опыт устарел, даже по стандартам COBOL. Я понимаю вашу точку зрения на COBOL85, но есть много старого кода, который был запущен до того, как он появился, или был написан людьми, чьи головы застряли в предыдущей версии. Вы действительно не можете предположить, что кодовая база соответствует 85 стандартам, но даже если это так, это все еще неудобный язык. Старые программисты выходят на пенсию быстрее, чем их заменяют, и очень немногие новые программисты хотят работать в COBOL. Я знаю, что не хотел бы снова трогать вещи.
AgentConundrum
43

Потратив большую часть сегодняшнего дня на написание некоторого 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.

Джеймс Андерсон
источник
2
В своем ответе я говорю, что COBOL вреден для структур данных. Разница в том, что означает «структура данных»? Может быть, инструменты верстки отличные, но COBOL все еще не подходит для бинарных деревьев и т. Д.? Или, может быть, мой опыт работы с COBOL был слишком стар или иным образом ограничен? Ключевой вопрос - есть ли в COBOL указатели? (Удивительно, но быстрый Google предлагает да, хотя моя старая книга предлагает нет). Я бы не хотел отказываться от ответа, который заработал для меня все эти прекрасные повторения, но если я ошибаюсь ...
Steve314
3
Есть обратная сторона десятичной арифметики: вы должны точно сказать, сколько цифр вы хотите. Я помню, как находил ошибки, когда у нас в предложении было слишком мало 9s PICв какой-то программе в группе.
Дэвид Торнли
2
У меня (неосведомленное) впечатление, что COBOL особенно хорош при работе с данными в жестких записях фиксированного размера. Не очень хорошо, возможно, в динамических структурах данных. Поправьте меня если я ошибаюсь.
Барри Браун
@ Steve314 - да, указатели появились примерно в 1985 году, но были немного неубедительны, так как их можно было только установить в разделе ссылок. Более поздние версии позволили вам указать на что-либо.
Джеймс Андерсон
1
@Structures - хотя он не соответствует стандартам Python с точки зрения хэшей, деревьев и т. Д. Он так же хорош, как C или Java - за исключением того, что он не так хорош, как C ++ плюс Boost или Java плюс библиотека коллекций. Еще раз неспособность оценить ценность стандартных библиотек и функций нанесли вред языку на протяжении всей его долгой жизни.
Джеймс Андерсон
27

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

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

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

Дэнни Стейпл
источник
20
Когда-нибудь они обнаружат хранилище, заполненное кодом, написанным Дейкстрой на языках, которые он осудил.
Йонска
7
@jonsca - вы будете удивлены тем, что вы будете делать за деньги.
Джефф
3
Несовместимые версии были IIRC довольно распространенным явлением, по крайней мере, до 70-х, и даже в 80-х годах была Basic. Дейкстра, вероятно, высказал свою точку зрения, основываясь на проблеме, которую я упомянул в своем ответе - COBOL не подходит (или не должен быть хорошим) для кодирования структуры данных. Следовательно, для конкретной ценности "обучения программированию" или "обучения информатике" COBOL действительно является ядом. Конечно , так как COBOL не предназначена для этого, это довольно несправедливо утверждение - но опять же , IIRC, контекст в том , что некоторые люди были пытаются научить эти вещи , используя COBOL.
Steve314
2
Дейкстра <- человек, который слишком много разговаривал ...
Ладья,
3
@Danny: COBOL презирали задолго до того, как Дейкстра написал эту строчку в 1975 году.
John R. Strohm
9

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

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

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

Шон
источник
Я слышал, как кто-то случайно упомянул о банковском деле, и это единственная причина, по которой я включил его, но я непременно поверю вам на слово за кого-то другого.
Jonsca
4
Я работал в течение 20 лет в банковском деле, почти все это в COBOL. Я полагаю, разные банки делали вещи по-разному.
TrueDub
Я знаю, по крайней мере, одну крупную ERP-систему, в которой (или до 2007 года) было много COBOL.
Алан Б
2
Это был не IBM, который разработал COBOL. Основными зачинщиками были ВМС США и UNIVAC.
Джеймс Андерсон
8
«Главная цель IBM при разработке COBOL состояла в том, чтобы« позволить управляющему банка написать программу »». Благородная цель, хотя подавляющее большинство знакомых мне менеджеров не могут даже написать мне простую литературу для веб-сайта, не говоря уже о том, чтобы написать COBOL.
maple_shaft
8

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

Ничего.

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

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

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

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

jonsca
источник
1
Языки для пользователей?
Джефф
16
«Строки кода» не является хорошей междисциплинарной мерой. Кобол общеизвестно многословен. Эти 5 миллиардов строк кода в год, вероятно, эквивалентны семнадцати регулярным выражениям;)
MSalters
3
Иногда COBOL является подходящим инструментом для работы - часто это не так. Самое сложное - заставить людей осознать разницу.
TrueDub
1
Совершенно верно, @TrueDub. Мое предложение звучало немного навязчиво, но так не должно быть.
Йонска
3
@TrueDub: Если COBOL - правильный инструмент для работы, я не хочу выполнять эту работу, пока у меня есть альтернативы. Есть гораздо более интересные работы, за которые мне хорошо платят.
Дэвид Торнли
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.В самом деле? И как день измерил это? Они пошли, чтобы сделать каждую компанию в слове и спросить их, сколько линий КОБОЛ у них есть или что?


источник
4

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

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

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

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

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

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

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

С. Лотт
источник
Я не помню ни одного из них - либо репрессии, либо я их никогда не изучал. Быстрый поиск говорит мне, что я, безусловно, согласен с тем, что ALTERэто зло, но эта функция редко используется, если вообще используется, поэтому на самом деле это не причина ненавидеть COBOL. REDEFINESХотя я не уверен в этом . Сравнение с этим unionзаставляет меня думать немного более доброжелательно к этому - но, возможно, то, что хорошо в низкоуровневом языке с битами и обработкой структуры данных, может не быть такой хорошей идеей в обработке данных.
Steve314
Иногда ваши ответы кажутся мне пренебрежительными, но этот просто бесполезен. Я не знаю, пытаешься ли ты здесь помочь, но делаешь это плохо или просто говоришь сам с собой. Я мог бы спросить вас, что вы подразумеваете под «чистым злом», но прелесть хороших ответов выше в том, что мне не нужно начинать разговор, чтобы чему-то научиться.
Эрик Уилсон,
@EricWilson: Спасибо, что так тщательно отклонили мой ответ. Это помогло мне понять, что еще нужно добавить.
S.Lott
1
@Eric - проблема в ALTERтом, что он перенаправляет gotos. Во-первых, это означает, что вы используете gotos - сам по себе я не думаю, что это зло, но в большинстве языков это необычная вещь для особых случаев. Во-вторых, это означает, что gotos идут куда-то иное, чем там, где, как они говорят, они пойдут - и это просто ужасно. Я не совсем уверен, что это самоизменяющийся код, но он описан как то, куда я смотрел, и думаю о том, что изменение целей инструкций перехода в ассемблере объясняет почему.
Steve314
@ S.Lott Спасибо за ваши дополнения (вы тоже @ Steve314), я узнал кое-что интересное и изменил свой голос.
Эрик Уилсон,
3

Я программировал на 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), где он все еще там, из-за огромного количества критически важных приложений, которые полностью зависят от Это.

Без шансов
источник
«отсутствие поддержки интерфейса, похожего на Windows» .... что насчет netcobol.com/products/Fujitsu-NetCOBOL-for-.NET/overview
JoelFan,
@JoelFan спасибо за ваш комментарий. Вы правы, что сегодня есть лучшие инструменты для COBOL, но я думаю, что все они прибыли слишком поздно. Моя точка зрения относительно отсутствия поддержки интерфейса Windows была в начале 90-х, когда только Micro Focus был единственным игроком на рынке.
NoChance
2

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

TMN
источник
1
«Hello World» занимает сколько строк? Разбор / генерация XML - теперь встроена в язык. Может быть, вы должны обновить свою базу знаний. Этот ответ относится к эпохе КОБОЛ 1960-х годов.
NealB
Интересно. Мне не приходилось работать с КОБОЛОМ около десяти лет, но в последний раз, когда я увидел его, он был написан так же, как я его запомнил, ОТДЕЛ ИДЕНТИФИКАЦИИ, РАЗДЕЛ РАБОЧЕГО ХРАНИЛИЩА и все. Я предполагаю, что все эти "обязательные комментарии" (АВТОР, ДАТА-ЗАПИСЬ, ИСТОЧНИК-КОМПЬЮТЕР, ОБЪЕКТ-КОМПЬЮТЕР) теперь являются необязательными. Синтаксический анализ XML не выглядит таким уж впечатляющим - вы должны структурировать разделение данных, чтобы отразить файловую структуру, нет обработки в стиле SAX или DOM. Приятно знать, что там есть.
TMN