Pull to refresh

Comments 66

Если COBOL так хорош, необходим и надёжен, то замена первой цифры в зарплате обычного программиста с 1 на 2, мгновенно сделает этот язык и модным, и молодёжным. Капиталистам ли этого не понимать? К чему эти стенания?

Не ну с деньгами так все могут!

Цифры 3 и 4 пока что не помогли. Накачивание деньгами пользователей ни к чему хорошему еще не приводило, и очевидно, не хватает инфраструктуры.
P.S. парсер сарказма сломан, капитан очевидность передаёт привет

Кобол необходим, но он отвратителен в поддержке и написании. Повышение зарплаты приведёт к появлению ещё большего потока джуниоров (а нужны сеньёры экстра-класса). Не существует промежуточного уровня, где из джуниора может получиться сеньёр, потому что новых проектов на коболе не пишут. Т.е. идеальным вариантом было бы дать в десять раз больше денег 80-летнему дедушке, чтобы он стал 40-летним. Но так не работает.

Рабочим вариантом будет дать x5 денег пачке джунов (40-летних, с других языков) и потом долго (годы) гонять их на тестовых и тренировочных задачах под присмотром того самого дедушки, отсеивая тех, кто не справляется.


Только наша индустрия (да и не только наша) так не умеет. Прежде всего потому что набора 'тестовых и тренировочных' задач, до сих пор не сделали.

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

Всегда найдется сколько-то человек, склонных к промышленной археологии. Собственно, все это и должно происходить на факультете этого направления (обычно — в качестве дополнительного образования), который финансируется заинтересованными организациями.

А может лучше всё переписать заново на чём-то современном? По затратам выйдет наверное тоже самое, что и в вашем предложении.
Кроме того — не всякий джун пойдёт учить COBOL. Умный — точно не пойдёт. Потому что понимает: 80-летнему дедушке можно дать x5 денег потому что у него выбор "работать или пенсия", а вот у 40-летнего профи в COBOL вариантов нет — рынок труда очень узкий, уходить некуда. Такому можно платить «среднюю зарплату»(а то и меньше) и никуда он не денется до пенсии. А если вдруг к его 50 годам таки решат переписать всё на современном языке — он остаётся не у дел.
Кроме того — не всякий джун пойдёт учить COBOL. Умный — точно не пойдёт.

Джун — тут имеется джун в COBOL-е. Так-то он, может, уже 20 лет на других языках отработал. И которому общеизвестные грабли уже не нужно объяснять.


а вот у 40-летнего профи в COBOL вариантов нет

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

Джун — тут имеется джун в COBOL-е. Так-то он, может, уже 20 лет на других языках отработал.

Вы случайно не кадровичка, которая считает, что человеку с 20 годами опыта на C++, если он вчера сел писать на C#, нужно платить так же как вчерашнему студенту, потому что он «джун»?
Так-то он, может, уже 20 лет на других языках отработал. И которому общеизвестные грабли уже не нужно объяснять.

Тут не было про 'платить как вчерашнему студенту'. Как раз наоборот. Платить достаточно. Стипендию в процессе обучения. Но нещадно гнать всех, кто не справляется.

Да пока вы перепишете, оно тоже перестанет быть современным. И современное — оно такое… Представьте себе поддержку системы на node.js через сорок лет — ещё неизвестно, что лучше, кобол или вот это.

Во-первых через N лет у вас будут хорошие миддлы. Которые нифига не экстра-класс серьёров, потому что ни одного реального проекта не сделали. Учить можно сколько угодно, но боевой опыт там не получить. Можно пойти писать что-то новое на коболе (и тогда начнут образовываться сеньёры) — но это как "обучение военных врачей посредством увеличения числа войн".


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

Я вот не понимаю, зачем там дедушки-синьоры? Не, ну не вообще зачем они там, а зачем там синьоры в коболе? Всеж понимают, что да, переписать большую легаси систему сложно, просто потому, что она большая, документации или нет, или не соответствует, и все такое прочее. Но с другой стороны, какая часть этих трудностей связана непосредственно с коболом? Я думаю — от силы половина. Т.е. большая часть — это архитектура всей системы, алгоритмы, и т.п. — и чтобы их понять, почти не нужно знать кобол. Нужно знать бизнес. Бухгалтерию там, например. И уметь проектировать системы. От них требуется способность создать подобную систему с нуля. А знать кобол во всех тонкостях им зачем?

Я больше скажу — когда я был молодой, кобол еще был достаточно живым. И хотя у меня никогда не было желания на нем писать, хотя бы потому, что рядом был доступен ассемблер и PL/1, я для моих задач они оба были лучше, я по нему документацию все-таки читал. В нем нет ничего ровным счетом, что нельзя было бы изучить за год. Язык как язык. Еще год — чтобы вникнуть скажем в MVS, ну или на чем оно там нынче работает.
Т.е. большая часть — это архитектура всей системы, алгоритмы, и т.п. — и чтобы их понять, почти не нужно знать кобол.

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

Не, ну я сказал большая часть. Понятно что язык изучить придется.

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

Т.е. представим, что мы прочитали документацию и код, и вникли в эту легаси систему. И поняли как она работает (или не очень поняли). Если вообще никто не может нам подтвердить, правильно ли мы понимаем — это не тоже самое, как в случае когда мы не можем понять код вообще, разве нет?

Не совсем. Потому что если мы очень хорошо понимаем код, то мы можем восстановить логику, по которой он работает (даже не очень понимая, зачем) и потом пойти спрашивать 'оно делает то и то, кто-нибудь может объяснить?'.


А если это черный ящик, которого мы не понимаем совсем — то даже этого спросить не получится.

Тогда я не понял, о чем мы тут спорим?

Я ведь и имел в виду, что не очень понимаю, для каких таких целей обязательно иметь эксперта в коболе. Кобол-то мы как раз поймем как-нибудь — на него есть документация, в отличие от бизнес логики. Чтобы понять (с документацией), что именно делает программа даже на незнакомом языке — не обязательно быть прямо экспертом в этом языке, нужно скорее понимать ее бизнес назначение.
Я ведь и имел в виду, что не очень понимаю, для каких таких целей обязательно иметь эксперта в коболе.

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

COBOL как спецификация (COBOL-85) скуден и изучать его в рамках курса программирования общего назначения бессмысленно. Однако, примитивность сделала возможным транспиляцию в C (GnuCOBOL), .NET IL (vCOBOL) и JVM bytecode (isCOBOL).
COBOL как экосистема была давно присвоена IBM — закрытый компилятор в исполняемой среде на Mainframe. Специфическое дорогущее железо, софт и жадность IBM сделала COBOL маргинальным в современном мире. Поняв, что укусила собственный хвост, компания начала срочно инвестировать в инструменты, обучение и сообщество (Open Mainframe Project). Поздновато и недостаточно, похоже.
Кстати, производительность COBOL это миф. Это как Hello World на C запустить на суперкомпьютере. Впечатлит только журналистов.

примитивность сделала возможным транспиляцию в C (GnuCOBOL), .NET IL (vCOBOL) и JVM bytecode (isCOBOL)

Так почему бы не транспилировать код в C, а затем нанять специалистов C/C++?

COBOL-85 изучается за 2 недели, а инфраструктура и процессы вокруг одной программы — сколь угодно долго. Статья о потере бизнес-знаний, тем более что новые версии Мейнфреймов полностью обратно совместимы. Архитектура millicode — гордость IBM.
Вместе с тем, миграция с Мейнфреймов как бизнес существует лет 40 и простые/дешевые кейсы уже давно выполнены.

В Америке любят Игоря Николаева и Фила Коллинза. И не любят COBOL.

Поэтому этот крупный банк по-прежнему зависит от людей вроде 73-летнего Томаса, который не только обеспечивает работу кода, но и может добавлять новые возможности и улучшения. Переживёт ли Томаса его код на COBOL?

BusFactor = 1 в Абсолюте
К примеру, так выглядит одна реализация:
Пузырьковая сортировка на COBOL

P.S. Думаю, «проблема» и отчасти в не COBOL, а в сложности выражения каких то его синтаксически/семантических возможностей в других языках на его замену.

Offtop: Узнала по вашей ссылке о языке Ursala. Очень выразительно!

Тут процентов 50 кода в строках — это всякого рода описания. А реально сортировка — от силы строк 20, как и в более современных языках. Т.е. интересного тут — это E-BUBBLE и F-PASS, все остальное — чтение данных из файлов, запись результатов и т.п. ерунда.

Спасибо, интересно. Особенно весело было узнать, что часть проблемы Y2K просто отодвинули на 2045 год. That's the spirit!

по-моему в фокспро было сделано также задолго до 2000
Томас уволился из банка в 2007 году в возрасте примерно 60 лет, и когда он ушёл, банк всё ещё использовал его систему, которой к тому времени исполнилось 20 лет.


всё-таки с 2007 очень многое изменилось, даже консервативный кровавый энтерпрайз за последние 15 лет похоронил тонны мэйнфреймов, лет через 20 также над Явой глумиться будут

Надо понимать, что там ещё и разная java. Где-то в каком-то забытом богом банке крутится что-то на java 4 на сановом серваке...

Ну почему прям забытом? Я даже вам скажу, как это банк называется. UBS, например.
UFO just landed and posted this here
Я совершенно ничего не знаю про UBS как банк. Но я знаю, что они приглашали разработчиков сопровождать и допиливать систему, написанную давно под стандарты J2EE (EJB) 2. И было это тогда, когда у всех уже был JavaEE версий примерно на пять новее. Ну или лет на 10, если в годах. Ну т.е. они к 2015 году, грубо говоря, застряли на уровне 2005. И ладно бы старая версия была «просто работает». Но ведь нет же — она вызывала геморрой в процессе работы, который в новых версиях был в значительной степени устранен.
А в реальности кто-нибудь видел работающую систему на Коболе?
Я видел. И, как это ни странно, в банке. Собственно задача и была на то, чтобы переписать эту часть системы на что-то более вменяемое.
После анализа было принято решение ничего не переделывать.
Интересно, спасибо. В России? А почему было принято такое решение?
Россия, да. Подсистема взаимодействия с ЦБ (там вообще отдельная тема с легаси). Больше деталей дать не могу — NDA.

По поводу решения — это смесь технических трудностей, рисков, а также желания вендора подсадить на другое свое решение + приправлено внутренними интригами самого банка.
В общем сложно всё.
То есть никто не согласился сделать эту работу, не согласился проверить сделанное, и заодно возник соблазн свалить задачу на поставщика компьютеров?
Нет, не так. Согласились сделать работу, но так, что банк меняет зависимость от Cobol и своего закоболеного человека на стороннее решение + кабальное соглашение на сопровождение этого решения. Взвесив все за и против Банк решил не менять шило на мыло.
у меня друган даже писал на коболе для UBS чуток. Сказал, интересный язык, но много церемоний.
Огромное спасибо за перевод этой статьи. Я плакал, когда читал ее. И смеялся, конешно, тоже.
На самом деле не верится, что все именно так. Мне почему-то кажется, что весь этот древний код на древних языках можно переписать.
И да, я пошел по ссылке «пузырьковая сортировка» и понял код (хоть и с некоторым трудом). COBOL понятен. Если вы программист.
Даже захотелось немного поработать с ним. Есть ссылка на онлайн-песочницу с обучением?
Ну и вообще…
Будь как COBOL!
Мне почему-то кажется, что весь этот древний код на древних языках можно переписать.

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

Само окно системы и пара панелек верхнего уровня была написана на дельфи. Внутри еще несколько панелек была написана на Eclipse RCP. Внутри RCP было поле, в котором запускалось веб-приложение на первом Ангуляре. И в их «ближайших планах» значилось перейти на второй ангуляр (то есть, я бы создал еще один квадратик с ангуляром вторым внутри ангуляра первого).

Ну так им же не шашечки, а ехать — я бы тоже на их месте крепко задумался, зачем мне это переписывать. Это для вас там код, который устроен разумно или нет, а для них — коробка типа телевизора, и что там внутри — хоть лампы вперемешку с микросхемами — работает и ладно. Должна же быть разумная бизнес-цель, которая окупит эту работу, а не просто ради красоты.

Когда-то запомнилась статья на Хабре про то, что уходит на покой последний программист "Вояджера", которому сейчас 85 лет. И могут быть проблемы, ибо уже мало кто понимает, что за ПО там летит, а документация частично утеряна.

На Perl'e надо переписывать, очень сильно сокращает код:-)
))))))
О да…
Я как то на нем пару строчек написал.
А через месяц потратил час, чтобы разобраться — а как именно работает то, что сам и написал. :)

APL тогда уж. И кода меньше, и по времени больше соответствует Коболу.

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

Не вижу проблемы отделять часть процессов от монолита на коболе и выводить в отдельную систему. Параллельно тестировать на одних и тех же данных. И потом уже запускать в прод. Кажется проблема высосана из пальца.

Bank of America и Сбер сопоставимы по масштабам, но это не помешало второму переписать за последние несколько лет бо́льшую часть систем на свежих технологиях.
Ну это не значит, что у всех есть на это время и деньги. И потом, представьте, что пять лет назад вы внедрили свежую технологию. Сегодня в режиме 24*7 крутится скажем версия 5-летней давности, в каком-то смысле уже legacy в полный рост, и там уже данных петабайты, а переход на более новые версии уже иногда становится нетривиальной задачей. Ну т.е. у любого софта, который не переписывают просто так, а эксплуатируют, имеется свойство устаревать со временем, даже если когда его внедряли он был супер-пупер новым.
Устаревание — это одно, а невозможность даже за очень дорого нанять специалиста — это проблема совсем иного порядка. Сберу теперь не надо будет беспокоиться о наличии рабочей силы, как минимум лет 15, а вероятно и все 25. И сотрудникам Сбера не надо беспокоиться, что их профессиональные навыки будут востребованы только в очень узкой области деятельности или не будут востребованы рынком совсем. Кроме того, есть основания полагать, что теперь Сбер будет регулярно обновлять системы.
Не, ну это все же две разные стороны медали. Понятно что люди на Grid Gain скажем найдутся легче, чем на что-то древнее. А я скорее про вот это:

>Кроме того, есть основания полагать, что теперь Сбер будет регулярно обновлять системы.
Что даже если они совсем новые, все равно их нужно обновлять, и это непросто, и при этом они устаревают сами по себе.

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


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

Нет, не так. Кобол может работать на новом оборудовании, но это не ПК. Но попробуйте пойти и купить современный мейнфрейм, даже если он условно настольный по габаритам. А кобол который работает на ПК — это кобол другой версии, и на нем конечно можно учиться — но половины возможностей не попробуешь.

На сейчас живых (разрабатываемых и выпущенных в 2020) COBOL диалектов 7:


  • IBM Enterprise COBOL
  • Fujitsu NetCOBOL
  • Envyr ICOBOL
  • GnuCOBOL
  • Micro Focus Visual COBOL
  • Veryant isCOBOL
  • Raincode COBOL

Первые три имеют собственный компилятор в нативный рантайм Windows (NetCOBOL, ICOBOL), Linux (NetCOBOL, ICOBOL), Z/OS (Enterprise COBOL). Последние три исполняются в .NET, .NET Core и JVM.

Не будем забывать про MOCHAS, систему, которая управляет контрактами минобороны США на два с лишним триллиона долларов. Она написала в 1959 на flow-matic, был такой язык до кобола.

Это перевод или оригинальный текст?

Дежа вю, возможно из-за того что я уже читал про "Томаса" где-то. Но стиль языка очень похож на англоязычный журнальный язык.

Этот банк не одинок. Программы на COBOL, некоторые из которых были написаны ещё до появления цветных телевизоров, используются в нашей повседневной жизни повсюду

Автор этой строки не в курсе, когда появились цветные телевизоры

Sign up to leave a comment.

Articles

Change theme settings