Почему КОБОЛ является все еще предпочтительным языком в деловом мире? [закрытый]

Я не так уверен, Cobol предпочитается большим бизнесом и правительством. Я бы сказал, терпимо мощь Будь лучшим словом.

Почему?

1. , потому что большое правительство / бизнес риск неблагоприятно, когда дело доходит до управления их Финансовые системы. Привернуть здесь и все Предприятие ставится в опасность. Если это не сломалось Не исправляйте это.

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

3. Объем транзакции. Приложения Cobol имеют тенденцию быть оптимизирован для пропускной способности. Пакетная обработка большая Сумма данных - это то, где Cobol действительно сияет. Ява Приложения несколько сложнее оптимизировать для пропускная способность из-за тенденции иметь больше инфраструктуры слои между программой и «металлом», который Добавляет перетяжку перетаскивания. Большой бизнес / правительство имеет много данных для продвижения их систем и пропускной способности необходимы.

4. Стоимость за транзакцию. COBOL обычно имеет нижнюю Стоимость за транзакцию, когда все факторы включены. Это частично, потому что время обработки стоит деньги, а приложения Cobol, как правило, больше эффективный. Тем не менее, приложения Cobol, кажется, имеют Нижние затраты на разработку / обслуживание тоже.

Прежде чем все перепрыгивают на меня на этот последний момент Позвольте мне объяснить ...

Я работаю в очень большой магазин и несколько лет назад исполнительный Решение было принято для создания всех новых систем в Java. Кобол собирался сохранить только для Поддержание существующего устаревшего программного обеспечения. А. полный фаз был запланирован на 15 лет горизонт.

некоторые из лучшие и яркие умы Java были приведены тренироваться, настроить лучшие практики, строить инфраструктуру и поддержка крупномасштабного развития Java. Этот Инициатива была хорошо спланирована и казнена. Потом, После размещения ряда приложений Java было развернуто «Подсчет бобов» начался. Результаты были то, что Приложения Cobol все еще стоят меньше, чтобы развиваться, поддерживать, поддерживать и проходить - длинное жесткое количество хрусте здесь Потому что результат не был приветствоваться!

Кобол вернулся - но не полностью. Новое исполнительное направление - держать Cobol для тяжелый подъем (обработка задней конечной транзакции) и Пакетные ориентированные приложения. В основном кобол должен быть используется для номера Реализация хрусте и бизнес правила. Java приходит к спереди, чтобы обеспечить интерфейсы типа графических интерфейсов и легкий вес обработка.

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

Почему это прижилось?

Это сильно подтолкнула IBM. Это было большим подспорьем для FORTRAN и COBOL, но не для PL / 1.

Он был доступен очень рано, впервые появился до 1960 года.

Это было намного проще, чем использование ассемблера, даже ассемблера IBM 360 (который был очень хорош для бизнес-обработки). Он подобрал множество людей, которые пытались сделать лучше ассемблера.

Это очень хорошо соответствовало общепринятой в то время практике вычислений для бизнеса. Он очень хорошо принимал ввод, выполнял незначительные преобразования и выдавал отчеты. (Это все еще так, если на то пошло, но у предприятий в настоящее время гораздо более разнообразные потребности.)

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

[Сообщение поставщика - но не обязательно официальное заявление поставщика]

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

Как описывает НилБ в своем посте, я разговаривал с пользователями, естественной средой и опытом которых является Java, но они сохраняют основную логику COBOL, потому что это лучший инструмент для работы. Они свободно смешивают Java (в первую очередь для обработки строк UNICODE и системной интеграции) с COBOL в одном приложении. если они сравнивали объем кода для выполнения той же работы на Java, это просто не имело смысла. Алекс Тернер разместил на другом веб-сайте несколько отличных примеров, в которых сравниваются типичные бизнес-функции на COBOL и Java.

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

Эти машины также поддерживают смехотворно большие скорости ввода-вывода; если вы не можете обработать дневные транзакции в режиме реального времени, вы не у дел.

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

Код нелегко перенести на другой язык, потому что разработчики не «планировали», чтобы это когда-либо произошло. Перенос кода, на котором сегодня работают системы, на другой язык - это риск и очень большие затраты.

Надежность имеет значение, и в COBOL она есть в избытке.

Во-первых, я работаю в Micro Focus, поэтому я заинтересованная сторона. Однако я бы поставил вопрос на себя. Почему нет? Неотъемлемое предположение состоит в том, что C ++, C # или Java, естественно, будут лучше, потому что они новее. Однако COBOL не стоял на месте. Отчасти из-за многословного синтаксиса в COBOL оказалось возможным добавлять новые функции, чтобы он оставался конкурентоспособным. Люди довольно часто говорят о том, насколько «плохой» COBOL, но сравнивают COBOL 30-летней давности с последней версией C #, Ruby и т. Д.!

Действительно, сама история развития COBOL при сохранении его обратной совместимости является веской причиной для бизнеса инвестировать в него; tco уменьшается, потому что нет необходимости переписывать.

Чтобы узнать больше о самой последней версии COBOL, посетите сайт сообщества Managed COBOL: http://knol.google.com/k/alex-turner/micro-focus-managed-cobol/2246polgkyjfl / 4

Почему это прижилось?

Потому что в конце 1950-х годов правительство США постановило, что если поставщик программного обеспечения хочет продать приложение или написать приложение для правительства, язык должен быть коболом.

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

Вторая причина: потому что даже сегодня он лучше любого другого языка, который я знаю, для некоторых аспектов определенных бизнес-проблем, которые возникают довольно часто. Самый важный из этих аспектов - десятичная арифметика. У Cobol он изначально есть (как в случае с PL / 1 и т.п.), но это не относится ни к одному из тех якобы «более современных» языков. Между прочим: именно по этой причине здесь возникает так много вопросов о том, «какой тип данных лучше всего подходит для хранения денежных значений?». Люди, задающие эти вопросы, знают не лучше, чем то, что весь ИТ-мир состоит из некоторого объектно-ориентированного языка и некоторого инструмента ORM, и понятия не имеют, почему такая вещь, как «денежная арифметика», может быть полезна для компьютерного языка для ее поддержки изначально , т. е. чтобы компьютерный язык имел для него встроенный, собственный тип данных, отличный от bigint (при этом программист все еще должен отслеживать количество десятичных знаков), или с плавающей точкой (при этом программист все еще ответственность за добавление правильной логики округления повсюду).

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

C++ и C являются хорошей заменой для системного стиля, но они отстают по математике с фиксированной точкой и сильной поддержке ввода-вывода, ориентированного на запись. В пространстве, где живет большинство финансовых и деловых приложений, z/OS, и Cobol, и z/assembler имеют лучшую встроенную поддержку этих вещей.

Java хороша, безопасна и работоспособна. А на мэйнфреймах IBM Java и Cobol очень хорошо взаимодействуют друг с другом. Но некоторые вещи, которые легко сделать на Cobol, очень трудно сделать на Java, и обратное верно. Они дополняют друг друга, а не заменяют. Java также выполняет всю математику с фиксированной запятой через библиотечные вызовы, которые намного медленнее, чем поддержка родного опкода.

Python использует библиотечную (она же модульную) поддержку для математики с фиксированной точкой, а также для ввода/вывода записей. Он также страдает от фатального, IMHO, недостатка дизайна - использования отступов для разграничения области видимости. Это работает достаточно хорошо в относительно однородной среде Mac/Windows/Unix с некоторым вариантом набора символов ISO8859-1. Это чревато проблемами при переходе от мира, ориентированного на ASCII, к миру, ориентированному на EBCDIC, где терминаторы строк не так просты, как "\n\r, \r, \n", и любая неправильная конфигурация в пакете передачи файлов, процедура преобразования символов или редактирование на терминале, настроенном на другой набор символов, разрушит область видимости вашего источника.

Все упомянутые вами языки имеют слабые места в критических бизнес-потребностях, где Cobol наиболее силен.

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

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

http://userweb.cs.utexas.edu/users/EWD/transcriptions/EWD12xx/EWD1284.html