Комментарии 66
Если COBOL так хорош, необходим и надёжен, то замена первой цифры в зарплате обычного программиста с 1 на 2, мгновенно сделает этот язык и модным, и молодёжным. Капиталистам ли этого не понимать? К чему эти стенания?
Не ну с деньгами так все могут!
P.S. парсер сарказма сломан, капитан очевидность передаёт привет
Кобол необходим, но он отвратителен в поддержке и написании. Повышение зарплаты приведёт к появлению ещё большего потока джуниоров (а нужны сеньёры экстра-класса). Не существует промежуточного уровня, где из джуниора может получиться сеньёр, потому что новых проектов на коболе не пишут. Т.е. идеальным вариантом было бы дать в десять раз больше денег 80-летнему дедушке, чтобы он стал 40-летним. Но так не работает.
Рабочим вариантом будет дать x5 денег пачке джунов (40-летних, с других языков) и потом долго (годы) гонять их на тестовых и тренировочных задачах под присмотром того самого дедушки, отсеивая тех, кто не справляется.
Только наша индустрия (да и не только наша) так не умеет. Прежде всего потому что набора 'тестовых и тренировочных' задач, до сих пор не сделали.
Кроме того — не всякий джун пойдёт учить COBOL. Умный — точно не пойдёт.
Джун — тут имеется джун в COBOL-е. Так-то он, может, уже 20 лет на других языках отработал. И которому общеизвестные грабли уже не нужно объяснять.
а вот у 40-летнего профи в COBOL вариантов нет
Так именно что есть. Такой вот вариант дотянуть до пенсии на редком рабочем месте, куда молодежь, которым на домик зарабатывать и о будущей своей карьере думать надо, не пойдет.
Да пока вы перепишете, оно тоже перестанет быть современным. И современное — оно такое… Представьте себе поддержку системы на 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 запустить на суперкомпьютере. Впечатлит только журналистов.
COBOL-85 изучается за 2 недели, а инфраструктура и процессы вокруг одной программы — сколь угодно долго. Статья о потере бизнес-знаний, тем более что новые версии Мейнфреймов полностью обратно совместимы. Архитектура millicode — гордость IBM.
Вместе с тем, миграция с Мейнфреймов как бизнес существует лет 40 и простые/дешевые кейсы уже давно выполнены.
В Америке любят Игоря Николаева и Фила Коллинза. И не любят COBOL.
Поэтому этот крупный банк по-прежнему зависит от людей вроде 73-летнего Томаса, который не только обеспечивает работу кода, но и может добавлять новые возможности и улучшения. Переживёт ли Томаса его код на COBOL?
BusFactor = 1 в Абсолюте
Пузырьковая сортировка на COBOL
P.S. Думаю, «проблема» и отчасти в не COBOL, а в сложности выражения каких то его синтаксически/семантических возможностей в других языках на его замену.
Offtop: Узнала по вашей ссылке о языке Ursala. Очень выразительно!
Спасибо, интересно. Особенно весело было узнать, что часть проблемы Y2K просто отодвинули на 2045 год. That's the spirit!
Томас уволился из банка в 2007 году в возрасте примерно 60 лет, и когда он ушёл, банк всё ещё использовал его систему, которой к тому времени исполнилось 20 лет.
всё-таки с 2007 очень многое изменилось, даже консервативный кровавый энтерпрайз за последние 15 лет похоронил тонны мэйнфреймов, лет через 20 также над Явой глумиться будут
Надо понимать, что там ещё и разная java. Где-то в каком-то забытом богом банке крутится что-то на java 4 на сановом серваке...
После анализа было принято решение ничего не переделывать.
По поводу решения — это смесь технических трудностей, рисков, а также желания вендора подсадить на другое свое решение + приправлено внутренними интригами самого банка.
В общем сложно всё.
На самом деле не верится, что все именно так. Мне почему-то кажется, что весь этот древний код на древних языках можно переписать.
И да, я пошел по ссылке «пузырьковая сортировка» и понял код (хоть и с некоторым трудом). COBOL понятен. Если вы программист.
Даже захотелось немного поработать с ним. Есть ссылка на онлайн-песочницу с обучением?
Ну и вообще…
Будь как COBOL!
Мне почему-то кажется, что весь этот древний код на древних языках можно переписать.
Я бы даже больше сказал. Весь код на проектах нужно переписывать. Постоянно переваривать, а иначе будет смех и позор. Недавно собеседовался в компанию, делающую системки для управления делами больниц — так они мне с гордостью продемонстрировали скриншот, в котором была их система. На скриншоте разноцветными квадратиками показывалось, что и на чем в системе написано.
Само окно системы и пара панелек верхнего уровня была написана на дельфи. Внутри еще несколько панелек была написана на Eclipse RCP. Внутри RCP было поле, в котором запускалось веб-приложение на первом Ангуляре. И в их «ближайших планах» значилось перейти на второй ангуляр (то есть, я бы создал еще один квадратик с ангуляром вторым внутри ангуляра первого).
Ну так им же не шашечки, а ехать — я бы тоже на их месте крепко задумался, зачем мне это переписывать. Это для вас там код, который устроен разумно или нет, а для них — коробка типа телевизора, и что там внутри — хоть лампы вперемешку с микросхемами — работает и ладно. Должна же быть разумная бизнес-цель, которая окупит эту работу, а не просто ради красоты.
Когда-то запомнилась статья на Хабре про то, что уходит на покой последний программист "Вояджера", которому сейчас 85 лет. И могут быть проблемы, ибо уже мало кто понимает, что за ПО там летит, а документация частично утеряна.
Не вижу проблемы отделять часть процессов от монолита на коболе и выводить в отдельную систему. Параллельно тестировать на одних и тех же данных. И потом уже запускать в прод. Кажется проблема высосана из пальца.
>Кроме того, есть основания полагать, что теперь Сбер будет регулярно обновлять системы.
Что даже если они совсем новые, все равно их нужно обновлять, и это непросто, и при этом они устаревают сами по себе.
"Кроме того, когда в 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, некоторые из которых были написаны ещё до появления цветных телевизоров, используются в нашей повседневной жизни повсюду
Автор этой строки не в курсе, когда появились цветные телевизоры
Публикации
COBOL — древний код, который управляет вашими деньгами