В 2023 году языку COBOL исполнилось уже 64 года. Это один из старейших языков программирования, которые применяются на практике. Кроме того, он же — один из лидеров по объему написанного кода. Язык не собирается умирать, наоборот, он развивается. Конечно, конкурентом популярным ныне ЯП он не является, причины его популярности в другом. Об этом поговорим под катом.
Почему COBOL до сих пор популярен?
Если говорить о том, насколько язык активно используется, то с этим все отлично. Согласно данным компании Micro Focus, ежедневно в мире используется около 775-850 млн строк кода Cobol. К сожалению, методику исследования компания не раскрывает, но, пока эти результаты никто не опровергал.
Кстати, результаты другого исследования от 2017 года показывают, что около 95 % банкоматов в мире используют код COBOL, а продукты на базе этого ЯП обрабатывают транзакций примерно на $3 трлн. (это не опечатка) в год. Вероятно, сейчас эти показатели снизились, но явно не до нуля, поскольку даже за 6 лет перевести все банкоматы в мире на современные ОС невозможно.
Эксперты называют несколько причин того, что устаревший, без всяких сомнений, язык востребован до сих пор:
Надежность: COBOL известен своей надежностью и стабильностью, поскольку он был протестирован буквально несколькими поколениями разработчиков. Он же совершенствовался на протяжении десятилетий использования. Программы COBOL редко выходят из строя или вызывают ошибки, что крайне важно для критически важных систем, работающих с конфиденциальной информацией и деньгами.
Эффективность: COBOL оптимизирован для обработки больших объемов данных и транзакций, что делает его быстрым и ресурсоэффективным. Программы COBOL могут работать на недорогом аппаратном и программном обеспечении, что снижает эксплуатационные расходы организаций.
Масштабируемость: COBOL может справляться с растущими рабочими нагрузками и требованиями без ущерба для производительности и качества. Программы COBOL могут работать на мэйнфреймах, серверах, облачных платформах и даже мобильных устройствах, что обеспечивает им гибкость и адаптируемость.
Совместимость. COBOL может работать с другими языками и технологиями, такими как Java, C#, SQL, XML или веб-службами, через различные интерфейсы и платформы. Это позволяет COBOL интегрироваться с новыми системами и платформами и использовать их возможности.
Продолжает язык и совершенствоваться. Так, в стандарте COBOL-2002 были добавлены возможности для объектно-ориентированного программирования. Кроме того, в стандарте COBOL 2014 появилась поддержка спецификации вычислений с плавающей запятой IEEE-754, перегрузки методов и динамически расширяемых таблиц.
Для COBOL выпускаются новые продукты. Например, несколько месяцев назад был опубликован релиз компилятора GnuCOBOL 3.2, позволяющего транслировать программы на языке COBOL в представление на языке Си для последующей компиляции при помощи GCC или других Си-компиляторов. Этот продукт работает с 19 разными «диалектами» ЯП, он частично поддерживает спецификацию COBOL 2014 и проходит 9740 тестов из набора для проверки совместимости с COBOL 85. При необходимости можно использовать встроенный отладчик.
На текущий момент общий объём написанного на COBOL кода оценивается в 220 млрд строк, из которых 100 млрд используются до сих пор. В основном — в финансовых учреждениях. По состоянию на 2017 год 43 % банковских систем продолжали использовать COBOL, код на COBOL применялся при обработке около 80 % персональных финансовых транзакций и в 95 % терминалов для приёма платежей по банковским картам.
Сейчас COBOL находится примерно на 34 месте рейтинга ЯП по версии IEEE.
Что дальше?
Сомнений в том, что COBOL будет применяться еще долгие годы, нет. Уж слишком масштабна инфраструктура, которая зависит от этого языка программирования. Тем не менее, постепенно реализуется переход с COBOL на современные языки программирования.
Не все и не всегда проходит гладко. Так, например, несколько лет назад Commonwealth Bank of Australia попробовал переписать ядро системы на новом языке. Переход состоялся, но на проект ушло около 1 млрд австралийских долларов — это в несколько раз больше, чем планировалось.
Некоторые организации не справились с переходом — было либо слишком дорого, либо слишком сложно, а во многих случаях и то, и другое. Но, как и говорилось выше, постепенно появляются новые инструменты, которые помогают мигрировать с одного ЯП на другой. Один из наиболее перспективных инструментов — проект от IBM, который получил название Watsonx Code Assistant.
Его тестируют некоторые клиенты и партнеры IBM, а в конце 2023/ начале 2024 года начнется уже коммерческая реализация. В первую очередь, этот инструмент предлагается нынешним и будущим владельцам мейнфреймов Z‑серии производства корпорации IBM.
Инструмент спроектирован таким образом, что Java‑код, создаваемый при помощи Watsonx Code Assistant, будет объектно‑ориентированным. Но он по‑прежнему будет взаимодействовать с оставшимися компонентами систем, написанными на COBOL, утверждает IBM, а. Кроме того, он же будет нормально взаимодействовать с такими ключевыми сервисами, как CICS, IMS, DB2 и др.
Если все получится, то зависимость от COBOL у большинства организаций если не снизится до нуля, то станет гораздо менее сильной. Кроме того, расширится круг специалистов, которые смогут обслуживать программно‑аппаратные комплексы как частных, так и государственных организаций. Более того, в будущем этот софт будет гораздо проще перенести на новую инфраструктуру со старого «железа».
Но в любом случае, COBOL будет оставаться востребованным нишевым языком еще в течение многих лет. Минимум трех, а скорее всего, пяти, а то и дольше.
Комментарии (44)
scorpion1574
27.11.2023 11:33+1Почему с такими преимуществами языка как описано в статье, его не используют повсеместно в проектах?
romxx
27.11.2023 11:33+1А что, разве на рынке ЯП "надежность, эффективность, масштабируемость и совместимость" есть только у Кобола?
GBR-613
27.11.2023 11:33+2В Коболе есть кое-какие вещи, которые рассчитанны на аппаратуру мейнфремов и которые в "обычных" процессорах (Intel, ARM...) просто не существуют. Их можно эмулировать, но работать будет медленно. (По нынешним временам не так уж и медленно, но ещё 20 лет назад это было неприемлемо.)
Поэтому компиляторы Кобола для "обычных" компьютеров и "нормальных" операционных систем очень долго никто не писал. А когда все таки стали, выяснилось, что и без них языков выше крыши. Поэтому все привыкли обходяться без него. А лет 10 тому назад американский Federal Reserve System объявил Коболу войну.
SpiderEkb
27.11.2023 11:33+2Нет. Но в той области где он применяется, конкурентов ему не так много.
Попробуйте написать на привычном вам ЯП задачку, где надо сделать из БД выборку по нескольким таблицам (SQL с join'ами) и как-то ее обработать.
Причем:
В полученной выборке будет поля типов NUMERIC, DECIMAL, DATE, TIME, VARCHAR
Для повышения скорости работы при множественных вызовах быстрее использовать т.н. "статический SQL". Т.е. непосредственную вставку SQL в код программы типа exec sql select ... from ... где сам запрос будет валилидироваться на этапе компиляции и на этапе же компиляции будет построен план запроса - в рантайме на это уже не будет тратиться время
Время не должно тратиться (предположите что эта штука будет вызываться 100 000 000 раз в стуки) на создание всяких "объектов-оберток" для полей полученных из выборки - просто описали соотв. статическую структуру (безо всяких конструкторов, просто байтовый буфер с размеченными полями), прочитали туда очередную запись и работаем с полями структуры - это обычные переменные, не объекты.
Написав одно и то же на COBOL и условной Java или C#, обнаружите, что программа на COBOL на одном и том же железе не только быстрее, но еще и памяти меньше потребляет и ресурсов процессора.
Но это касается только вот таких специфических задач (интенсивная работа с БД в больших объемах и коммерческие вычисления). Писать что-то иное на COBOL будет очень больно.
MountainGoat
27.11.2023 11:33+2эта штука будет вызываться 100 000 000 раз в стуки
Звучит как "где ещё вы найдёте слесаря, который сделает подшипник не выходя из запоя?"
Такая задача банально не выключается, а висит себе сервисом и дёргается по API. Поэтому можно валидировать SQL и создать временные объекты один раз - на старте. А значит и написать это можно на чём угодно - ко второму прогону даже JavaScript уже заJITится достаточно для приемлемой скорости.
jobless
27.11.2023 11:33Звучит как "где ещё вы найдёте слесаря, который сделает подшипник не выходя из запоя?"
В середине 90х в одном миллионнике я принимал активнейшее участи в спасении многопарного(кажется 12 пар) оптического кабеля в металлическом корпусе. Разбирали "на золото" ЕС-103X(не помню точную модель) и буквально ногой выбивал ножовку по металлу у того кто пытался перепилить этот неподъёмный кабель. Была задействована единственная пара под единственный ЕС-7927 в паре километров от ВЦ. Пилить под новые разъёмы не судьба, на тот момент в городе был единственный человек у телевизионщиков который учился в Питере на сварщика оптики и он понятия не имел что с нашей делать. Была найдена фирма в Зеленограде, которая уже имела такой опыт и делала конвертор оптика(старорежимная) - эзернет(коаксиал). Разъём назывался ЛУ-6 или ЛУ-6(Булава), отличались шагом резьбы. Так вот именно по причине запоя токаря Зеленоград сорвал сроки и по портил кучу нервов ибо никто не понимал заработает ли оно вообще и ожидание было невыносимым. Заработало!!!
AccountForHabr
27.11.2023 11:33+1При таких вводных проще будет сразу писать хранимую процедуру в бд.
p.s. зачем план запроса строить на этапе компиляции?
Cубд умеют кэшировать планы запросов.
Планы запросов имеют тенденцию устаревать - ну там статистка, индексы и вот это все
entryAlloc
27.11.2023 11:33вариантов решения этой задачи много, зависит от конкретных вводных, уверен что можно найти решение без использования COBOL)
Kanut
27.11.2023 11:33+1Например потому что писать на нём это боль :)
RichardBlanck
27.11.2023 11:33Да ладно. Мне когда-то очень нравилось. Просто, мощно, лаконично.
Kanut
27.11.2023 11:33Когда-то я с удовольствием играл в Dark Sun: Shattered Lands с её разрешением экрана 320x200.
Но когда я пару лет назад пытался вспомнить молодость, то почему-то это самое разрешение 320x200 превратилось в боль :)
Dynasaur
27.11.2023 11:33А какие преимущества? Операции с плавающей точкой добавили в 2014! Круто! :-)
SpiderEkb
27.11.2023 11:33Там, где используется кобол (финансовые расчеты) они нафиг не нужны (хотя бы потому что с ними будут накапливаться ошибки округления). Все операции там проводятся с фиксированной точкой. А поддержка этих типов в кобол заложена "с рождения".
Так что добавили их туда "чтобы было", реальной потребности в том нет.
Dynasaur
27.11.2023 11:33+1ну да, конечно, ни одного статистического отчёта не построить без них, ни одного прогноза. Конечно, для деревянной системы, которая умеет только в дебет-кредит этого не надо. Вот в них он и работает :-)))
Dynasaur
27.11.2023 11:33Понятие "финансовая математика" там_где_используется_кобол тоже не ведомо. Расчёт рисков там всякий, ну его
SpiderEkb
27.11.2023 11:33Во-первых, нетрадиционный синтакис.
Во-вторых, это не ЯП общего назначения, это специализированный ЯП для коммерческих расчетов. Т.е. ниша его эффективного использования достаточно узка.
IvanPetrof
27.11.2023 11:33Вот всегда интересовало, что там такого специализированного?
SpiderEkb
27.11.2023 11:33+2Это сложно объяснить тому, кто ни разу не сталкивался. Правда. Я неоднократно пытался донести эту мысль, но практически всегда неудачно. Основные аргументы "против" такие:
"Ну и что что нужен SQL в коде? У меня вот есть библиотека ... которая позволяет выполнять SQL запросы из программы". Тут пытаешь объяснить разницу между "библиотекой" где для любого запроса план каждый раз будет готовится в рантайме (а на это запросто может уйти процентов 30 времени и столько же ресурсов процессора - это наши объективно замеренные статистики) и embedded sql поддерживаемый компилятором языка, который не только провалидирует запрос на этапе компиляции, но и на этапе компиляции же его план построит, экономя время в рантайме.
"А вот в Java есть BigDecimal - это тоже самое что DECIMAL в БД". Не тоже самое. Во-первых, это не нативный тип, а класс-обертка. Во-вторых, в памяти он представлен совсем иначе, нежели DECIMAL на диске в записи. И вы не можете объявить переменную типа BigDecimal (как вы объявляете, например int), просто скопировать туда кусок буфера с диска и потом с ней работать. Вам потребуется объявить объект класса, вызвать его конструктор и т.п. А это все время и ресурсы процессора.
В COBOL все типы данных, что есть в БД поддерживаются нативно. Т.е. там есть и фиксированная точка (аналоги DECIMAL, NUMERIC) и дата-время и таймштампы и VARCHAR. Там не надо никаких оберток - просто объявляете структуру (с точки зрения COBOL это просто байтовый буфер - кусок памяти заданного размера внутри которого размечены поля-члены структуры) с полями соотв. типов, читаете туда запись и дальше без никаких лишних телодвижений уже работает с полями структуры. Т.е. экономите время на вызовы всяких конструкторов для объектов-оберток.
Напомню что все это работает главным образом на больших серверах, где одновременно крутятся десятки тысяч самых разных бизнес-процессов, за сутки сотни миллионов (если не миллиарды) бизнес-операций выполняется, терабайты (а то и десятки терабайт) в сутки изменений в БД.
И часто это банки, которые предпочитают все данные хранить во внутреннем периметре, т.е. "купить еще один сервер в облаке" для них не вариант.
Такая вот специфика... И да. Не COBOL'ом единым. Есть и другие (как минимум один знаю и с ним работаю) специализированные языки такой направленности. Есть даже целые специализированные платформы (дорого, но очень эффективно и очень надежно) для таких задач.
И да. Вне всей этой специфики, такие языки нафиг не нужны.
Kanut
27.11.2023 11:33Тут пытаешь объяснить разницу между "библиотекой" где для любого запроса план каждый раз будет готовится в рантайме
Вы же в курсе что большинство таких "библиотек" давно уже поддерживают эту вашу "прекомпиляцию" SQL запросов?
SpiderEkb
27.11.2023 11:33+1Интересно, каким образом? На этапе компиляции "библиотека" еще не работает. Это должен быть компилятор (или предкомпилятор). Который еще и проверит - а куда ты собираешься получать результат запроса, а совпадает ли объявление структуры с форматом результата запроса...
Максимум что может библиотека - сделать план и закешировать его при первом вызове.
Но основная проблема будет с типами переменных. Которых в обычных ЯП просто нет.
Я все это не просто так - все это пробовал - С/С++ в сравнении со специальным языком. А потом все это через Performance Explorer прогоняется. И там сразу видно - тут пара процентов времени на "лишние" операции в С/С++, там три процента...
Даже код более громоздкий получается...
IvanPetrof
27.11.2023 11:33Т.е. Что-то типа pl/sql?
SpiderEkb
27.11.2023 11:33IBM i (AS/400) + RPG Ну и до кучи еще ILE (с возможностью использовать как RPG, так и С/С++ одновременно). Ну и немножко CL где надо.
Выглядит примерно так:
dcl-c maxLogLevels const(100); dcl-ds t_dsSettings qualified template; PgmName char(50); LogLevel char(50); LimitT char(50); LimitB char(50); LimitE char(50); end-ds; dcl-ds dsSettings likeds(t_dsSettings) dim(maxLogLevels) static; exec sql declare curECLSettings cursor for select A.EC0VAL, coalesce(B.EC0VAL, 'E'), coalesce(C.EC0VAL, 'D002'), coalesce(D.EC0VAL, 'M001'), coalesce(E.EC0VAL, 'M001') from EC0PF A left join EC0PF B on (B.EC0GRP, B.EC0PRM, B.EC0ACT) = (A.EC0GRP, 'LOGEVT', 'Y') left join EC0PF C on (C.EC0GRP, C.EC0PRM, C.EC0ACT) = (A.EC0GRP, 'LOGDEEPT', 'Y') left join EC0PF D on (D.EC0GRP, D.EC0PRM, D.EC0ACT) = (A.EC0GRP, 'LOGDEEPB', 'Y') left join EC0PF E on (E.EC0GRP, E.EC0PRM, E.EC0ACT) = (A.EC0GRP, 'LOGDEEPE', 'Y') where A.EC0PRM = 'PGMNAME' and A.EC0ACT = 'Y';Потом
exec sql close curECLSettings;И дальше в цикле
exec sql fetch curECLSettings for :maxLogLevels rows into :dsSettings;чтение блоками по maxLogLevels = 100 записей в массив структур dsSettings
Все типы данных SQL имеют соответствие в RPG
Если чего нет (BLOB, CLOB...) - объявляется через sqltype
dcl-s Blob sqltype(BLOB:1000000) ; dcl-s BlobLocator sqltype(BLOB_LOCATOR) ; dcl-s Clob sqltype(CLOB:1000) ; dcl-s ClobLocator sqltype(CLOB_LOCATOR) ;Все это объявления на уровне компилятора. Никаких объектов, никаких конструкторов в рантайме не будет. Объявил переменную и работаешь с ней.
С COBOL не работал, хотя у нас он тоже поддерживается (не знаю какой уж стандарт), но там все примерно также плюс-минус.
Программы с интегрированным SQL компилятся в два прохода - сначала SQL-препроцессор, потом уже основной RPG компилятор.
В С/С++ тут тоже можно SQL вставлять, но там проблемы с типами - напрямую поддерживается только _Decimal(n,p) в С и _DecimalT<n,p> в С++
Для всего остального уже "обертки" нужны.
Kanut
27.11.2023 11:33+1На этапе компиляции "библиотека" еще не работает.
Зависит от библиотеки. Плюс в самом крайнем случае вы это можете и "ручками" прописать.
Который еще и проверит - а куда ты собираешься получать результат запроса, а совпадает ли объявление структуры с форматом результата запроса...
Ну это как раз таки делается даже если вы не прекомпилируете.
SpiderEkb
27.11.2023 11:33Зависит от библиотеки. Плюс в самом крайнем случае вы это можете и "ручками" прописать.
Зачем, есть все это у меня уже есть?
Ну это как раз таки делается даже если вы не прекомпилируете.
На каком этапе? Вот ошибся в синтаксисе запроса - должен получить ошибку с указанием - "вот тут у тебя фигня какая-то" на этапе компиляции.
Ошибся с типами хост-переменной куда результат запроса приходит - получи ошибку при компиляции "тут тип неправильный".
Там еще много чего... Например, резалсеты. Я могу из своей программы в вызывающую вернуть SQL resultset (выборку) причем, как результат работы курсора, так и из памяти - массив структур заполнил и вернул его в виде резалтсета вызывающему
EXEC SQL declare Cursor cursor with return to client for SELECT S01PS AS $$PS, S01DSC AS $$DSC FROM S01PF WHERE S01EXF = :iParms.EXF AND TRIM(S01DSC) like TRIM(:iParms.DSC ) fetch first 9999 rows only;
AptRoApt
27.11.2023 11:33А что за язык-то? Видел Вас до этого в комментариях, где вы об этой же теме рассказывали, но язык так и не назвали. Читая статью, вспомнил вас, решил, что COBOL, вероятно, но не угадал)
SpiderEkb
27.11.2023 11:33Ну я писал - RPG на платформе IBM i
Практически ровестник COBOL - начинался как эмулятор табуляторов на IBM 1401 (со всеми вытекающими - позиционный синтаксис и т.п.) Первые программы писались на бланках (как когда-то для FORTRAN)
Сейчас - вполне нормальный процедурный язык. Много чего есть интересного. В частности очень гибкая концепция работы со структурами. в RPG структура - это байтовый буфер с размеченными внутри него полями. Причем, как просто (как в С) список полей, так и заданный размер (скажем, 100 байт) внутри которого определяется в какой позиции какое поле. При этом поля могут перекрываться.
Или вот такие конструкции:
dcl-ds t_dsLstIIF qualified template; arrLstIIF char(6) dim(5) ascend inz; arrLst char(5) overlay(arrLstIIF); arrIIF char(1) overlay(arrLstIIF: *next); cntLst int(5) inz; end-ds;arrLstIIF - массив 6-символьных элементов, каждый из которых состоит из 5-символов Lst и одного символа IIF - например 'PPT 7' с возможностью обращения напрямую к элементу dsLstIIF.arrLst(i) или dsLstIIF.arrIIF(i). Например, можно сортировать arrLstIIF как по arrLst, так и по arrIIF. Или искать в arrLstIIF как по arrLst, так и по arrIIF.
Или вот такое
eval-corr ds1 = ds2;Что означает "присвоить полям ds1 значения полей ds2 с совпадающими именами". Для структур где количество полей десятки сие сильно экономит количество строк.
Или возможность объявлять структуры со ссылкой на формат записи таблицы в БД (аж два способа)
dcl-ds t_dsECCMP2 likerec(ECCMP201LF.ECCMP2PFR: *all) template; dcl-ds t_dsGF extname('GFPF': *all) len(9999) qualified template end-ds;Вообще, IBM COBOL никогда особо не развивала. Т.е. на нашей платформе он до сих пор есть и поддерживается, но на нем практически никто не пишет. Более 80% кода пишется на RPG, что-то на С/С++
История там длинная и запутанная. IBM для своих коммерческих серверов (для коммерческих расчетов) одно время пытались двигать PL/1. Но получилось очень сложно и запутанно. Короче, задвинули его совсем и стали развивать RPG. Он достаточно простой но при этом мощный - в современной версии там и динамические массивы есть и overload процедур и арифметика для даты/времени/таймштампа и все что угодно для работы со строками (включая разбор строки в массив слов по разделителю, сборка строки из массива слов с заданным разделителем и прочее и прочее). Для чисел с фиксированной точкой вся арифметика, включая операции с округлением.
Вот как-то так... Да, очень нишевая вещь. Но в своей нише (банки, страховые и везде где нужна работа с БД + коммерческие расчеты) весьма эффективная как по скорости разработки, так и по надежности и быстроте кода. Я вот не знаю там ни одного UB, которыми так изобилует тот же С++. Там в принципе не бывает неиниализированных переменных - любая объявленная переменная всегда инициализируется компилятором в дефолтное для данного типа значение (если явно не указано иное). Есть удобные "спецзначения" *loval / *hival - минимальное / максимальное значение для данного типа переменной (т.е. не надо думать "а какое там может быть", "а где это определено макросом именно для этого типа" - компилятор сам определит что там должно быть в данном случае).
У нас эта платформа используется мало (Альфа, Росбанк, Райффайзен точно, одно время в ПФР было, не знаю как сейчас, в РЖД, слышал, были такие машины, может еще где...). На западе больше распространено. И ресурсы в сети есть по этому делу вполне живые.
Раз в 2-3 года выходит новая версия ОС. Два-три раза в год - минорные обновления - TR (technology refresh) - версию так и пишут - 7.4TR5. Железо тоже обновляется регулярно. У нас начиналb с серверов на Power7 (я не застал, пришел уже Power8 были), сейчас на Power9 живем. Уже вышли Power10.
Сама система тоже неслабая. Не винда и не линукс. "Все есть объект". Куча типов систеных обхектов - тут и очереди сообщений и очереди данных и пользовательские очереди еще много чего полезного.
БД интегрирована в систему, компиляторы интегрированы в систему... Покупая сервер сразу получаешь все что нужно.
Тут бесконечно можно рассказывать :-)
Dynasaur
27.11.2023 11:33+1Я представляю эти банкоматы и банковские системы, древние, как г..но мамонта. Мало того, я даже имел дело с соответствующим банковским сервисом. Большое счастье, что в России и СНГ банковские продукты появились после Кобола и не несут на себе ничего из этих окаменелостей. Ей богу, счастливы те, кто этого не знал.
Voldemarius
27.11.2023 11:33Не знаю насчет Кобола, но банкоматы с OS/2 до недавнего времени встречал - работают как часы. А вот банкоматы с Виндовс, которые тоже распространены в последнее время, нехило пьют кровь нашему обслуживающему персоналу...
msdos9
27.11.2023 11:33В 90-е плотно работал с ним на заводе. Какой-то там ЕС ЭВМ аналог какого-то там IBM, уже не помню... Боль была не от языка, а от зеленых, выжигающих сетчатку зеленых мониторов. А язык? Язык неплохой, только многословный и только ручками, ручками... Если много задач на сервере крутится, то приходилось ждать, когда до твоей очередь дойдëт, но это уже к языку не относится.
urvanov
27.11.2023 11:33Боль была не от языка, а от зеленых, выжигающих сетчатку зеленых мониторов.
Я, кажется, видел один такой монитор. Но там у него была возможно переключаться с черный-зеленый на черный-желтый, вроде. И ещё какой-то третий режим был, но тоже, правда, выглядело так себе.
Dynasaur
27.11.2023 11:33+1Зашёл на hh.ru. Поискал по словам "Cobol", "Кобол". Ни одной вакансии. Ноль! Аминь.
chnav
27.11.2023 11:33+2Меня тоже смутило это исследование от британских учёных:
>> результаты другого исследования от 2017 года показывают, что около 95 % банкоматов в мире используют код COBOL
Видимо речь о банкоматах где-то на Аляске
Feedman
27.11.2023 11:33В начале карьеры (середина 90-х) я работал с двумя тётками, которые в молодости видели человека работавшего на КОБОЛ-е.
sentbegemot
27.11.2023 11:33Вот всегда удивляло, а откуда у профи, у которых каждая минута по идее золотая, столько времени, чтобы писать такие комментарии-простыни?
toxis
27.11.2023 11:33В прошлом году я сменила деятельность на айти став junior developer на коболе. Если что - спрашивайте.
VladimirFarshatov
Э-эх.. а когда-то я его учил .. нифига уже не помню. ;)