Языку программирования COBOL свыше 60 лет. Несмотря на это, он до сих пор активно используется. Конечно, в подавляющем большинстве сфер его заменили современные языки программирования. Но дело в том, что в ряде стран до сих пор работают аппаратные системы с ПО на базе этого ЯП. Особенно много их в США.
Поэтому COBOL держится на плаву и в последние несколько лет даже набирал популярность. Так, например, в августе 2023 года язык вышел на 15 место по популярности среди ЯП. Год назад он находился на 31 месте. Впечатляющий рост. Но через время, возможно, он станет уже историей. Всё дело в инициативе IBM, о которой расскажем под катом.
Немного о причинах живучести языка
Главная — то, что ещё действительно много систем, которые работают с этим ЯП. Вот инфографика от 2017 года, созданная в рамках исследования Reuters. Конечно, прошло 6 лет, но вряд ли все эти компании и системы разом перешли на новые языки — уж слишком это дорого. Кто-то перешёл, но большинство компаний предпочли новому хорошо работающее и проверенное временем старое.
Если система хорошо работает, пусть даже ей и много лет — зачем менять? Пока это не угрожает информационной безопасности инфраструктуры компании, её технической стабильности, никто не рвётся менять работающие системы, проверенные временем, на нечто новое. Только потому, что это — новое и современное.
Но вот парадокс — систем ещё много, а вот программистов, которые хорошо в них разбираются и могут что-то писать на Cobol, — совсем крохи. И большинству из них около 60-70 лет.
В том же 2017 году 75-летний программист по имени Билл Хиншо основал компанию по обслуживанию систем на COBOL. И не просто так — дело в том, что в том же 2017 году COBOL всё ещё обеспечивал проведение транзакций на суммы свыше $3 млрд. И не в год или месяц, а в день. В эту сумму входят операции со счетами, страхование жизни, кредитные сервисы, работа банкоматов. Всего несколько секунд простоя какой-либо узловой системы на COBOL может стоить бизнесу многих миллионов долларов.
В итоге Хиншо неплохо расширил компанию, пригласил несколько программистов, которые уже отдыхали на пенсии, плюс нанял 50-летних юнцов и стал обслуживать инфраструктуру различных банков, страховых и кредитных организаций. Компании постепенно переходят на современные технологии, но стоит это больших денег. Например, стоимость замены старой инфраструктуры на новую обошлась одному из крупных банков Австралии в $749,9 млн.
Если всё хорошо, в чём проблема?
Дело в том, что IBM разработала специальный набор инструментов по автоматическому преобразованию кода COBOL в код на Java. И это не теоретическая разработка, не proof of concept, а коммерческий инструмент, который предлагается партнёрам компании.
Называется инструмент Watsonx Code Assistant. Сейчас с ним работает ограниченное количество клиентов IBM, но уже к концу года начнётся полномасштабная кампания по предоставлению новинки всем желающим. И, скорее всего, их будет много, потому что мало кому улыбается обслуживать системы, которым несколько десятков лет, и для которых нужно упорно искать персонал, способный во всём разобраться.
Самое интересное, что всем недавно та же IBM возродила популярность COBOL, конечно, в несколько ограниченном виде, но всё же. Дело в том, что американская система занятости в 2020 году всё ещё зависела от COBOL (сейчас ситуация несколько поменялась). И после того, как из-за пандемии выросло количество безработных, инфраструктура не выдержала возросшей нагрузки. В итоге всё пришлось спешно чинить, приглашая существующих специалистов по COBOL и подготавливать новых.
Да, IBM организовала обучающие курсы по этому языку, которые помогли решить проблему со страховой системой, равно как с инфраструктурой и других организаций. В итоге благодаря стараниям IBM и других компаний количество строк кода, написанных на COBOL, в 2022 году составило уже 800 млрд. Правда, вполне возможно, что в 2017 году просто посчитали не всё, но факт остаётся фактом — количество строк кода, написанных на COBOL, огромно.
IBM решила упростить компаниям процесс перехода на новые технологические платформы и языки, поэтому и разработала новый инструмент.
Что в итоге?
Если проект, предложенный IBM, действительно работает так хорошо, как об этом говорит сама компания, то задача миграции очень упростится. Понятно, что какой бы надёжной технология миграции ни была, это не волшебная кнопка «Обновить инфраструктуру сейчас». Работы будет немало, но в ней примут участие уже не только избранные, т. е. программисты на COBOL, но и специалисты по Java.
Сам процесс миграции должен стать быстрее и проще, что и нужно бизнесу. Код, который создаётся при помощи Watsonx Code Assistant, не станет конфликтовать с остальными системами, даже если они и устаревшие. Код объектно-ориентированный, а значит будет поддерживаться совместимость как с модулями, написанными на COBOL, так и с сервисами вроде CICS, IMS, DB2.
Скорее всего, о проекте IBM мы ещё услышим в конце года, и тогда будет понятно, как продвигается процесс миграции.
Комментарии (65)
Leetc0deMonkey
01.09.2023 15:45Ни за что не поверю что на современном перенасыщенном рынке, да ещё после массовых увольнений, найдётся мало желающих хоть в Коболе разобраться, лишь бы платили. Тут что-то другое.
Machirodont
01.09.2023 15:45+21Я так понимаю, нормальных обучающих материалов нет, нормальной IDE нет, open-source проектов нет, доступа к нативной среде исполнения (мейнфреймы) в обучающих целях тоже нет, как и актуальной документации к ним в открытом доступе. Практически 100% вакансий - работа над критическими системами в крупном энтерпрайзе (банки, страховые и т.п.), в таких местах джунов-мидлов не нанимают в принципе, а проектов, на которых можно набраться опыта - не существует. При том что спрос, несмотря на "рост", все равно ничтожен - перспективнее разобраться в очередном JS-фреймворке.
Leetc0deMonkey
01.09.2023 15:45+5Для состоявшегося в IT спеца, желающего сменить стек, никакая IDE не проблема. Мейнфреймы нынче в вируталках. Отсутствие документации тоже вызывает вопросы. И главное - ровным счётом ничего никогда не предпринималось для решения этих вопросов. Тезис о непопулярности и дефиците коболистов хорошо заходил где-то до начала-середины 2010ых. Потом это начало подозрительно попахивать. А сейчас откровенно понятно что гильдия старых коболистов просто грамотно подмяла под себя сытную поляну и никого туда не пускает.
0xd34df00d
01.09.2023 15:45+6Так состоявшихся айти-спецов упомянутые вами массовые увольнения не затронули. С чего бы им лезть в кобол?
Leetc0deMonkey
01.09.2023 15:45+1Так состоявшихся айти-спецов упомянутые вами массовые увольнения не затронули.
Ещё как затронули. Выкидывали и выкидывают целыми отделами, не особо вникая в ценность выкидываемой персоналии. А проходить потом месяцами 5 этапные литкодсобесы - да лучше в Коболе разобраться...
cupraer
01.09.2023 15:45+5У меня в анамнезе есть 3 года подтвержденного опыта на COBOL over VAX/VMS, в конце 90-х. Каждую осень — несколько входящих с предложениями на такие деньги, которые мне в Европе никогда не получить.
Основная проблема — эта работа сезонная, контракт «до нового года», залатать дыры для генерации отчетов. Предложений на постоянку я не видел уже лет 15.
0xd34df00d
01.09.2023 15:45Ну вот вам в кобол влезать и не нужно, вы уже в нём, и ещё небось про это упоминаете на всяких там линкединах, поэтому вам и пишут. Это немного не та ситуация.
vadimr
01.09.2023 15:45+3Что значит “не пускает”? Учите Кобол, никто не запрещает. Почему вы до сих пор не изучили?
Порог входа высокий, а рынок относительно небольшой.
При этом сам язык Кобол у меня, например, с детства вызывает физиологическое отвращение, хотя я люблю мейнфреймы и всякий винтаж.
SpiderEkb
01.09.2023 15:45+2Порог входа высокий потому что кроме мамого языка еще придется осваивать платформу на которой все это работает.
А рынок ограничен потому что область специфическая. Это не сайтики клепать.
А требования там достаточно жесткие, стеки крайне консервативные
CrzyDocTI
01.09.2023 15:45+31) "Для состоявшегося в IT спеца, желающего сменить стек, никакая IDE не проблема" - только если проблема не вида что раньше была IDE, а теперь можно сказать что нет. Инструменты гораздо менее развиты.
2) "Мейнфреймы нынче в вируталках" - эмулировать нормально так и не научились, в виртуалках что-то что поможет написать helloy world но не более
3) "Отсутствие документации" - так же как и с IDE - в сравнении можно считать что ее нет.
ПС. Watsonx Code Assistant еще пару лет назад был очень сомнителен. А пилить его начали чуть ли не 10 лет назад - сомневаюсь что сильно продвинулись
SpiderEkb
01.09.2023 15:45+4нормальной IDE нет, open-source проектов нет, доступа к нативной среде исполнения (мейнфреймы) в обучающих целях тоже нет
Написал уже ниже. Регистрируемся на на POUB400.COM, ставим VSCode + IBM i Development Pack и получаем все что надо. Так что сказки все это.
Другое дело, что да. Придется думать самому и писать самому. А не лепить из готовых кирпичиков по-быстрому.
в таких местах джунов-мидлов не нанимают в принципе
Да ладно? У нас вот нанимают. Не КОБОЛ, но... Писать банковскую логику на RPG под IBM i (и да, компилятор КОБОЛ тут тоже есть).
Варианта два - если совсем без опыта - стажером на полгода. Если с опытом разработки - просто первые три месяца "испытательный срок" (в полной оплатой и всеми делами) - фактически обучение (будет наставник персональный, план обучения) конкретному языку и платформе.
перспективнее разобраться в очередном JS-фреймворке
Естественно. Там не будут каждую поставку через нагрузочное тестирование прогонять и придираться к каждому проценту утилизации CPU. Там можно выучить пару фреймворков и вперед - "херак-херак и в продакшн".
Conung_ViC
01.09.2023 15:45Очень знакомые условия...
АльфаБанк, Екб?
bear11
01.09.2023 15:45+1"open-source проектов нет"
Есть. https://sourceforge.net/projects/gnucobol/
Кобол отличный язык если вам нужно перерабатывать заумные текстовые формы с полями данных
с точностью до позиции. Ввод-вывод таких документов - его конек.
perfect_genius
01.09.2023 15:45+1в ней примут участие уже не только избранные, т. е. программисты на COBOL
А какой смысл им убивать свою востребованность?
Hardcoin
01.09.2023 15:45+1А какой смысл программистам делать нейронки для написания кода? Тоже ведь убивают свою востребованность.
perfect_genius
01.09.2023 15:45Для обучения нейронки необязательно ведь нужен опытный заинтересованный программист.
А если обучает и такой, то может и сомневается, что что-то выйдет, зато деньги получает.
Это действительно интересный вопрос — кто обучает нейронку для замены своей профессии.Какой-нибудь транслятор выглядит более реализуемым, чем нейронки, способные полноценно заменить программиста.
Hardcoin
01.09.2023 15:45Это bleeding edge технологий. Разумеется нужен опытный заинтересованный программист. От других толку не будет.
xkb45bkc4
01.09.2023 15:45+2Наверное разово можно заработать много больше, чем за годы поддержки. Да и сроки миграции могут быть не маленькими.
mst_72
01.09.2023 15:45+6COBOL. На Java... Примерно то, что где-то активно в 2010-15 годах делалось с сомнительным успехом (из-за специфики организации памяти в коболе, которую проще на C перенести, чем на Java). И тут внезапно проявился "ассистент" для переноса... Ну просто ахренеть
vadimr
01.09.2023 15:45+8Эту песню про уход Кобола с рынка я слышу последние 30 лет.
А что касается конкретной технологии кросс-компиляции на другой язык, то я в своей жизни не видел ни одного примера, когда бы кто-то пользовался результатом такого процесса, хотя идея отнюдь не нова. Как верно замечено в комментарии выше, вопрос же не в том, чтобы поменять синтаксис операторных скобок. 99% текста легаси программ вообще низачем не нужно в современных условиях, и глупо его переписывать (это будут, скажем, манипуляции с блоками DSCB, или переименования файлов, или выделение памяти руками через анус, или какая-нибудь ещё дичь). Но весь код вместе с исполняющим его окружением обладает системным эффектом пригодности для решения задачи.
olku
01.09.2023 15:45+28Есть некоторые мифы о Коболе, гуляющие из статьи в статью.
Коболов, а именно их диалектов, несколько. Полной совместимости они не имеют. Тот диалект, про который обычно журналисты пишут - это IBM Enterprise Cobol. Компилятор его доступен только на мейнфреймах, разработка и отладка либо через терминал, либо через плагин для VSCode, который делал подрядчик из Чехии. Этот плагин реализует клиента АПИ к Z/os.
Курсы и документация есть. Смотрите на Гитхабе OpenMainframe Project. В рамках курса IBM даёт аккаунт на мейнфрейм. Но не все современные практики разработки применимы. Репортил ребятам чтобы ненулевой код возврата клиент отдавал, для построения нормального CICD, но понимания не встретил. Нет юнит тестов, нет привычного дебаггера с брейкпойнтами, культуры документирования и версионирования.
Люди есть. В начале пандемии СМИ тиражировали статьи что все пропало и последние разрабы умрут. На клич подтянулся народ, в основном из Индии, и зарегистрировался в проекте OpenMainframe. Около 2k профилей, но работы для них не нашлось.
Потому? Дело не в программерах. Ванильный Кобол, а именно спека COBOL85, прост как валенок, хватит и пары недель чтобы начать на нем писать. Сложность в тотальной закрытости стека и утрате знаний о бизнес процессах, куда эти кобольные модули встроены.
Бизнес портирования в Яву существует минимум лет 20. Главным игроком в нем является MicroFocus. Они пылесосят носителей знаний и предлагают перенос бизнес процессов. В группах жаловались, что после отжима знаний консультанта выкидывают "на мороз".
SpiderEkb
01.09.2023 15:45+3Компилятор его доступен только на мейнфреймах
Не только на менфреймах (IBM z), но и на миддлваре (IBM i). Не знаю точно какой там диалект, но КОБОЛ там есть, входит в группу языков ILE (интегрированная языковая среда) - COBOL, RPG, CL, C/C++
разработка и отладка либо через терминал, либо через плагин для VSCode, который делал подрядчик из Чехии
Для IBM i есть плагин IBM i Development Pack с поддержкой всех языков ILE. В т.ч. и КОБОЛ. Ну или через RDi - IDE от IBM на базе Eclipce
В рамках курса IBM даёт аккаунт на мейнфрейм.
Для IBM i есть публичный бесплатный сервер PUB400 - регистрируетесь, получаете аккаунт и работаете.
нет привычного дебаггера с брейкпойнтами
Привычный - это какой?
Для IBM i отладка возможна как в IDE (RDi, VSCode с плагинами), так и в терминале (встроенный отладчик STRDBG). С брейкпойнтами (в т.ч. и сервисными когда можно отлаживать программы, работающие в других заданиях, например, фоновых), отслеживанием изменения состояния переменных и т.п. Функциональности вполне достаточно.
Сложность в тотальной закрытости стека и утрате знаний о бизнес процессах, куда эти кобольные модули встроены.
Так это все равно на чем оно написано. Тут не в языке дело.
olku
01.09.2023 15:45Дебаггер, например, такой https://marketplace.visualstudio.com/items?itemName=OlegKunitsyn.gnucobol-debug
Да, бизнес модель такая. Которая перестает работать когда кто-то начинает играть иначе, по правилам сотрудничества, открытости и равноправия. Не сочтите за политику, а то уже прилетало в карму. :)
Hardcoin
01.09.2023 15:45В группах жаловались, что после отжима знаний консультанта выкидывают "на мороз".
После обучения английскому репетира тоже "выкидывают", но разве это странно? Зачем кому-то учиться всю жизнь у одного учителя?
SourenTopchian
01.09.2023 15:45+1COBOL первой свежести.
https://publibfp.dhe.ibm.com/epubs/pdf/igy6lr40.pdf
Fourth edition (31 August 2023 update)olku
01.09.2023 15:45Из всех живых (обновляемых) диалектов, ООП есть у Enterprise COBOL, хотя спека 2002 года.
saipr
01.09.2023 15:45+1Интересный факт:
в 1977 г. был принят отечественный стандарт на язык программирования КОБОЛ (ГОСТ 22558-77).
Нам COBOL преподавали в академии, и учебники по этому языку писали наши преподаватели:
Столько лет прошло, а мы говорим о COBOL-е. Интересно бы знать, что будут говорить через очередные 50 лет!
Alexander34
01.09.2023 15:45+3Через еще 50 лет ИИ оставит человеков жить лишь потому, что среди них надо будет искать тех, кто сможет поддерживать КОБОЛ.
saipr
01.09.2023 15:45Все эти ситуации в своё время (задолго до появления сегодняшнего понятия ИИ) описал Рэй Бредбери. Чего стоит один его рассказ "Вычислитель":
Я им не угоден или не нужен, — сказал он. — В наши дни машины лучше. На кой им черт старикашка, вроде меня, к тому же пристрастившийся к марсианской выпивке? Ни на кой! А машина не стареет, не выживает из ума и не напивается до чертиков!
QtRoS
01.09.2023 15:45Хм, а Java это точно удачный выбор? Наверняка в написанном на COBOL софте есть много взаимодействий с железом, которые будут переписаны... на JNI? В идеале для таких надёжных и требовательных систем бы взять Rust (да простят меня хейтеры языка), может куда интереснее получиться.
SpiderEkb
01.09.2023 15:45+5Крайне неудачный.
Эти системы в большинстве своем достаточно высоконвгружены и требуют предельной эффективности.
Прямой работы с железом там нет. Но арифметика на 99% с фиксированой точкой. В т.ч. операции типа "присвоение с округлением".
Также очень много занимает работа с БД. Как непосредственно с файлами (позиционирование по ключу и т.п.), так и средствами embedded sql (как статического, что быстрее, так и динамического когда других вариантов нет).
Все это реализовано на уровне языка.
Поактически нет динамической работы с памятью - выделение/освобождение суть лишние накладные расходы снижающие эффективность.
Ну и, наконец, в итоге получаем полноценный и быстро работающий программный объект, не требующий JVM, которая сама по себе ресурсы жрет.
rg_software
01.09.2023 15:45Я бы ещё добавил, что Java тоже не образец обратной совместимости, и если сейчас кого-то беспокоит, что есть три диалекта Кобола, то через 40 лет будут легаси системы на 10 несовместимых версиях Java, и для каждой будут нужны свои специалисты, вот уж решили проблему, называется.
Hivemaster
01.09.2023 15:45С чего это вдруг? Можете прямо сейчас скачать JDK 1.2, скомпилировать им что-нибудь и запустить на JRE 17. Можно и наоборот, так как все новые возможности в язык добавляются без нарушения совместимости. Единственная проблема, на которую можно наткнуться - желание новых JRE работать с модулями при отсутствии модульной системы до Java 9. Ничего более совместимого в мире просто нет.
rg_software
01.09.2023 15:45+2Увы, если бы это было так, но это даже близко не так. У меня есть JAR-файлы, которые прекрасно работали на 1.4, но не работают на 17. Ещё одна точка отсчёта -- Java 8, для которой тоже немало софта, не работающего под 17.
Мне надо раскопать архив, чтобы привести примеры, но это вот прямо настолько общее место в личном опыте, что даже странно слышать обратное. Стандартная история -- держать по четыре версии JVM на случай запуска того или иного софта.
sergey-gornostaev
01.09.2023 15:45Крайне интересно было бы услышать примеры. Пишу на Java уже лет двадцать, но с проблемами несовместимости не сталкивался ещё ни разу. Если не считать уже упомянутый Jigsaw.
vadimr
01.09.2023 15:45Например, у меня есть программы на Java, которые используют работу через jdbc работу с клиентом СУБД определённой версии, которая в настоящее время не поддерживается. Это не проблема самого языка Java, но реальный фактор, ограничивающий жизненный цикл приложений. А мейнфрейм бинарно совместим с 1966 года.
MTyrz
01.09.2023 15:45Где-то у меня лежит java-сервер для линейки, который емнип не запускается выше седьмой версии. Если интересно, могу попытаться его выкопать, попробовать запустить и, не знаю, логи ошибок вам выложить?
Kelbon
01.09.2023 15:45щас бы автоматически переписывать на язык, на котором всё лопнет при попытке компиляции, платформа под которую надо работать не поддержана, а на следующем релизе код перестанет работать
olku
01.09.2023 15:45+1Целевую платформу, вероятно, выбирал маркетинг. Дотнет и ява корпорациям ближе, но ява во времена принятия решения была более открытой и портируемой. Например, у GnuCOBOL нет своего компилятора, он транспилит в С, который компилируется уже тем что есть в системе.
SpiderEkb
01.09.2023 15:45+1Джва не дотянет. Там, где сократить общее время утилизации процессора на 3-5% считается хорошим результатом, аредаочтение всегда будет отдаваться языкам, выдающим полноценный исполняемый код.
GnuCOBOL вообще не в тему - это поделие для студентов. На используемых в данной области платформах есть нативные компиляторы.
olku
01.09.2023 15:45О, нашел свой коммент 2020 года:
На сейчас живых (разрабатываемых и выпущенных в 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.
Обесценивать вклад Simon Sobisch (немного с ним знаком) и других контирибьютеров в GnuCOBOL и экосистему Кобола вцелом несколько высокомерно. Технологии без людей мертвы. IBM сам же это и продемонстрировал.
SpiderEkb
01.09.2023 15:45+2Технологии без людей мертвы.
Технологии мертвы когда они не используются в реальных приложениях.
Сколько реально работающих коммерческих приложений написано на gnuCOBOL?
И сколько на IBM Enterprise COBOL... Просто сравните.
Тут еще надо понимать историю откуда все это взялось.
Когда большие компьютеры начали внедряться в коммерческие структуры потребовался язык для реализации именно коммерческих вычислений со всеми их особенностями. И вот тогда появился COBOL (аналогично тому как для математических расчетов был создан FORTRAN) случился "большой взрыв" - повальная автоматизация банков и крупных коммерческих структур.
Тут надо понимать что КОБОЛ не является языком общего назначения, но специализированным языком. И в этом у него не было конкурентов
За годы было написано огромное количество кода, который работает до сих пор. Это старый, быстрый, до блеска вылизанный код. И заменить его не так просто - это не просто переписать все, это еще все оттестировать по полной программе. И убедиться, что оно не только работает правильно, но и как минимум не медленнее на том же железе. Огромные затраты ресурсов, которые не окупятся.
И еще надо понимать, что под Win или Linux COBOL никому не нужен. Целевые платформы там, где он нужен, совсем другие - это или мейнфреймы типа IBM z, или мидлваре типа IBM i там, правда, у COBOL есть мощный конкурент - RPG на котором написано и пишется более 80% кода под эту платформу, который по возможностям для коммерческих расчетов как минимум не хуже COBOL но активно развивается и сейчас представляет собой нормальный процедурный язык (в синтаксисе четко ощущается привкус PL/I). И, кстати, это уже личный опыт, в своей области по быстродействию и ресурсоэффективности он как минимум не хуже С (а на С++ еще постараться надо чтобы оно было столько же быстрым и эффективным - минимум динамичесой работы с памятью, минимум всяких "безопасных копий объектов", минимум исключений). И что характерно, в том же RPG фактически нет UB, коими изобилует С/С++.
olku
01.09.2023 15:45Было бы интересно почитать про архитектуру таких систем и требования к ним. Выжимание рантайма до такта выглядит как вертикальное масштабирование. Но оно имеет предел, в том числе и экономический, поэтому сейчас так бурно развиваются распределенные системы. Когда-то давно попалась история архитектуры Гугла, когда они решили вместо больших дорогих ящиков ставить много дешёвых.
SpiderEkb
01.09.2023 15:45+1Здесь также. Почитайте про новые процессоры Power10.
Если кратко на пальцах, то там есть возможность объединения нескольких машин фактически в одну высокопроизводительной шиной. Контроллер шины непосредственно на кристалле процессора (т.е. фактически вы "сцепляете" процессоры друг с другом). При этом общим становится все, включая память. И для конечного пользователя все это выглядит как одна машина.
Но дело не в этом. Дело в том, чтобы то, что можно сделать просто написав оптимальный код без затрат на новое железо, должно делаться оптимизацией кода. Это быстрее и дешевле. Никто не побежит покупать новую машину в кластер только потому что кому-то по голове ударило концептуальностью и он наворотил 100500 уровней абстракций там, где это совсем не нужно.
Речь в целом идет о том, что есть вполне специфические задачи. И для решения этих специфических задач есть специализированные языки, наилучшим образом для этих задач предназначенные.
Если "приблизить физику к кухне". Вот бывает цепная пила, бывает циркулярная, бывает лобзик. Вам нужно порезать большой лист фанеры на прямоугольники. Можно сделать это цепной пилой, но получится плохо. Можно лобзиком, но получится криво. А можно это ровно и быстро сделать циркуляркой.
А вот попилить дрова можно и циркуляркой, но неудобно - тут лучше цепная пила подойдет.
Так и здесь. Зачем искать какие-то библиотеки для джавы для работы с фиксированной точкой и плодить зависимости, когда у меня в том же RPG такие типы поддерживаются на уровне языка.
Аналогично для работы с датами и временем - есть типы, есть набор функций (арифметика, поддержка конвертации в разные типы, поддержка множества форматов). Операция типа "взять дату в виде строки в формате EUR (DD.MM.YYYY) вычесть из нее один месяц и вывести в строку в формате ISO (YYYY-MM-DD)" пишется в одну строчку средствами языка.
Но на самом деле все еще сложнее. На используемой нами платформе (IBM i) используется ILE которая поддерживает несколько языков - RPG, CL, COBOL, C, C++. И все ILE компиляторы генерируют одинаковый код в MI (ассемблер тут недоступен на пользовательском уровне). В результате получается т.н. "модуль" (аналог объектного файла). Несколько модулей собираются (bind) в один программный объект (pgm) и тут уже все равно на каком языке написан тот или иной модуль.
Совершенно нормальным является писать на (например) RPG то, что удобнее писать на RPG, на С то, что удобнее писать на С (например, какие-то низкоуровневые вещи) и потом объединять это в одну программу. Тут главное правильно прототипы описать для вызовов функций на разных языках. Еще более того - я из кода на RPG могу вызывать любую функцию из, например, С-шной библиотеки просто описав ее прототип. Пример:
//============================================================================== // Текущее время в секундах с точностью до мкс //============================================================================== dcl-proc GetTime; dcl-pi *n packed(16: 6); end-pi; dcl-ds t_dsTimeVal qualified template align(*full); tv_sec int(10) inz; tv_usec int(10) inz; end-ds; dcl-ds t_dsTimeZone qualified template align(*full); tz_minuteswest int(10) inz; tz_dsttime int(10) inz; end-ds; dcl-pr GetTimeofDay int(10) extproc(*CWIDEN : 'gettimeofday'); dsTime likeds(t_dsTimeVal); dsZone likeds(t_dsTimeZone) options(*omit); end-pr; dcl-ds dsTimeVal likeds(t_dsTimeVal) inz(*likeds); dcl-s pktTime packed(16: 6) inz(*zero); dcl-s fltSecs float(8); dcl-s fltUSecs float(8); if GetTimeofDay(dsTimeVal: *omit) = 0; fltSecs = dsTimeVal.tv_sec; fltUSecs = dsTimeVal.tv_usec; fltUSecs /= 1000000; pktTime = fltSecs + fltUSecs; endif; return pktTime; begsr *pssr; dump; endsr; end-proc;Нужно мне в RPG время в формате секунды.микросекунды в переменной с фиксированной точкой (packed(16: 6) - 16 знаков, 6 после запятой). Ок. Используем сишную функцию gettimeofday просто описав ее прототип так, что его понял компилzтор RPG
dcl-pr GetTimeofDay int(10) extproc(*CWIDEN : 'gettimeofday'); dsTime likeds(t_dsTimeVal); dsZone likeds(t_dsTimeZone) options(*omit); end-pr;указываем что GetTimeofDay на самом деле есть внешняя функция gettimeofday. И это работает.
Но и это еще не все. Каждый программный объект кроме исполняемого кода содержит еще MI код из которого он был сгенерирован. И метку для какого процессор он был сгенерирован. Переносим программу с машины на Power9 на новую машину на Power10, запускаем и при первом запуске система видит что исполлняемый код для другого процессора и автоматом его перегенерирует из MI под текущий процессор. Т.о. автоматом всегда получаем оптимальный исполняемый код для той архитектуры на которой сейчас работает программа.
И вы предлагаете от всего этого отказаться и переписать все на джаву потому что это сейчас модно? Серьезно? Вы потратите на это куеву хучу времени и сил. Вам придется решать куеву хучу проблем - "а как это написать на джава если в ней и близко нет ничего подобного"? Потом нужен полный ретест (компонентный, бизнес, нагрузочный, интеграционный...) всего что переписали... И в итоге что? Будет оно быстрее работать? Ой не факт... скорее всего нет (т.е. пройдите в кассу и купить еще пару-тройку серверов?).
И все ради чего? Чтобы была возможность нанимать джава-джунов, которые вам кривыми руками запоганят все что с таким трудом переписали?
Наша практика показывает что если взять человека с опытом разработки (не важно на чем, лишь бы умел читать ТЗ и переводить его в алгоритм), то через полтора-два месяца он осваивает базовые принципы и синтаксиc того же RPG + основы работы в системе IBM i (которая вообще ни на что не похожа - там "все есть объект", свои принципы организации файловой системы, и вообще все свое) и готов решать несложные "боевые" задачи. А через год-полтора это уже крепкий мидл (а то и сеньор, в зависимости от начального опыта).
И это проще и дешевле, чем натягивать сову на глобус и пытаться все переписать под "современный модный стек" который по большому счету не является нативным для этой системы.
CptAFK
01.09.2023 15:45Тем временем НСПК (Карты МИР) не согласится с вами, что Java плохой выбор для решения таких задач.
https://habr.com/ru/companies/oleg-bunin/articles/695262/
У Java есть главное преимущество, нет привязки к конкретному типу аппаратного обеспечения.
SpiderEkb
01.09.2023 15:45+2Обрабатывает более 50 миллионов операций;
Генерит более 3 000 различных файлов и отчётов для банков;
Получает данные из большого количества ключевых систем Мир Plat.Form, а также является источником транзакционных данных;
Обеспечивает строгий SLA на каждом этапе работы. Так как важно, чтобы все расчёты происходили точно, в срок и без ошибок.
Ну ок. А теперь смотрим всего лишь один банк. Точнее, даже не весь банк, а только ядро АБС.
27 тыс. программных объектов
15 тыс. таблиц и индексов базы данных
Более 150 программных комплексов
Занимает более 30 Терабайт дискового пространства
В день изменяется более 1,5 Терабайт информации в БД
За день выполняется более 100 млн. бизнес операций
Одновременно обслуживается более 10 тыс. процессов
только в процедуре закрытия дня производится более 500 миллионов изменений в БДИ банк - это не только счета-проводки. Это огромное количество клиентских данных. Это контроль каждого платежа. Это огромное количество отчетов (3тысячи? Ха... детский лепет), это рассылка различных уведомлений (как клиентам, так и различным структурам) в самых разных форматах.
И все это только один банк (ну пусть крупный, пусть из топ-10, но все равно один банк).
Думаете не пробовали джаву? Пробовали. Не тянет оно. Жрет ресурсы как не в себя и тормозит. В результате она осталась на всяких внешних системах (коих в банке порядка 60-ти штук) которые не являются mission critical. А на ядре совсем другой стек.
FlashHaos
01.09.2023 15:45+2Те числа, которые вы привели, вполне соразмерны показателям АБС сбера, который тоже весь работает на джаве и по большей части на х86.
Просто для перехода надо взять и заварить кашу на весь банк в десять лет длительностью. В рыночных условиях это сложно.
SpiderEkb
01.09.2023 15:45Естественно. Банки сравнимы. Вопрос в том, сколько серверов у сбера и сколько у нас :-) И во сколько обойдется сберу перенести все на новые сервера и во сколько это обойдется нам (опыт перехода с 8xx серверов на 9хх у нас есть - ничего страшного в этом нет).
Ну я не могу с уверенностью сказать что у сбера джава именно на уровне ядра АБС...
yrub
01.09.2023 15:45слушайте, джава очень много где и все ее недостатки известны, это дополнительная память и медленный старт. ну и еще унификация, из-за которой у вас может не быть какого-то модного api из OC, или если вы прям очень много делаете запросов к какому-то другому нативному коду, например в dll. так что все эти рассказы про тормозящую java рассчитаны на тех, кто в середине нулевых застрял :) в худшем случае вы потеряете по скорости в 2 раза (если мерять приложение целиком), но при этом получите огромное количество плюсов начиная от написания кода, заканчивая средствами мониторинга и управления.
паузы уже починили со сборщиком zgc, они меньше миллисекунды.
в принципе и с памятью/временем старта тоже разобрались через нативную компиляцию с graalvm.
SpiderEkb
01.09.2023 15:45+1если вы прям очень много делаете запросов к какому-то другому нативному коду, например в dll
Банковская система - это не одна большая программа. Это куча разных модулей запускаемых для выполнения конкретных задач (тут ближе всего модель акторов). Большинство модулей job-isolatetd - работают в разных заданиях (выпадение в дамп одного вообще никак не влияет на все остальное). Но они между собой все взаимодействуют разными способами (а способов тут очень много всяких и разных, например, в системе есть такой объект как USRQ - пользовательская очередь, очень удобно для организации всяких конвейеров, но работа с ним только на низком уровне через MI).
в худшем случае вы потеряете по скорости в 2 раза
Для наших реалий это катастрофа.
Делал тут комплекс проверок для системы расчетов (контроль платежей). Плотность вызовов зашкаливает (каждый платеж идет через эти проверки). Нагрузку прошли, внедрение согласовано. Но анализируя (для себя уже) PEX-статистику (результат нагрузочного тестирования), увидел одну вещь, которая не понравилась. Потратил немного времени, переписал. В итоге:
Утилизация ЦП на 1 вызов (до/после):
CPOCHK#ACC - 372 мксек / 357 мксек
CPOCHK#BAN - 1,5 мксек / 0,4 мксек
CPOCHK#CRE - 200 мксек / 88 мксек
CPOCHK#DEP - 39 мксек / 37 мксек
CPOCHK#INR - 0,9 мксек / 0,2 мксек
CPOCHK#MIN - 6,8 мксек / 4,5 мксек
CPOCHK#RR - 13 мксек / 8,4 мксек
CPOCHK#SGM - 9,5 мксек / 6 мксек
CPOCHK#SPI - 6,3 мксек / 2,4 мксек
CPOCHK#WHL - 8,9 мксек / 5,8 мксек
CPOSRVPGM / CPOCHK#HD - 51 мксек / 38 мксек
Заключение
Доработка положительно влияет на производительность функционала.
Совокупное потребление процессорного времени сократилось на 20%.
Вот за что бьемся. И это не потому что "сервер не тянет". Просто есть нормативы внутренние на предельную загрузку сервера. Запас по процессору должен быть всегда. Даже в периоды пиковых нагрузок. Это надежность и безопасность. Поэтому любой код должен быть максимально эффективен прежде всего.
А вы говорите в два раза...
но при этом получите огромное количество плюсов начиная от написания кода, заканчивая средствами мониторинга и управления
Какие именно плюсы в "написании кода" я получу?
Что касается мониторинга и управления, то тут он и без того хорош. Просто не сталкивались с подобными системами. Тут все работает в отдельных заданиях - зашли терминалом на сервер - вот вам задание. Запустили что-то в фоне (submit job) - вот еще одно задание. У каждого задания могут быть свои настройки и права...
Система позволяет мониторить все - видеть джоблоги в реальном времени, видеть статус каждого задания и сколько ресурсов оно потребляет (процессор, ввод-вывод, открытые файлы и т.п.), управлять заданиями (вплоть до принудительного закрытия).
Никакая джава не даст вам таких возможностей.
yrub
01.09.2023 15:45Поэтому любой код должен быть максимально эффективен прежде всего.
любой код должен в первую очередь работать без ошибок, потом желательно чтобы он был понятным остальным, потом чтобы он работал и через 30 лет на другом железе, те его не пришлось переделывать заново. потом можно уже и на скорости заморочиться. эффективность важна там где есть прямая зависимость на прибыль. ну те если бы из-за просадки в скорости на эти 2 раза платежи не проходили и люди доставали налик - да, а так вопрос только в цене покупки второй машины. если она стоит 5 миллионов, а зп в фирме 500 и работает с десяток человек, то да, эта оптимизация имеет смысл, иначе - нет. не так просто большие компании сидят на java, например twitter, им проще заниматься ее оптимизаций, чем писать все на плюсах.
Система позволяет мониторить все - видеть джоблоги в реальном времени, видеть статус каждого задания и сколько ресурсов оно потребляет (процессор, ввод-вывод, открытые файлы и т.п.), управлять заданиями (вплоть до принудительного закрытия).
вы видимо плохо знаете java ;) все это есть и для этого не надо колупаться в "мозгах" ОС. можно даже код приложения на лету обновить.
avost
01.09.2023 15:45+1Думаете не пробовали джаву? Пробовали. Не тянет оно.
Почему не тянет? Очень даже тянет. Везде, где нет вот этого легаси-кобола и унаследованных мейнфреймов тянет и хорошо тянет. А там где сохранилось менфреймовое ядро, его снаружи обвешивают конверторами и сервисами на той же яве и постепенно откусывают от ядра куски опять же в пользу явы. Я работал с банками из первого примера и собеседовался с банками из второго (как раз эти адаптеры надо было писать). А ещё успел поделать немножко торговли на чикагской мерчант бирже. Там не фондовая и нет HFT, а с не хай фриквенси торговлей ява вполне справляется (но работа с памятью глубока затюнена, да).
А на ядре совсем другой стек.
Неа. Та же самая ява. Зоопарк стеков невыгоден. Он остался в легаси и специальных случаях, вроде HFT.
И все это только один банк (ну пусть крупный, пусть из топ-10, но все равно один банк).
Это вы про какой?
SpiderEkb
01.09.2023 15:45+1А там где сохранилось менфреймовое ядро, его снаружи обвешивают конверторами и сервисами на той же яве и постепенно откусывают от ядра куски опять же в пользу явы.
Ядро как раз и обеспечивает всю основную бизнес-логику. Это mission critical часть. Сервисы на джаве - это внешние интерфейсы для других систем. Не более того. Делаются они не потому что "джава лучше", а для того, что не вешать на ядро то, чего там не должно быть. Как пример - ядро не должно заниматься всякой ерундой типа отсылки всяких уведомлений (смс, почта и т.п.). Оно просто формирует данные и "выпихивает" их во внешнюю систему. А та уже делает все эти подробности.
Мобильное приложение не имеет доступа к БД. Ему дают REST API, которое завязано на вебсервисы, формирующие запрос к ядру, получающие от него ответ и отдающие приложению. Ядро вообще изолировано от внешенего мира ("Б" - безопасность), находится во внутреннем контуре и общаться с ним можно только через запросы (очереди, вебсервисы...)
Нашумевшая ситуация в начале пандемии когда "мейнфремы начали падать под нагрузкой":
Хороший пример этого можно наблюдать во время пандемии. В первые дни Covid-19 бизнесы массово закрывались. Уволенные сотрудники рванулись онлайн, чтобы подать заявление на получение пособий по безработице, и веб-сайты многих правительств штатов не выдержали нагрузки. Губернатор Нью-Джерси сообщил прессе, что их системы COBOL отчаянно нуждаются в помощи, чтобы справиться с новыми потребностями. «У нас в буквальном смысле есть системы, которым от сорока и более лет», — заявил он.
Но технологи, работавшие за кулисами над устранением неполадок, знали, проблема заключалась не в перемалывающем числа COBOL. Эти старые системы работали хорошо. Нет, всегда ломались более новые элементы — программы, управлявшие самим веб-сайтом.
«С ума сходило веб-приложение между мейнфреймом и внешним миром. Именно оно падало», — рассказывает программистка и писательница Марианна Беллотти, годами работавшая с государственными системами и следившая за этой системой Нью-Джерси. Но, по словам историка Хикса, властям было слишком неудобно признать «ой, да, это сломались наши веб-системы».
Беллотти наблюдала подобные явления и в других государственных органах, например в Налоговом управлении США (IRS). Однажды её вызвали для помощи с неработающим веб-приложением IRS. После расследования выяснилось, что проблема и в самом деле была в новых программах, «в куске плохо написанного кода на Java». Мейнфрейм с запущенным COBOL, напротив, гнал вперёд подобно Ferrari.Да, неудобненько вышло, но таковы факты...
Kenya-West
01.09.2023 15:45У Java есть главное преимущество
Причем преимущество не уникальное до такой степени, что оно есть практически у каждого мейнстримного языка и платформы: JavaScript (Node / Deno), Python, .NET (C#, за остальные не скажу).
Пишу как кодер в одном из немногих, если не единственном, банке в России, который от начала и до конца работает на .NET
yrub
01.09.2023 15:45может куда интереснее получиться
последнее что надо банкам это эксперименты, они деньги в первую очередь зарабатывают. им желательно 1 раз купить и лет 40 пользоваться
SpiderEkb
01.09.2023 15:45Да. Банк зарабатывает деньги. И умеет их считать. И понимает когда лучше купить дорогую, мощную, но надежную систему, а когда можно обойтись чем-то подешевле.
И там надежность и стабильность на первом месте. Отсюда и выбор технологических стеков специфический.
Factivist
01.09.2023 15:45+2Скорее всего, о проекте IBM мы ещё услышим в конце года
Когда начнут сыпаться первые "жертвы" модернизации. С миллионными потерями.
M_AJ
Проблема ведь не в синтаксисе, если бы дело было только в этом, то проблемы не было бы вообще — горшки не боги обжигают, и нет никакой проблемы в том, чтобы выучить COBOL, как люди учат С или Lua. Подозреваю, что настоящая ценность коболистов вовсе не в самом Коболе, а в понимании работы систем, которые на нем написаны — им не нужно вникать с нуля, поэтому они могут выполнить работу в разы быстрее и потому дешевле, за что их и нанимают. Ситуация примерно как с 1С-программистам, основная ценность которых не в том, что они умеют программировать кириллическими буквами, а в значении самой предменой области.
SpiderEkb
В целом - да. Так и есть. Не зная особенности системы (а это достаточно специфические системы, не линух с виндой, там свои законы) нормальный код не напишешь. Ни на чем.