Давным-давно, когда мир был юн, и компьютеры в нем были в новинку, я учился по программе на младшего сотрудника (Associate Degree) по обработке данных – программ по «компьютерным наукам» тогда не было – и в рамках этой программы преподавались бухгалтерское дело, математика, статистика, а также три языка программирования: ассемблер IBM/360, FORTRAN и COBOL. К 80-м студентам уже рассказывали, что COBOL мертвый язык, и никто его больше не изучают.
Ныне государственные учреждения и банки умоляют прислать им COBOL-щиков, специалистов по языку, который не хочет умирать.
Лора Келли, губернатор Канзаса, сказала:
По всей стране еще осталось множество служб занятости, чьи системы по-прежнему работают на COBOL. Знаете, такая очень-очень старая технология,” – говорит Келли, - “Наша служба занятости признает эту проблему и инициировала модернизацию, но, к сожалению, модернизация – как раз такой процесс, на который требуется время. Потом все планы смешал этот вирус, и пришлось прекратить работы по переходу на гораздо более надежную систему. Поэтому они пользуются по-настоящему древними программами
Губернатор Нью-Джерси Фил Мерфи выступил по телевидению, умоляя COBOL-программистов о помощи.
Итак, как же выучить COBOL, срубить на этом кучу денег, спасти множество госслужб, которым нужен новый код, чтобы справиться со всеми этими программами государственного стимулирования?
Давайте разберемся.
COBOL? Какой такой COBOL?
COBOL означает COmmon Business Oriented Language (бизнес-ориентированный язык общего назначения). Это один из первых высокоуровневых языков программирования, был спроектирован группой, финансируемой Министерством Обороны. Их задачей было разработать общий язык для решения бизнес-задач. Эту группу прозвали CODASYL— «Комитет по языкам систем обработки данных» — и группа подготовила спецификацию «бизнес-ориентированного языка общего назначения», опираясь на идеи из языка FLOW-MATIC, разработанного Грейс Хоппер, а также на идеи других языков, в том числе, AIMACO из компании Univac и COMTRAN, применявшегося в IBM. Получившийся у них язык был несколько раз пересмотрен, но быстро занял доминирующую позицию в деле построения бизнес-систем и не утратил этого лидерства до сих пор.
COBOL пользуется множество компаний, среди которых - IBM, UPS и Cigna. Марио Себальос, программист из Cigna, рассказывает: “Синтаксис оставили простым, чтобы не-программисты (“Бизнес”) могли читать и понимать его. В COBOL все выражается явно, чтобы не оставалось места ни для каких допущений.”
Разумеется, были у него и критики. Известно, как в 1975 году Эдсгер Вибе Дейкстра провозгласил, что “Использование COBOL калечит ум. Его преподавание, следовательно, должно рассматриваться как уголовное преступление [sic].” Несомненно, это поспособствовало отказу от преподавания COBOL в университетах, но он оставался доминирующим бизнес-языком.
Но найти людей со знанием COBOL бывает сложно. «Мейнфрейм – платформа, на которой сложно учиться, и все дело в цене», - говорит Себальос. – «у разработчика-одиночки нет денег, чтобы взять в аренду мейнфрейм. Очень в немногих вузах читают курсы по мейнфреймам и COBOL. Когда IBM стала осваивать удаленную работу и аутсорсинг, они прекратили стимулировать американские вузы преподавать курсы по мейнфреймам и COBOL. Специалистов стали выбирать из-за рубежа. Любой талантливый американец обошелся бы слишком дорого, учитывая, сколько он берет за консультации.”
Почему COBOL по-прежнему в цене
COBOL отличается от типичных языков программирования, используемых сегодня, и в некоторых отношениях он очень ограничен: в нем не поддерживается динамическое выделение памяти, не так легко обратиться к низкоуровневым возможностям операционной системы или конкретной архитектуры компьютера. В самых распространенных вариантах этого языка неприменима рекурсия. На COBOL никому не захотелось бы написать компилятор. Если показать COBOL студенту-информатику, его это просто заденет.
В данном случае допускается категорийная ошибка. На самом деле, COBOL – это предметно-ориентированный язык, специфичный для конкретной области бизнес-программирования. Роберт Гласс показал, в каких именно отношениях COBOL лучше подходит для бизнес-программирования, чем более универсальные языки. Например, вот по каким причинам:
1) В бизнес-ориентированном языке нужно объявлять неоднородные данные, управлять и оперировать ими. В бизнес-программах перемежаются строки фиксированной и переменной длины, бок о бок применяются целые числа, числа с плавающей точкой и десятичные данные, а также с диким энтузиазмом ставятся сложные структуры-записи, зачастую – с переменными частями. Программисты баз данных знакомы с некоторыми из этих проблем, и инструменты для объектно-реляционного отображения регулярно натыкаются на такие сложности.
2) Бизнес-данные и финансовая информация должны управляться с применением истинно десятичных типов данных. Системы бухгалтерского учета должны давать результат, точный до последнего десятичного знака, и при этом в точности воспроизводить результаты вычислений, сделанных вручную. Обычные числа с плавающей точкой провоцируют сложности и ошибки.
3) Бизнес-ориентированный язык должен обращаться к большим объемам данных, структурированных в форме записи и оперировать ими, притом, что эти данные поддерживаются извне.
Конечно, сегодня все это в пределах возможностей универсальных языков программирования. Но для COBOL это родная возможность.
Можно спорить о том, нужен ли COBOL, но есть факт: на COBOL существуют сотни миллиардов строк кода, и попытки мигрировать с COBOL на другой язык в целом не были успешны.
Ваша первая программа на COBOL
Исходный код – это просто текстовые файлы. В COBOL не менее, чем в любом другом языке, важно иметь удобный редактор с поддержкой языка – если не более. Начинающему проще всего будет пользоваться Visual Studio Code, единственным редактором со времен EMACS, который мне по-настоящему понравился.
Удивительно, насколько много есть VSCode-расширений для COBOL. В настоящее время я пользуюсь bitlang, обеспечивающим подсветку кода, а поддержку языка нашел в Broadcom COBOL. Есть еще множество инструментов, ориентированных на тех, кто программирует под мейнфреймы, но такие редакторы слишком сложны, и во вводной статье, такой, как эта, они излишни.
Итак, вот что нужно сделать, чтобы приступить к экспериментам с COBOL:
1. Скачайте и установите Visual Studio Code, если еще не сделали этого.
2. Установите расширения bitlang.cobol и Broadcom COBOL Language Support.
3. Установите GnuCOBOL. (Честно, если с чем-то у вас и возникнут неприятности, то с этим. Версия Homebrew под MacOS работала нормально, а других систем, на которых можно было ее протестировать, у меня не было. Под Windows есть программа MicroFocus, в которой предусмотрен бесплатный пробный период для Visual Studio COBOL и поддержка Azure для экспериментов.)
Вот вы и установили все, что нужно и готовы написать вашу первую программу на COBOL. По традиции начнем с азов, то есть, с программы “Hello, world”.
Вот и первый повод удивиться для COBOL-новичка: в COBOL важно, в каком столбце находится ваш код. В традиционной программе на COBOL в исходнике несколько компонентов:
Столбцы 1-6 – для порядкового номера. Столбец 7 называется «областью индикатора»; в нем обычно обозначаются комментарии, для этого в данный столбец ставится астериск ‘*’. Далее в столбцах 8-72 идет код, а столбцы 73-80 программист обычно вправе использовать по собственному усмотрению.
Такая структура восходит к тем временам, когда мы записывали наш исходный код в 80-столбчатые перфокарты.
Современные компиляторы для COBOL также принимают и свободный формат, не обязывающий вас втискивать код в такой 80-столбцовый корсет, но весьма значительная часть актуального кода по-прежнему существует в таком перфокартном формате. Пока давайте продолжать работу с образами перфокарт.
Крепитесь: COBOL структурируется не поблочно, как почти все прочие языки, которыми вы могли пользоваться. С самого начала одна из основных целей проектирования COBOL заключалась в том, чтобы он был «самодокументируемым» и походил по синтаксису на английский язык. Тут нет никаких функций, подпроцедур и блоков, а есть разделы, секции, абзацы и утверждения. (Почти полная подпроцедура – это глагол PERFORM, который встретится нам ниже.)
Да, кстати, у нас же есть глаголы для операторов COBOL.
Вот программа “Hello, World” на COBOL:
IDENTIFICATION DIVISION.
PROGRAM-ID. HELLO.
PROCEDURE DIVISION.
DISPLAY "Hello, world".
END PROGRAM HELLO.Она довольно многословна по сравнению с программами на других языках, но определенно не так плоха. Сравним ее с простой версией на Java:
public class Hello {
public static void main(String[] args){
System.out.println("Hello, world!");
}
}Как и все “Hello, world”-подобные программы, она ничего не делает. Но, если вам говорили, что для создания простейшей программы на COBOL нужно написать 90 строк, то, конечно же, вас ввели в заблуждение.
Теперь давайте в качестве первого примера разберем эту программу “Hello world”.
Первая строка:
IDENTIFICATION DIVISION.В программах на COBOL всегда есть как минимум идентификационный раздел и процедурный раздел. В идентификационном разделе есть важный абзац, PROGRAM-ID. Здесь вы должны дать программе имя. Это имя не обязательно должно соответствовать имени файла или вообще, чему бы то ни было, кроме того случая, когда ваша программа на COBOL вызывается из другой программы на COBOL. Это делается при помощи глагола CALL, который мы разбирать не будем.
Нам обязательно понадобится ID программы, поэтому добавим
IDENTIFICATION DIVISION.
PROGRAM-ID. HELLO.Есть еще множество вещей, обычно присутствующих в идентификационном разделе. Приведу пару типичных примеров.
IDENTIFICATION DIVISION.
PROGRAM-ID. HELLO.
AUTHOR. CHARLES R MARTIN.
DATE-WRITTEN. 2020-APR-11В современных средах все это – комментарии.
Кстати, если речь зашла о современных средах – COBOL не требует все писать капслоком, как делаю здесь я. GnuCOBOL полностью удовлетворится.
identification division.
program-id. tut2.
author. charlie martin.
procedure division.
display "hello, world".
end program tut2.Просто я немного грущу и ностальгирую.
Не судите строго. Итак, давайте добьем наш “Hello, world.” Та часть программы, в которой выполняется код COBOL, называется процедурным разделом.
IDENTIFICATION DIVISION.
PROGRAM-ID. HELLO.
PROCEDURE DIVISION.
DISPLAY "Hello, world".
END PROGRAM HELLO.Здесь есть еще один отголосок перфокартного формата. Обратите внимание на отступы `DISPLAY “Hello, world”`, здесь четыре столбца. Дело в том, что на отрезке от 8 до 72 на самом деле две части: раздел A, столбцы 8-11 и раздел B, от столбца 12 и далее. Разделы, секции и абзацы должны начинаться в зоне A; утверждения в коде должны начинаться в зоне B.
Расширенный пример на COBOL
Разумеется, по “Hello, World” не составишь качественного впечатления о каком-либо языке, поэтому давайте немного углубимся в COBOL и разберем пример, который хотя бы немного напоминает реальную бизнес-программу. Пример будет самый простой: рассчитаем зарплатную ведомость для работника с почасовой оплатой, с учетом необходимых налогов.
Сделав это, могу признаться, что не так-то это и просто, налоговые таблицы сложны и таинственны. Поэтому примем ставку федерального налога за 16,4 процента, налог штата за 7 процентов, а ставку FICA зафиксируем на уровне 6,2 процента, при этом тщательно выберем ставку оплаты и количество отработанных часов, чтобы не упереться в пороговое значение FICA. Мы учитываем только рабочих, которым оплачивается почасовой труд, а рабочие часы сверх 40 в неделю рассчитываем как переработки и оплачиваем их с коэффициентом 1,5.
Идентификационный раздел здесь повторять незачем. Перейдем к разделу окружения, на его основе собирается интерфейс между программой COBOL и внешним миром.
ENVIRONMENT DIVISION.
INPUT-OUTPUT SECTION.
FILE-CONTROL.
SELECT TIMECARDS
ASSIGN TO "TIMECARDS.DAT"
ORGANIZATION IS LINE SEQUENTIAL.Опять же, мы потренируемся работать с некоторыми аспектами COBOL, которые могут быть удивительны для программиста, не писавшего код в таблично-ориентированном мире обработки данных. В UNIX, Linux, MacOS или Windows запись – это текстовая строка, которая заканчивается некоторым завершающим символом или символами. Для традиционного COBOL это проблема, но компиляторы COBOL реализуют нестандартное расширение, чтобы справиться с этим: ORGANIZATION IS LINE SEQUENTIAL.
В разделе ввода-вывода файлу просто присваивается символьное имя (TIMECARDS), соединяющее его с файлом из внешнего окружения.
Следующая часть программы описывает те данные, с которыми мы работаем. В COBOL обычно предполагается, что все данные будут содержаться в записях фиксированного формата. Структура этих записей иерархическая, отмечается номерами уровней: уровень 01 самый верхний, а дальнейшие подразделы получают более высокие номера. Я использовал 02, 03 и так далее, но это произвольный выбор; мы часто применяли нумерацию 01, 05 и так далее, поскольку так было проще вставлять новые карты, не перепробивая все остальные.
Но теперь введем еще один раздел, который называется раздел данных. Как вы уже, наверное, догадались, он для данных. Здесь используются две секции. Сначала идет файловая секция.
DATA DIVISION.
FILE SECTION.
FD TIMECARDS.
01 TIMECARD.
02 EMPLOYEE-NAME.
03 EMP-FIRSTNAME PIC X(10).
03 EMP-SURNAME PIC X(15).
02 HOURS-WORKED PIC 99V9.
02 PAY-RATE PIC 99. Это наш ввод, который находится в фиксированном формате; строкой FD мы соединяем его с файлом TIMECARDS. Далее идет секция рабочего хранилища. Если вы ранее не работали с COBOL, оно может показаться немного непривычным, но на самом деле я просто объявляю здесь переменные, которые буду далее использовать в программе.
WORKING-STORAGE SECTION.
* временные переменные, используемые при вычислениях
* промежуточные значения для расчета зарплаты с учетом переработок
01 REGULAR-HOURS PIC 9(4)V99 USAGE COMP.
01 OVERTIME-HOURS PIC 9(4)V99 USAGE COMP.
01 OVERTIME-RATE PIC 9(4)V99 USAGE COMP.
01 REGULAR-PAY PIC 9(4)V99 USAGE COMP.
01 OVERTIME-PAY PIC 9(4)V99 USAGE COMP.
* вычисленные элементы зарплатной ведомости
01 GROSS-PAY PIC 9(4)V99 USAGE COMP.
01 FED-TAX PIC 9(4)V99 USAGE COMP.
01 STATE-TAX PIC 9(4)V99 USAGE COMP.
01 FICA-TAX PIC 9(4)V99 USAGE COMP.
01 NET-PAY PIC 9(4)V99 USAGE COMP.Незнакомая часть этого кода – это условие PIC (или PICTURE). COBOL вообще не отличается сильной типизацией. Напротив, как в C, каждое объявление в нем соответствует участку памяти; PIC сообщает COBOL, как интерпретировать этот участок памяти с «картинкой». В данном случае 9(4)v99 говорит COBOL, что упомянутый участок памяти, например, REGULAR-HOURS, должен интерпретироваться как шестизначное число, в котором есть десятичная точка (V), предшествующая двум последним знакам. USAGE COMP приказывает COBOL использовать внутренний формат, приспособленный для быстрых арифметических операций. На самом деле, этот формат довольно гибкий и зависит от архитектуры – то есть, вам самим лучше не зависеть от соблюдения этого формата на всех платформах.
Если хотите быть в этом уверены, не используйте USAGE COMP, что приведет вас к другой части данных – формату вывода. Эти поля используются по умолчанию и выводятся на экран, а USAGE COMP нет.
01 PAYCHECK.
02 PRT-EMPLOYEE-NAME PIC X(25).
02 FILLER PIC X.
02 PRT-HOURS-WORKED PIC 99.9.
02 FILLER PIC X.
02 PRT-PAY-RATE PIC 99.9.
02 PRT-GROSS-PAY PIC $,$$9.99.
02 PRT-FED-TAX PIC $,$$9.99.
02 PRT-STATE-TAX PIC $,$$9.99.
02 PRT-FICA-TAX PIC $,$$9.99.
02 FILLER PIC X(5).
02 PRT-NET-PAY PIC $*,**9.99.Здесь по-настоящему интересно лишь то, что у нас появилось несколько новых форматов PIC: у $,$$9.99 есть ведущий символ доллара, всегда предшествующий самой левой цифре, а также $*,**9.99, служащие заполнителем между знаком доллара и первыми цифрами.
Скоро покажу всю программу, но сначала хочу продемонстрировать, как в COBOL делается математика, например, в COMPUTE-GROSS-PAY:
COMPUTE-GROSS-PAY.
IF HOURS-WORKED > 40 THEN
MULTIPLY PAY-RATE BY 1.5 GIVING OVERTIME-RATE
MOVE 40 TO REGULAR-HOURS
SUBTRACT 40 FROM HOURS-WORKED GIVING OVERTIME-HOURS
MULTIPLY REGULAR-HOURS BY PAY-RATE GIVING REGULAR-PAY
MULTIPLY OVERTIME-HOURS BY OVERTIME-RATE
GIVING OVERTIME-PAY
ADD REGULAR-PAY TO OVERTIME-PAY GIVING GROSS-PAY
ELSE
MULTIPLY HOURS-WORKED BY PAY-RATE GIVING GROSS-PAY
END-IFДа, в стандартном COBOL нужно все проговаривать.
А теперь вся программа целиком.
IDENTIFICATION DIVISION.
PROGRAM-ID. PAYCHECKS.
AUTHOR. CHARLES R. MARTIN.
DATE-WRITTEN. 2020-APR-15.
ENVIRONMENT DIVISION.
INPUT-OUTPUT SECTION.
FILE-CONTROL.
SELECT TIMECARDS
ASSIGN TO "TIMECARDS.DAT"
ORGANIZATION IS LINE SEQUENTIAL.
DATA DIVISION.
FILE SECTION.
FD TIMECARDS.
01 TIMECARD.
02 EMPLOYEE-NAME.
03 EMP-FIRSTNAME PIC X(10).
03 EMP-SURNAME PIC X(15).
02 HOURS-WORKED PIC 99V9.
02 PAY-RATE PIC 99.
WORKING-STORAGE SECTION.
* временные переменные, используемые при вычислениях
* промежуточные значения для расчета зарплаты с учетом переработок
01 REGULAR-HOURS PIC 9(4)V99 USAGE COMP.
01 OVERTIME-HOURS PIC 9(4)V99 USAGE COMP.
01 OVERTIME-RATE PIC 9(4)V99 USAGE COMP.
01 REGULAR-PAY PIC 9(4)V99 USAGE COMP.
01 OVERTIME-PAY PIC 9(4)V99 USAGE COMP.
* вычисленные части зарплатной ведомости
01 GROSS-PAY PIC 9(4)V99 USAGE COMP.
01 FED-TAX PIC 9(4)V99 USAGE COMP.
01 STATE-TAX PIC 9(4)V99 USAGE COMP.
01 FICA-TAX PIC 9(4)V99 USAGE COMP.
01 NET-PAY PIC 9(4)V99 USAGE COMP.
* print format of the check
01 PAYCHECK.
02 PRT-EMPLOYEE-NAME PIC X(25).
02 FILLER PIC X.
02 PRT-HOURS-WORKED PIC 99.9.
02 FILLER PIC X.
02 PRT-PAY-RATE PIC 99.9.
02 PRT-GROSS-PAY PIC $,$$9.99.
02 PRT-FED-TAX PIC $,$$9.99.
02 PRT-STATE-TAX PIC $,$$9.99.
02 PRT-FICA-TAX PIC $,$$9.99.
02 FILLER PIC X(5).
02 PRT-NET-PAY PIC $*,**9.99.
* Tax rates -- 77 level aha！
77 Fed-tax-rate Pic V999 Value Is .164 .
77 State-tax-rate Pic V999 Value Is .070 .
77 Fica-tax-rate Pic V999 Value Is .062 .
* 88 уровень – для условий
01 END-FILE PIC X.
88 EOF VALUE "T".
PROCEDURE DIVISION.
BEGIN.
PERFORM INITIALIZE-PROGRAM.
PERFORM PROCESS-LINE WITH TEST BEFORE UNTIL EOF
PERFORM CLEAN-UP.
STOP RUN.
INITIALIZE-PROGRAM.
OPEN INPUT TIMECARDS.
PROCESS-LINE.
READ TIMECARDS INTO TIMECARD
AT END MOVE "T" TO END-FILE.
IF NOT EOF THEN
PERFORM COMPUTE-GROSS-PAY
PERFORM COMPUTE-FED-TAX
PERFORM COMPUTE-STATE-TAX
PERFORM COMPUTE-FICA
PERFORM COMPUTE-NET-PAY
PERFORM PRINT-CHECK
END-IF.
COMPUTE-GROSS-PAY.
IF HOURS-WORKED > 40 THEN
MULTIPLY PAY-RATE BY 1.5 GIVING OVERTIME-RATE
MOVE 40 TO REGULAR-HOURS
SUBTRACT 40 FROM HOURS-WORKED GIVING OVERTIME-HOURS
MULTIPLY REGULAR-HOURS BY PAY-RATE GIVING REGULAR-PAY
MULTIPLY OVERTIME-HOURS BY OVERTIME-RATE
GIVING OVERTIME-PAY
ADD REGULAR-PAY TO OVERTIME-PAY GIVING GROSS-PAY
ELSE
MULTIPLY HOURS-WORKED BY PAY-RATE GIVING GROSS-PAY
END-IF
.
COMPUTE-FED-TAX.
MULTIPLY GROSS-PAY BY FED-TAX-RATE GIVING FED-TAX
.
COMPUTE-STATE-TAX.
* Compute lets us use a more familiar syntax
COMPUTE STATE-TAX = GROSS-PAY * STATE-TAX-RATE
.
COMPUTE-FICA.
MULTIPLY GROSS-PAY BY FICA-TAX-RATE GIVING FICA-TAX
.
COMPUTE-NET-PAY.
SUBTRACT FED-TAX STATE-TAX FICA-TAX FROM GROSS-PAY
GIVING NET-PAY
.
PRINT-CHECK.
MOVE EMPLOYEE-NAME TO PRT-EMPLOYEE-NAME
MOVE HOURS-WORKED TO PRT-HOURS-WORKED
MOVE PAY-RATE TO PRT-PAY-RATE
MOVE GROSS-PAY TO PRT-GROSS-PAY
MOVE FED-TAX TO PRT-FED-TAX
MOVE STATE-TAX TO PRT-STATE-TAX
MOVE FICA-TAX TO PRT-FICA-TAX
MOVE NET-PAY TO PRT-NET-PAY
DISPLAY PAYCHECK
.
CLEAN-UP.
CLOSE TIMECARDS.
END PROGRAM PAYCHECKS.Вот файл с данными:
Charlie Martin 41015
Terry Lacy 32007А вот вывод:
$ cobc -x paycheck.cob
$ ./paycheck
Charlie Martin 41.0 15.0 $622.50 $102.09 $43.57 $38.59 $**438.25
Terry Lacy 32.0 07.0 $224.00 $36.73 $15.68 $13.88 $**157.71
$Где учить COBOL
На самом деле, есть немало курсов и книг по COBOL.
Я купил и проработал этот курс Udemy, он весьма хорош. А среди электронных книг для Kindle мне нравится Beginning COBOL for Programmers Майкла Кафлана. На YouTube уйма видео, из которого я посмотрел лишь некоторые. Вот это кажется хорошим, но, если поискать по COBOL, можно найти гораздо больше.
Конечно, на подходе и новые материалы. IBM и Open Mainframe Project анонсировали совместный проект, призванный объединить специалистов с навыками COBOL и учить программированию на этом языке. Здесь есть несколько ресурсов, в частности, новостная площадка для COBOL-программистов, желающих вернуться к делам, а также первые наработки опенсорсного курса по COBOL.
Почему у COBOL дурная слава
Как понятно из этого небольшого примера, COBOL не слишком похож на привычные языки программирования. На COBOL не напишешь ни компилятор, ни модуль ядра, да и синтаксис – явно не такой, как вы ожидали увидеть. Но давайте сравним его с другим распространенным предметно-ориентированным языком: SQL. Там синтаксис также довольно причудлив, а семантика определяется реляционным исчислением.
“Программируя на мейнфрейме, можно подсмотреть, как раньше делался софт,” – говорит Себальос. — “С ним современный программист словно открывает капсулу времени. Многие черты COBOL кажутся весьма кустарными по сравнению с современными приемами DEVOPS и автоматизации.”
Комментарии (87)
Feedman
25.10.2021 13:35+4Шо, опять???
kaljan
25.10.2021 16:02+3Да, каждые 4 года)
funca
25.10.2021 19:22+7Каждые полтора - оригинальная статья вышла в марте прошлого года.
Интересно, какой смысл переводить чужие легаси статьи про чужие легаси проблемы в непопулярных легаси языках?
prokoudine
25.10.2021 22:08+2То-то я смотрю текст местами чужеродно смотрится, конструкции какие-то нерусские.
PereslavlFoto
25.10.2021 22:20+1Трафик!!! У-у-у-х-х-х!!!
14 тысяч просмотров!!!
nochkin
26.10.2021 05:09+1Из этих просмотров примерно половина -- это боты, написанный на COBOL. Потому не в счёт.
forthuser
25.10.2021 13:35+2Примеры решённых задач на Cobol для его «освежения» на ресурсе.
http://rosettacode.org/wiki/Category:COBOL
P.S. Как понимаю, что для России это не так актуальная тема Cobol «страданий»?orthoxerox
25.10.2021 14:48+8Да, COBOL нас почти не задел. Зато в России есть Delphi. И RPG во многих крупных банках. И 1С.
balamutang
25.10.2021 16:20+2Ну с 1С то проблем нет, он сам рефакторится вместе с версиями, ЯП в 1С6.0 был совсем не такой как в 1С7.0 и тд. Поколения программистов уходят реже чем версии 1С
nochkin
26.10.2021 05:12Кстати, видел как в одной крупной штатовской конторе попался старый проект на Dephi. Никто не знал, что это такое и что с этим делать.
Про Pascal знали немного по-наслышке, а вот про Delphi ничего.
Ради прикола попытался узнать историю проекта, но никакой информации не нарыл. Видимо, какой-то свежий русский программист решил так "пошутить".
alan008
27.10.2021 09:08А ничего, что сам Delphi как раз в Штатах и разрабатывается. Причем каждый год новые версии выходят, вполне современные. Вот недавно компиляцию под процессор Apple M1 для MacOS запилили.
nochkin
27.10.2021 19:32Как видно выше, место разработки мало влияет на популярность. А если взять определённую область (например, финансы), так там ещё другие критерие накладываются, которые не будут способствовать популяризации.
Есть много других языков и проектов, которые начали свой путь совсем не в штатах, но сегодня в штатах они популярны или минимально о них знают во многих индустриях.
alan008
28.10.2021 00:06Согласен. Но что супер-популярно сейчас не факт что будет супер-популярно через 5-10 лет. А такие инструменты как Delphi живут десятками лет. Хотя конечно в этом скорее заслуга Windows — он жив и Delphi жив. Помрет Windows, скорее всего помрет и Delphi. Понятно, что сейчас под винду больше на C# пишут, но и на Delphi остаются проекты, в т.ч. крупные.
nochkin
28.10.2021 00:16По поводу популярности и 10 лет, то это 100% именно так, совершенно верно.
Delphi живой, но не везде. Потому я и заметил, что в некоторых сферах он не только не живой, но о нём даже никто ничего не знает. В тех же финансах (а это ведь достаточно древняя сфера) его нет, там прочно сидят другие инструменты, которых не мало.
По поводу крупных проектов: что бы далеко не ходить, то крупные проекты есть и на COBOL'е, но только это не идёт ему в плюс сегодня. Начинать новый большой проект на COBOL'е сегодня -- мягко говоря, будет не очень разумным решением.
P.S.: кстати, тот проект на Delphi я предложил взять только для того, что бы портировать его на что-то другое. Народ даже согласился, но потом его просто свернули, так как нашли более удобные альтернативы.
WASD1
25.10.2021 14:29Понятно почему банки готовы платить `компенсация х2` * `работники х2` -- "лишь бы всё не упало"
Но совсем непонятнО: почему не перенесут всё то же самое на человеческий стек (ну хотя бы в "кобол-нитерпретатор") в перспективе пары лет?orthoxerox
25.10.2021 14:58+5Потому что там реально тысячи человеко-лет кода, причём махровейшей бизнес-логики.
Перенести её куда-либо один-к-одному, написав волшебный конвертер - вы получите тот же Кобол, только написанный на Яве, то есть потеряете все преимущества, сохранив все недостатки.
Переписать с нуля? Аналитики, которые могут объяснить исходную задачу, уже на пенсии или в могиле, нужно воспитывать новых и учить их Коболу. Нужно нанимать целую команду, которая будет переписывать код несколько лет, потом тестировать его, потом мигрировать на него, а что в итоге? Тот же функционал, что и пять лет назад.
На коболе остались в основном глубоко бэк-офисные процессы, которые меняются довольно медленно. Пока лучше платить двум седовласым гуру Кобола и одному падавану двойную ставку каждый год, чем нанимать двадцать человек на переписывание.
eyudkin
25.10.2021 15:46+6Но в итоге это приведёт к тому, что эти седовласые гуру умрут, а для новых поколений разработчиков кобол станет ещё менее предпочтительным вариантом, потому что прочие ЯПы сделают ещё один шажок вперёд.
Вся эта история имхо об опасности подхода "работает - не трогай" и том, что рефакторинг должен быть постоянным, а система должна постоянно освежаться и модернизироватся.
Потому что иначе очень быстро система становится волшебной, а любые манипуляции с ней - опасными и сверхдорогими.
inkelyad
25.10.2021 17:05+6Вся эта история имхо об опасности подхода "работает — не трогай"
Это история про то что черные ящики надо научиться документировать. Хорошо документировать. Чтобы вот буквально рядом с ящиком стоял (толстенный) учебник, который можно прочитать и понять, где там что тыкать и крутить надо в случае чего.
А не "лучшая документация — это код"
olku
25.10.2021 23:16+2Это, жадность IBM и специфические исторические знания о системной архитектуре конкретных компаний. Сам язык прост как валенок. Впрочем, такой же универсальный.
nochkin
26.10.2021 05:15Так документация часто даже есть. Только это руководство пользователя, а не для разработчика. Как раз то, что надо было для бизнеса того времени и не более. Ведь писать дополнительную документацию по коду -- это дополнительные деньги, которые налогоплательщики давать не хотят.
victor_1212
25.10.2021 18:55>Но в итоге это приведёт к тому, что эти седовласые гуру умрут, а для новых поколений разработчиков кобол станет ещё менее предпочтительным вариантом
>Это история про то что черные ящики надо научиться документировать. Хорошо документировать.
большинство "седовласых гуру" уже того, типа сверху с интересом наблюдает за происходящим, про то "как должно быть" хорошо рассуждать, когда время для рассуждений имеется, что в общем в бизнесе редкость, ну и реакция современной индустрии как всегда прямолинейная - нужен программист-ассенизатор (cobol specialist) весьма востребованная категория, как кстати и обычные janitor, что будет в будущем - на это просто воображения не хватает
ps
проблема касается не только cobol'a конечно
funca
25.10.2021 19:40+5COBOL это "клей" с синтаксисом, близком к английскому языку (чтобы даже бизнес аналитик мог понять). Сходить в базу данных или файлы, отпроцессить ответ по шаблону и выплюнуть наружу XML (или ещё какой формат) - в коболе это эссе в несколько человекочитаемых строчек. На Java за это время вы успеваете только открыть IDE и быть может нагенерить кучу невнятного boilerplate кода (с ООП, классами и тому подобной, не относящиеся к делу, ерундой). Насколько я понимаю, затее переписать на Java там столько же лет, сколько самой java. Но чисто с технологической точки зрения это не даёт ни каких плюшек.
olku
25.10.2021 23:19Миграция с мейнфреймов существует как бизнес лет 40. Все есть, и даже в облаках. Язык не причём.
PereslavlFoto
25.10.2021 15:03+5Удивительно, как разные авторы приглашают Дейкстру сказать, что самые разные языки «калечили ум»!
barbaris76
28.10.2021 00:18Вот да, сам хотел написать, что точно помню, как Дейкстра писал (с чужих слов, конечно), что сажать нужно за бейсик :))
belch84
25.10.2021 15:44+2Интересно, какой современный (или относительно «свежий») язык проживет столько же, сколько прожил COBOL?
ZiggiPop
25.10.2021 21:51+1Уже есть такой, Lisp (с диалектами). Постарше COBOL будет(на один год), и живее всех живых при этом. Да, не в первой десятке по популярности, но и не исчезающее количество актуальных проектов на нем, даже если не брать всякие Clojure, Scheme и прочие Racket.
belch84
25.10.2021 22:18Если внимательно прочитать мой вопрос, то станет ясно, что Lisp в качестве варианта ответа не подходит, ибо, при всех его достоинствах, он не является ни современным, ни «свежим». FORTRAN тоже живет очень долго (по крайней мере, во всевозможных библиотеках численных методов), но он тоже не совсем свеж, и его справедливо критиковали за примитивность и провоцирование ошибок. Тем не менее, на этих древних языках написана уйма ПО, и очень хочется знать, найдется ли среди новых языков, свободных от недостатков COBOLа и FORTRANа такие, которые проживут столько же или дольше? Я подозреваю, что нет
ZiggiPop
27.10.2021 17:17>то станет ясно, что Lisp в качестве варианта ответа не подходит, ибо, при всех его достоинствах, он не является ни современным, ни «свежим».
То-то «несвежее» и несовременное функциональное программирование тянут во все «современные» императивные ЯП! Не хватает, видимо, стариковского духа.
azTotMD
25.10.2021 22:21Согласно википедии фортран появился раньше. И до сих пор используется, на нем даже относительно свежие программы пишут
belch84
25.10.2021 22:24Я наверное, как-то неясно выразился, повторю, я задавал вопрос не о ровесниках COBOLа, а о языках, которые появились относительно недавно
rjhdby
26.10.2021 14:32Мне кажется у Rust'а есть перспективы, раз уж его в ядро линукса уже готовы(?) принимать
tchkEn
25.10.2021 17:32+2Вообще COBOL вещь интересная и не однозначная. АБС написанные на данном языке, с одной стороны, трудны в освоении, могут пугать отсутствием привычного пользователям GUI из-за чего может возникнуть множество серьёзных ошибок. При этом, с другой стороны, они обладают гибкостью и надёжностью, а опытный пользователь способен работать с ними на очень быстро и эффективно.
Exchan-ge
25.10.2021 19:26+41988 год.
В нашем ВЦ за терминалом сидит группа бухгалтеров.
Их учат Коболу.
Я сижу в стороне и до меня долетают отдельные фразы.
Казалось, они проходят мимо моего сознания. Но вот начал читать эту статью и сразу уловил что-то знакомое, забытое, из давнего-давнего прошлого :)
phikus
26.10.2021 11:04до меня долетают отдельные фразы
Зинаида Петровна, а вы бы пошли сеньором за сотку?
third112
26.10.2021 00:20у разработчика-одиночки нет денег, чтобы взять в аренду мейнфрейм
ИМХО сейчас это не проблема — в сетке можно найти много эмуляторов на ПК. "IBM 370" покажет бешенную скорость.
Koval97
26.10.2021 08:58+1Какой там популярный?! Одно старое дряхлое ведомство, столкнувшись с "внезапным" из-за пандемии резким ростом обращений за пособием по безработице, не может обработать 3,6 млн обращений в месяц, что любой современный сервер делает за минуту. И вместо того, чтобы обновить парк и приобрести любой современный CRM из тысяч вариантов на рынке, они только и делают что распространяют сказки про мёртвый язык программирования в тшетной надежде, что найдётся некромант, который магическим образом в несколько раз ускорит им обработку таблиц. Интернет помнит всё, и особенно новостные заголовки!
zantor
26.10.2021 09:43Емнип, об этом уже писали. Тормоза были к каком-то из middleware, коих за это время, очевидно, было написано овер 9000, вполне вероятно, что и как раз на чем-то модном и молодежном :)
CrushBy
26.10.2021 09:14Мы сталкивались с той же самой проблемой. Даже отдельную статью писали для этого.
Другое дело, что предметный бизнес-ориентированный язык должен быть простым для освоения. Одна из его задач должна быть в том, чтобы можно было легко ему научить человека из бизнеса.
То есть проблема должна решаться относительно легко (именно так мы ее и решали) :
Ищете человека из бизнеса с техническо-аналитическим складом ума.
Даете ему больше денег (выше рынка). Если не находите, то даете еще больше. Теорема : рано или поздно найдется.
Быстро обучаете его этому высокоуровневому языку (если человек способный, а язык нормальный, то на это уйдет максимум месяц).
PROFIT !!!
Конечно, правильный вариант - это переписать это все нафиг на нормальные современные технологии. Но если уж заранее не сделали, то тут, как говорится, "desperate times call for desperate measures".
ksbes
26.10.2021 09:26+1Другое дело, что предметный бизнес-ориентированный язык должен быть простым для освоения. Одна из его задач должна быть в том, чтобы можно было легко ему научить человека из бизнеса.
Давайте горшки будет делать гончар, а сапоги сапожник. Программы писать должны IT специалисты (весь стэк), а люди из бизнеса - должны заниматься бизнесом. Если обычного и специализированного естественных языков для общения и согласования не хватает - есть тот же ГОСТ, UML и проч.
Действительно работающий COBOL не всякий программист прочтёт, не то что бизнес аналитик. Тут та же история что с SQL, когда хотели сделать "язык для бхгалтеров". В простых, учебных примерах - бухгалтера вполне себе понимали. Но запрос, который реально работает на практике сейчас и программист предпочитает не смотреть, а абстрагироваться через ORM
CrushBy
26.10.2021 09:54+1Программы писать должны IT специалисты (весь стэк), а люди из бизнеса - должны заниматься бизнесом
А люди, которые пишут макросы в Excel - это кто ? А 1Совцы ? Чем программист принципиально отличается от не программиста ? Тем, что он может алгоритмы/архитектуры описывать на плоском языке, а не в виде схем/диаграмм ?
Давайте горшки будет делать гончар, а сапоги сапожник.
По такой логике, можно начать гнобить и Full Stack Developer. Типа "пусть фронтендом занимаются фронтендеры, бэкендом - бэкендоры, а базой - разработчики БД". Да, есть случаи, когда это имеет смысл. Но есть случаи, когда и не имеет.
Действительно работающий COBOL не всякий программист прочтёт, не то что бизнес аналитик
Если бизнес-аналитика обучить языку, на котором читать, то он может читать и получше программиста, если там декларативная, а не императивная логика.
bbc_69
26.10.2021 13:38Чем программист принципиально отличается от не программиста ? Тем, что он может алгоритмы/архитектуры описывать на плоском языке, а не в виде схем/диаграмм ?
Да, ровно этим. И да, программирование - отдельная проффесия.
По такой логике, можно начать гнобить и Full Stack Developer. Типа "пусть фронтендом занимаются фронтендеры, бэкендом - бэкендоры, а базой - разработчики БД".
Вполне обоснованная претензия, между прочим. В более или менее сложных проектах фронт и бек неизбежно разбегаются ибо везде свои тонкости.
Если бизнес-аналитика обучить языку, на котором читать, то он может читать и получше программиста, если там декларативная, а не императивная логика.
Пусть читает, кто ж против. Только поддерживать всё это нужен всё равно программист. Которого искать всё труднее становится. Такие дела.
В общем, ораторы выше поддерживаю полностью.
CrushBy
26.10.2021 14:54+1Да, ровно этим. И да, программирование - отдельная проффесия.
То есть достаточно для того-же Java кода построить возможность задавать его визуально в виде стрелочек и формочек, и тогда это перестанет быть программированием, и будет другой профессией ? А оно станет по такой логике гораздо проще ?
Вполне обоснованная претензия, между прочим. В более или менее сложных проектах фронт и бек неизбежно разбегаются ибо везде свои тонкости.
Да, во многих проектах разделение оправдано. Тем не менее профессия Full Stack Developer'ов существует и достаточно востребована. Значит и в ней есть смысл.
Пусть читает, кто ж против. Только поддерживать всё это нужен всё равно программист. Которого искать всё труднее становится. Такие дела.
Зачем нужен программист ? Например, у нас прекрасно разрабатывают сложные системы люди, которые никогда не были программистами. При этом ни к каким программистам не обращаются. Что мы делаем не так ?
bbc_69
26.10.2021 17:52То есть достаточно для того-же Java кода построить возможность задавать его визуально в виде стрелочек и формочек, и тогда это перестанет быть программированием, и будет другой профессией ? А оно станет по такой логике гораздо проще ?
Может я как-то плохо выразился. Не надо воспринимать технических специалистов, как программистов графиками. У программистов склад ума отличается. И идея сделать "понятный менеджеру" язык программирования обречена на провал. Пример - SQL.
Тем не менее профессия Full Stack Developer'ов существует и достаточно востребована.
Я имел в виду то, что идея гнать на фулл стек имеет под собой основания и не является чем-то немыслимым. Естественно, всё зависит от конкретной ситуации.
Зачем нужен программист ? ... Что мы делаем не так ?
Ну, это была шпилька на тему основной идеи статьи. Если Кобол такой понятный техническим специалистам, то почему бы им самим не сделать всё что надо? Зачем для это искать программиста да ещё и за 100500 денег?
Что касается Ваших знакомых/коллег, то скорее всего у них изначально есть способности к программированию. Либо сложность системы несколько преувеличена. Без данных сложно сказать что-то определённое.
CrushBy
26.10.2021 20:54Не надо воспринимать технических специалистов, как программистов графиками. У программистов склад ума отличается
А что если есть человек, у которого склад ума такой же, как у программиста, но он сейчас работает не программистом, а менеджером/учителем/аналитиком/трейдером/бухгалтером/администратором и т.д. ? Он тогда кто по-Вашему ? Программист или нет ? Или должна быть категория "потенциальный программист" ?
Что касается Ваших знакомых/коллег, то скорее всего у них изначально есть способности к программированию
Так я про это и говорю. Есть много людей с достаточно развитым аналитическим мышлением, которые просто не являются программистами. При этом они могут на хорошем уровне, например, освоить SQL, но не могут (или не хотят) управлять памятью и многопоточностью в C++ или хотя бы в Java. Их можно тогда задействовать в разработке на том же COBOL - нужно лишь их мотивировать. Самый простой вариант - деньгами.
Exchan-ge
26.10.2021 23:41А что если есть человек, у которого склад ума такой же, как у программиста, но он сейчас работает не программистом, а менеджером/учителем/аналитиком/трейдером/бухгалтером/администратором и т.д. ?
Кстати, в 70х в нашей школе факультативно проходили курс программирования (на Алголе и Фортране).
И были среди нас отличники, которые сейчас работают менеджерами, инженерами и врачами (хотя возраст уже вполне пенсионный). Есть даже один историк :)
Программистами они не стали по причине низкого спроса на эту профессию в то время, когда и ЕС ЭВМ были новинкой.
bbc_69
27.10.2021 08:15Тем не менее, это противоречит тому, что написано в топике: предпочитают искать готовых программистов, а не переучивать технических специалистов. Я не сторонник считать, что они все там дураки и ничего не понимают. А значит в этом есть смысл.
Ну и был у меня коллега с достаточно развитым аналитическим мышлением. Так перешёл в программисты. Так что да, считаю таких людей потенциальными программистами, особенно у нас.
forthuser
26.10.2021 18:11То есть достаточно для того-же Java кода построить возможность задавать его визуально в виде стрелочек и формочек, и тогда это перестанет быть программированием, и будет другой профессией? А оно станет по такой логике гораздо проще ?
Этот подход реализован в HiAsm
в разных пакетах для его применения в поддерживаемых языках (к примеру и C#)
P.S. Да, этот подход ближе к «строительству» программ, в отличии от классики программирования.CrushBy
26.10.2021 21:01Мой тезис в том, что важен не способ задания программы (визуально, или в виде кода). Важна архитектура/парадигма той платформы, в которой создается эта программа.
Например, языки в Java и C# немного отличаются, но платформы - похожи. А в Java и C++ языки похожи, но принцип разработки отличаются гораздо сильнее.
И визуальное программирование требует значительно более высокого уровня абстрагирования, и, соответственно, другой платформы. А мышкой это делается в графике, или кодом - это не столь принципиально.
ldss
26.10.2021 19:01да нафиг он нужен, этот кобол
вот реально, потерять год-два на.. что? Научишься чему-то новому и востребованному? Поднимешь какие-то скиллы до нужного уровня? Это ж болото и тупик, деградация себя как торговца своей рабочей силой на рынке
Egoryi
26.10.2021 19:41+1В 1978 году на COBOL в виде развлечения я написал не экономическую программу (бизнес тогда был под запретом в СССР), а программу "Автооператор", которая управляла потоком заданий на перфокартах. Программу эту даже купили.
SpiderEkb
27.10.2021 11:04+4Ох... "Эта музыка будет вечной..." (с)
COBOL разрабатывался как очень специализированный язык для вполне конкретных приложений. Равно как FORTRAN изначально разрабатывался для расчетов математических
Кстати, были времена когда под коммерческие вычисления делались специальные модификации RISC процессоров - C-RISC — «Commercial-RISC».
И в сове области COBOL был хорош. Он давал очень быстрый и эффективный код. И именно поэтому на нем столько написано именно в области коммерческих приложений. И он до сих пор остается быстрым и эффективным, что бы там ни говорили.
Тот случай с системами занятости, который так любят мусолить, на самом деле к COBOL не относится:
В первые дни Covid-19 предприятия массово закрывались. Уволенные работники кинулись в Интернет, чтобы подать заявление на получение пособия по безработице, а веб-сайты правительств многих штатов рухнули под нагрузкой. В Нью-Джерси губернатор заявил прессе, что их системы COBOL отчаянно нуждаются в помощи, чтобы справиться с новыми требованиями. «Буквально, у нас есть системы, которым более 40 лет», — отметил он.
Но технологи, работавшие за кулисами над устранением проблем, знали, что проблема не в COBOL, вычисляющем цифры. Это старое оборудование работало нормально. Нет, сбой произошел в более новых вещах — программах, обеспечивающих работу самого веб-сайта.
«То, что вышло из строя, было веб-приложением между мэйнфреймом и внешним миром. Именно оно и развалилось», — говорит Марианна Беллотти, программист и писательница, которая много лет работала с правительственными системами и наблюдала за работой системы Нью-Джерси. Но признать, что «о, наши веб-системы сломались», слишком стыдно, как отмечает историк Хикс.
Беллотти видела, как то же самое происходило с другими государственными учреждениями, например, с налоговой службой. Однажды ее позвали помочь с веб-приложением Налогового управления, которое не работало. Когда они провели расследование, то обнаружили, что, действительно, проблема была в более новых программах, «в этом куске плохо написанного кода на Java». Мейнфрейм, работающий на COBOL, напротив, мчался как Ferrari.
«Мейнфреймы, — говорит она, — реагировали в течение миллисекунд».
https://habr.com/ru/company/itelma/blog/577736/
Дело в том, что такие системы многослойны. Есть мейнфрейм, где хранятся все данные и реализуется вся логика, есть фронт-системы, реализующие пользовательский интерфейс и всякие модные и креативный фичи и есть middle слои, реализующие API для фронта, которые преобразуются в запросы к мейнфрейму (который может быть вообще изолирован от внешнего мира - общение с ним идет через шину или очереди). Фронты и middle реализуются на современных стеках, но там нет ни работы с данными, ни какой-то серьезной логики.
Проблема COBOL не столько проблема самого языка, сколько окружения в котором он работает - чтобы писать эффективный код на таком уровне, надо понимать как все это работает в целом (там реально может быть очень много тонкостей - сам пишу, хоть не COBOL, RPG под IBM i - очень много чисто системных особенностей, которые сильно влияют, порой можно буквально на порядок снизить потребление процессорных ресурсов и повысить скорость просто используя особенности системы).
Тут возникает второй вопрос - умирают мейнфреймы или нет. На эту тему периодически возникают разные обзоры. Например: https://idcdocserv.com/US46775720
Общий вывод - нет. Не умирают. Область их использования достаточно локализована и специфична, но жить они будут еще достаточно долго и вполне себе развиваются и поддерживаются. Эти системы проектировались для одновременного выполнения множества процессов (заданий). Например, та же IBM i (AS/400) спроектирована так, что накладные расходы на переключение контекста процессов там существенно ниже, нежели в Win и *NIX системах. Что в целом повышает общую производительность именно в многопроцессной работе (например, при использовании систем, построенных на модели акторов).
Аренда мейнфрема, конечно, дорого, но есть эмуляторы (насколько близко к реальност они эмулируют второй вопрос), есть публичные сервера - тот же PUB400 (публичный IBM i сервер с бесплатной регистрацией, 2 библиотеки, 300Гб дискового пространства. Там есть C/C++, CL, RPG, COBOL). В целом особых проблем с обучением нет.
Переход с COBOL на "современный стек" неоправдан. В силу огромного количества эффективно работающего, отлаженного кода. Причем, в очень сложных системах где огромное количество таблиц, программных модулей, одновременно работающих тесно интегрированных между собой процессов. Перевести все это на новый стек, не потеряв эффективности и сохранив функциональность та еще работа (с учетом вникания в бизнес-логику, переписывания огромного количества кода и огромного количества ретестов). Причем, результат не факт что будет лучше - "новый" стек может точно также устареть через 10-15 лет.
Из известных попыток крупная пожалуй только одна. Банк Содружества Австралии и Океании. Переписали старый код на новый стек. Заняло у них это 5 лет (2012-1017гг) и обошлось в $750млн. Плюс некоторое количество сбоев в процессе перехода (самый известный - внезапное обнуление кредиторской задолженности всех клиентов - поправили, восстановили, но это тоже затраты сил и времени). Других желающих не нашлось.
Такие предложения идут чаще от молодых-проактивных, привыкших работать с модными фреймворками, но совершенно не имеющих опыта в работе с такими системами на уровне их ядра. Для тех же, кто со всем этим работает, "легаси" воспринимается как надежный, эффективный, достоверно работающий код, который не надо лишний раз трогать.
В целом, COBOL как-то продолжал развиваться, по крайней мере до 2014-го года. Даже были какие-то попытки внести туда ООП. Но в настоящее время не слышал чтобы на нем разрабатывалось что-то новое (хотя в той же IBM i он поддерживается на уровне системы).
Сейчас вместо него используется RPG (по крайней мере на платформах IBM). Который хоть и вырос из бланков и перфокарт (RPG Fixed Style - ранние версии), но в настоящее время очень сильно модифицирован (Free Style без необходимости позиционирования) до нормального процедурного языка, умеющего работать с указателями, динамическим выделением памяти и т.п. При этом в нем присутвует все, что необходимо для коммерческих расчетов - типы данных с фиксированной точкой, мощные средства работы со строками, возможность работы с таблицами и индексами напрямую (что не исключает использование SQL где это необходимо - SQL операторы могут встраиваться непосредственно в RPG код). И при этом получается весьма эффективный код.
Есть определенные сложности при работе с многопоточными приложениями. Но это уже скорее специфика области применения - в job isolated многозадачных системах, требующих постоянного сопровождения, предпочитают распараллеливать обработку большого количества данных на несколько заданий, но не потоков. Так проще для сопровождения т.к. если в потоке что-то пошло не так, останавливать придется всю задачу целиком (да и диагностировать такую ситуацию сложнее). Задание же полностью изолировано. В случае критического исключения оно просто переходит в соответствующий статус, который сразу виден сопровождению, не затрагивая другие задания (т.е. если у нас есть 1 головное задание, собирающее данные для обработки и раздающее их обработчикам + несколько заданий-обработчиков, то падение одного из обработчиков никак не скажется на всех остальных во-первых, во-вторых, сразу будет обнаружено и диагностировано сопровождением).
В общем, как-то много получилось... Но вопрос COBOL это не вопрос синтаксиса или возможностей, но вопрос очень комплексный - задачи, окружение, требования к надежности, эффективности, сопровождаемости. И пока старый код с этим задачами справляется, никто, кто умеет считать деньги, просто так, ради какой-то "концептуальности", ничего переделывать не будет. Слишком дорого и сложно.
Что же касается высказываний "я этим заниматься не буду - это не даст мне ничего, что я потом смогу применить где-то еще" - ну это просто личное мнение. Спрос на разработчиков в таких областях не так высок. Но он есть и достаточно стабилен (если судить по соответствующим группам в том же LinkedIn). Правда, там достаточно замкнутое сообщество и очень много вакансий закрывается без публикации, просто через знакомых и знакомых знакомых человек переходит с одного места на другое. И те, кто туда сознательно попадают (а молодежь приходит), обычно остаются на всю жизнь. Просто потому что что-то в этом для себя находят. И не только деньги.
lasalas
"Не хотите ли поесть говна, по старой памяти? Но теперь за большие деньги!"
BTW, SQL основан не на реляционной алгебре, а на реляционном исчислении.
Sivchenko_translate Автор
Благодарю вас, поправил.
dimkrayan
как то за не особо большие деньги. Я вот сейчас вбил слово cobol на indeed.com - максимум, что я увидел (смотрел просто глазами, так что как статистику это не стоит рассматривать) - 220к в год, в среднем - порядка 120 что для США - ну явно не много. Есть несколько друзей там - сеньоры на современных языках - и у них зп значительно больше.
И вот меня все удивляло это: ну вряд ли кобол прям такой сложный, вряд ли не нашлось ни одного java сеньора, который за х2 к зарплате не осилил бы кобол. Но похоже, что они, конечно, ищут, умоляют, "но вы там держитесь".
Kanut
Как бы у нас с Cobol'ом прикол в том что он востребован, а людей нет. А те кто есть, в основной своей массе уходят на самозанятость и поэтому в статистике зарплат не особо-то и видны. Но при этом зарабатывают они спокойно в полтора-два раз больше тех кто пишет на "популярных" языках.
Другое дело что вся эта возня с легаси(то есть не только Cobol, но и ряд других языков) дело очень мутное и нервное. И в принципе мало кто хочет с таким связываться. Даже с учётом больших зарплат.
dimkrayan
А где все эти вакансии? И в полтора-два раза больше - это сколько?
Просто, я не в первый раз интересуюсь.
Пару лет назад я думал как раз поступить, вроде "Ну, какая разница, на чем легаси из пустого в порожнее переливать". Пошел смотреть вакансии (в том числе, чтобы выписать список требований, технологий - что учить) - и как-то не впечатлило.
Kanut
В смысле "где"? Местами на биржах вакансий. Хотя по большей части такие вещи идут через всяких HR-посредников или "личные знакомства".
Ну я знаю двух человек, которые таким занимаются, и у них получается примерно 100-140к€ в год. По их словам это норма для такого дела. Обычно самозанятый сениор у нас зарабатывает 75-90к€ в год. Не самозанятый 65-75к€. Но у самозанятых там ещё некоторые ньюнсы с дополнительными расходами.
Ну у нас в принципе относительно сложно найти работу для самозанятого если смотреть вакансии на всяких онлайн-биржах. Не так чтобы такого вообще не было. Есть конечно.
Но много где самозанятых берут "по знакомству". То есть либо тебя самого должны откуда-то знать, либо кто-то тебя порекомендовать должен.
F0iL
Вот это глупость какая-то. С одной стороны, ноют об острой нехватке специалистов (и она, в принципе, на самом деле есть), а с другой стороны привередничают с "должны знать, или кто-то порекомендовать должен, а все остальные идите нафиг"...
Kanut
Однозначно глупость. То есть я не знаю почему, но какой-нибудь консалтинг за бешенные деньги берут куча фирм. А условно говоря взять того же разработчика напрямую как самозанятого многие не хотят.
То есть я в своё время так из консалтинга "прыгнул" на самозанятость: после того как сделал несколько проектов для одной фирмы и они мне только потом предложили работать с ними напрямую. При этом с консалтингом они продолжали работать и дальше и ни в какую не хотели брать самозанятых "с улицы".
mikka1
Я думаю, что действительно основной "набор" идёт именно через сарафанное радио.
В моей прошлой конторе (США) на момент моего ухода год назад была одна из основных систем, введенная в эксплуатацию в 1987 году. Я несколько лет проработал на проекте миграции на новую и крутую систему, не переставая удивляться тому, насколько продуманно и грамотно была написана система существующая (мы постоянно упирались в то, что стандартный функционал старой системы либо вообще будет отсутствовать в новой, либо будет реализован через многомерные костыли, что нехило доставляло представителям бизнес-подразделений, но это ладно, я отвлёкся...)
Когда в какой-то момент в рамках миграции понадобилось разобрать авгиевы конюшни старой системы, нам сосватали команду из 3 или 4 седовласых и бородатых дядечек, которые ныне основали свою консалтинговую компанию и занимаются как раз спасением утопающих, которые в океане не той системы плавать не умеют. Они пробыли с нами недели 2 или 3, написали то, о чем их попросили, и распрощались. Размер их гонорара за этот микропроект после их ухода старались лишний раз не вспоминать - это была ОЧЕНЬ солидная цифра, сильно превышающая гонорар многих management consulting проектов похожей длительности. И, да, откатов/коррупции там, скорее всего, не было - они реально в вопросе разбирались, а задачу нужно было делать. Но это очень узкая ниша.
dimkrayan
Не совсем понял, при чем здесь самозанятость. Это для работы на несколько заказчиков, или чтобы налоги не так кусались?
но если честно, это не выглядит как "где же вы, только найдитесь". Про зарплату без указания страны говорить не корректно. Очень уж от страны зависит.
Kanut
Немного того и немного другого.
Просто для вещей вроде копания в легаси коде у многих фирм нет "объёма работ" чтобы брать человека на постоянку. Поэтому им проще брать людей под конкретные задачи. Что как бы в свою очередь скорее подходит для консалтинга-галер или самозанятых.
С другой стороны и в плане налогов самозанятость у нас для айтишника вполне себе выгодная штука. Но обычно фирмы её не особо любят.
Ну у меня страна в профиле указана. Но речь про Германию. Или точнее про юго-запад Германии.
dimkrayan
кстати, ради интереса, а при работе через самозанятость что с пенсией? Платятся ли отчисления и будет ли она примерно того же размера(в том же возрасте? может другое какое отличие?), что и при обычном трудовом контракте? Что с другими соц. гарантиями? Пособие по безработице, насколько я помню, через страховку работает - как с ним будут обстоять
дела?
Kanut
Всё добровольно. Но есть возможность платить в "обычный" пенсионный фонд, взять обычную медстраховку, платить страховку по безработице, и так далее и тому подобное.
С другой стороны у нас ту же пенсию на мой взгляд выгоднее делать через частные пенсионные фонды.
dimkrayan
да везде это выгоднее. А может даже лучше через какие-нибудь инвестпакеты.
Мне скорее интересно сравнение с работой по обычному контракту, на сколько выгоднее получается и какие подводные камни. Что не включено в эту стоимость (может, отпуска?).
Спросил товарища из Польши (понимаю, что не то же самое) - говорит, сейчас пытается разобраться, но пока ничего не понятно.
Кстати, налоговая не гоняет за это? Я слышал, у нас могут квалифицировать, как попытку уйти от налогов и доначислить.
Kanut
Ну я бы сказал что получается где-то на 30-40% дешевле.
Ну например если взять приватную медицинскую страховку, то она выгоднее. Но на обычную потом практически не вернуться. И надо будет платить частную даже если уже не самозанятый.
За что? Ты точно так же сдаёшь налоговую декларацию и указываешь доходы-расходы. И если налоговой что-то не нравится, то она тебе сообщит. Но у меня ни разу никаких проблем не было.
slonopotamus
Это ведь до налогов? Чо-то мало, столько сеньором можно и в Мск зарабатывать. И при этом не надо "есть говно" (с).
vics001
Хорошие однако зарплаты в Москве, неужели и вправду больше 1 млн RUB в месяц?!
В Европе > 100K EUR это уже высший класс developers или management.
DarthVictor
После налогов от €120K в европе останется тысяч €80К. Или ₽535К. Это весьма много, но в банках возможная зарплата для всякий техлидов-архитекторов, особенно учитывая 13-ю, а иногда и 14-ю зарплату.
Kanut
Если самозанятый, то там спокойно может на руки оставаться 100к€ или даже больше. По крайней мере у нас.
tchkEn
Если речь про Россию, то такие вакансии исчезают, - многие переходят на софт написанный на более современных и "популярных" языках программирования.
victor_1212
>Другое дело что вся эта возня с легаси(то есть не только Cobol, но и ряд других языков) дело очень мутное и нервное.
ну это они только пишут что надо Cobol, а на самом деле 99% в чужом гуано придется разбираться к тому же плохо документированном, как обычно imho
tchkEn
В России лет 10 назад может и больше зарабатывали люди знающие Cobol, но это уже давно не так, есть АБС написанные на более современных "популярных" языках, они проще в освоении и удобнее в использовании. Наверное России даже повезло с тем, что финтех у нас помоложе чем в США, вот там реально без Cobol не обойтись и смогут ли они с него вообще слезть не понятно.
Kanut
У нас тоже потихоньку идёт миграция с такого легаси на более актуальные вещи. Но всё равно есть всё ещё куча мест где можно встретить тот же Cobol.
zloy_zaya
I believe you're trying to compare senior's salary for West coast with Cobol programmer's in East coast. Most Cobol jobs are in East coast.
dimkrayan
Нет, я сравниваю зарплаты где угодно в США. Точнее, я сравниваю с сайтом indeed.com. Где он их выдает - там и сравниваю. А если про друзей - один из них живет вообще не на побережье, в Денвере.
Кстати, а почему есть разница, на каком побережье?
zloy_zaya
Сравнить зарплаты по США "где угодно" это как сравнить зарплаты по России, например, и Москвы.. На Восточном побережье Washington DC, соответственно в примыкающих штатах, как то VA и MD много работы на федеральное правительство. Там зарплаты не настолько большие, но работа стабильная (читайте, пожизненная) и даже контракты длительностью 5-6 лет. У меня знакомый уже 12 лет работает на контракте и хорошо себя чувствует.
Западное побережье это, как правило, Калифорния/Долина. Там люди зарабатывают совершенно другие деньги, но там и стоимость жизни куда выше.
Мейнфреймы стоят в основном, в федеральном правительстве, правительстве штатов и, иногда, в некоторых крупных банках. Другое дело, что банки давно мигрировали свои мейнфреймы в облака IBM, а вот Агентства расчехляются медленно. Если на чек-поинте вашего агентствавы видите старичков, то это IBM пришел разрулить серьезные проблемы связанные с мейнфреймами.
Как-то так.
dimkrayan
учитывая, что я смотрел на максимальные зарплаты в коболе - можно сказать, что я сравнивал их "в лучшем месте в США" (да, формулировка так себе).
А еще на восточном побережье есть Нью Йорк. И там зарплаты вполне на уровне.
А насчет старичков вы не правы. Работал я в прошлом в интеграторах, занимался в основном СХДшками для всех этих мейнфреймов (symmetrix), ну и немного IBM-овскими серваками (pSeries - знаю, что это не мейнфреймы, хотя и выглядят солидно). И возраст большей части коллег и инженеров вендора был лет 30-35.
nochkin
Нью Йорк в этом плане тоже любит держать у себя динозавров в плане старых систем, банков и т.д.
Восточное побережье больше по финансам и потому много старого, которое надо поддерживать.
Просто так сложилось исторически.