Comments 47
Э-эх.. а когда-то я его учил .. нифига уже не помню. ;)
Почему с такими преимуществами языка как описано в статье, его не используют повсеместно в проектах?
А что, разве на рынке ЯП "надежность, эффективность, масштабируемость и совместимость" есть только у Кобола?
В Коболе есть кое-какие вещи, которые рассчитанны на аппаратуру мейнфремов и которые в "обычных" процессорах (Intel, ARM...) просто не существуют. Их можно эмулировать, но работать будет медленно. (По нынешним временам не так уж и медленно, но ещё 20 лет назад это было неприемлемо.)
Поэтому компиляторы Кобола для "обычных" компьютеров и "нормальных" операционных систем очень долго никто не писал. А когда все таки стали, выяснилось, что и без них языков выше крыши. Поэтому все привыкли обходяться без него. А лет 10 тому назад американский Federal Reserve System объявил Коболу войну.
Нет. Но в той области где он применяется, конкурентов ему не так много.
Попробуйте написать на привычном вам ЯП задачку, где надо сделать из БД выборку по нескольким таблицам (SQL с join'ами) и как-то ее обработать.
Причем:
В полученной выборке будет поля типов NUMERIC, DECIMAL, DATE, TIME, VARCHAR
Для повышения скорости работы при множественных вызовах быстрее использовать т.н. "статический SQL". Т.е. непосредственную вставку SQL в код программы типа exec sql select ... from ... где сам запрос будет валилидироваться на этапе компиляции и на этапе же компиляции будет построен план запроса - в рантайме на это уже не будет тратиться время
Время не должно тратиться (предположите что эта штука будет вызываться 100 000 000 раз в стуки) на создание всяких "объектов-оберток" для полей полученных из выборки - просто описали соотв. статическую структуру (безо всяких конструкторов, просто байтовый буфер с размеченными полями), прочитали туда очередную запись и работаем с полями структуры - это обычные переменные, не объекты.
Написав одно и то же на COBOL и условной Java или C#, обнаружите, что программа на COBOL на одном и том же железе не только быстрее, но еще и памяти меньше потребляет и ресурсов процессора.
Но это касается только вот таких специфических задач (интенсивная работа с БД в больших объемах и коммерческие вычисления). Писать что-то иное на COBOL будет очень больно.
не понял, а в чем проблема написать например это на C или C++?
эта штука будет вызываться 100 000 000 раз в стуки
Звучит как "где ещё вы найдёте слесаря, который сделает подшипник не выходя из запоя?"
Такая задача банально не выключается, а висит себе сервисом и дёргается по API. Поэтому можно валидировать SQL и создать временные объекты один раз - на старте. А значит и написать это можно на чём угодно - ко второму прогону даже JavaScript уже заJITится достаточно для приемлемой скорости.
Звучит как "где ещё вы найдёте слесаря, который сделает подшипник не выходя из запоя?"
В середине 90х в одном миллионнике я принимал активнейшее участи в спасении многопарного(кажется 12 пар) оптического кабеля в металлическом корпусе. Разбирали "на золото" ЕС-103X(не помню точную модель) и буквально ногой выбивал ножовку по металлу у того кто пытался перепилить этот неподъёмный кабель. Была задействована единственная пара под единственный ЕС-7927 в паре километров от ВЦ. Пилить под новые разъёмы не судьба, на тот момент в городе был единственный человек у телевизионщиков который учился в Питере на сварщика оптики и он понятия не имел что с нашей делать. Была найдена фирма в Зеленограде, которая уже имела такой опыт и делала конвертор оптика(старорежимная) - эзернет(коаксиал). Разъём назывался ЛУ-6 или ЛУ-6(Булава), отличались шагом резьбы. Так вот именно по причине запоя токаря Зеленоград сорвал сроки и по портил кучу нервов ибо никто не понимал заработает ли оно вообще и ожидание было невыносимым. Заработало!!!
Звучит как интересная история для полноценной статьи.
Учитывая то, что первый зачёт(*) по программированию сдан как раз в декабре 1978 - го, историй таких за 45 лет накопилось много, но для статей просто пересказа фрагментов воспоминаний ИМХО не достаточно.
(*) АЛГАМС и программирование "на листочке". Живого компилятора в руках не удалось по держать, хотя экскурсия в зал с Минском была и обязательно с главной фишкой - прослушиванием музыки извлекаемой из пищалки пульта.
При таких вводных проще будет сразу писать хранимую процедуру в бд.
p.s. зачем план запроса строить на этапе компиляции?
Cубд умеют кэшировать планы запросов.
Планы запросов имеют тенденцию устаревать - ну там статистка, индексы и вот это все
вариантов решения этой задачи много, зависит от конкретных вводных, уверен что можно найти решение без использования COBOL)
Например потому что писать на нём это боль :)
А какие преимущества? Операции с плавающей точкой добавили в 2014! Круто! :-)
Там, где используется кобол (финансовые расчеты) они нафиг не нужны (хотя бы потому что с ними будут накапливаться ошибки округления). Все операции там проводятся с фиксированной точкой. А поддержка этих типов в кобол заложена "с рождения".
Так что добавили их туда "чтобы было", реальной потребности в том нет.
ну да, конечно, ни одного статистического отчёта не построить без них, ни одного прогноза. Конечно, для деревянной системы, которая умеет только в дебет-кредит этого не надо. Вот в них он и работает :-)))
Понятие "финансовая математика" там_где_используется_кобол тоже не ведомо. Расчёт рисков там всякий, ну его
Во-первых, нетрадиционный синтакис.
Во-вторых, это не ЯП общего назначения, это специализированный ЯП для коммерческих расчетов. Т.е. ниша его эффективного использования достаточно узка.
Вот всегда интересовало, что там такого специализированного?
Это сложно объяснить тому, кто ни разу не сталкивался. Правда. Я неоднократно пытался донести эту мысль, но практически всегда неудачно. Основные аргументы "против" такие:
"Ну и что что нужен SQL в коде? У меня вот есть библиотека ... которая позволяет выполнять SQL запросы из программы". Тут пытаешь объяснить разницу между "библиотекой" где для любого запроса план каждый раз будет готовится в рантайме (а на это запросто может уйти процентов 30 времени и столько же ресурсов процессора - это наши объективно замеренные статистики) и embedded sql поддерживаемый компилятором языка, который не только провалидирует запрос на этапе компиляции, но и на этапе компиляции же его план построит, экономя время в рантайме.
"А вот в Java есть BigDecimal - это тоже самое что DECIMAL в БД". Не тоже самое. Во-первых, это не нативный тип, а класс-обертка. Во-вторых, в памяти он представлен совсем иначе, нежели DECIMAL на диске в записи. И вы не можете объявить переменную типа BigDecimal (как вы объявляете, например int), просто скопировать туда кусок буфера с диска и потом с ней работать. Вам потребуется объявить объект класса, вызвать его конструктор и т.п. А это все время и ресурсы процессора.
В COBOL все типы данных, что есть в БД поддерживаются нативно. Т.е. там есть и фиксированная точка (аналоги DECIMAL, NUMERIC) и дата-время и таймштампы и VARCHAR. Там не надо никаких оберток - просто объявляете структуру (с точки зрения COBOL это просто байтовый буфер - кусок памяти заданного размера внутри которого размечены поля-члены структуры) с полями соотв. типов, читаете туда запись и дальше без никаких лишних телодвижений уже работает с полями структуры. Т.е. экономите время на вызовы всяких конструкторов для объектов-оберток.
Напомню что все это работает главным образом на больших серверах, где одновременно крутятся десятки тысяч самых разных бизнес-процессов, за сутки сотни миллионов (если не миллиарды) бизнес-операций выполняется, терабайты (а то и десятки терабайт) в сутки изменений в БД.
И часто это банки, которые предпочитают все данные хранить во внутреннем периметре, т.е. "купить еще один сервер в облаке" для них не вариант.
Такая вот специфика... И да. Не COBOL'ом единым. Есть и другие (как минимум один знаю и с ним работаю) специализированные языки такой направленности. Есть даже целые специализированные платформы (дорого, но очень эффективно и очень надежно) для таких задач.
И да. Вне всей этой специфики, такие языки нафиг не нужны.
Тут пытаешь объяснить разницу между "библиотекой" где для любого запроса план каждый раз будет готовится в рантайме
Вы же в курсе что большинство таких "библиотек" давно уже поддерживают эту вашу "прекомпиляцию" SQL запросов?
Интересно, каким образом? На этапе компиляции "библиотека" еще не работает. Это должен быть компилятор (или предкомпилятор). Который еще и проверит - а куда ты собираешься получать результат запроса, а совпадает ли объявление структуры с форматом результата запроса...
Максимум что может библиотека - сделать план и закешировать его при первом вызове.
Но основная проблема будет с типами переменных. Которых в обычных ЯП просто нет.
Я все это не просто так - все это пробовал - С/С++ в сравнении со специальным языком. А потом все это через Performance Explorer прогоняется. И там сразу видно - тут пара процентов времени на "лишние" операции в С/С++, там три процента...
Даже код более громоздкий получается...
Т.е. Что-то типа pl/sql?
IBM 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> в С++
Для всего остального уже "обертки" нужны.
На этапе компиляции "библиотека" еще не работает.
Зависит от библиотеки. Плюс в самом крайнем случае вы это можете и "ручками" прописать.
Который еще и проверит - а куда ты собираешься получать результат запроса, а совпадает ли объявление структуры с форматом результата запроса...
Ну это как раз таки делается даже если вы не прекомпилируете.
Зависит от библиотеки. Плюс в самом крайнем случае вы это можете и "ручками" прописать.
Зачем, есть все это у меня уже есть?
Ну это как раз таки делается даже если вы не прекомпилируете.
На каком этапе? Вот ошибся в синтаксисе запроса - должен получить ошибку с указанием - "вот тут у тебя фигня какая-то" на этапе компиляции.
Ошибся с типами хост-переменной куда результат запроса приходит - получи ошибку при компиляции "тут тип неправильный".
Там еще много чего... Например, резалсеты. Я могу из своей программы в вызывающую вернуть 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;
А что еще за языки и платформы?
А что за язык-то? Видел Вас до этого в комментариях, где вы об этой же теме рассказывали, но язык так и не назвали. Читая статью, вспомнил вас, решил, что COBOL, вероятно, но не угадал)
Ну я писал - 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.
Сама система тоже неслабая. Не винда и не линукс. "Все есть объект". Куча типов систеных обхектов - тут и очереди сообщений и очереди данных и пользовательские очереди еще много чего полезного.
БД интегрирована в систему, компиляторы интегрированы в систему... Покупая сервер сразу получаешь все что нужно.
Тут бесконечно можно рассказывать :-)
Я представляю эти банкоматы и банковские системы, древние, как г..но мамонта. Мало того, я даже имел дело с соответствующим банковским сервисом. Большое счастье, что в России и СНГ банковские продукты появились после Кобола и не несут на себе ничего из этих окаменелостей. Ей богу, счастливы те, кто этого не знал.
Таки где падение, заявленное в заголовке?
В 90-е плотно работал с ним на заводе. Какой-то там ЕС ЭВМ аналог какого-то там IBM, уже не помню... Боль была не от языка, а от зеленых, выжигающих сетчатку зеленых мониторов. А язык? Язык неплохой, только многословный и только ручками, ручками... Если много задач на сервере крутится, то приходилось ждать, когда до твоей очередь дойдëт, но это уже к языку не относится.
в Сбере гдето остался КОБОЛ? Остались даже книжки какие-то по нему, листал читал когда-то в детстве когда подобную литературу можно было найти только в библиотеках.
Зашёл на hh.ru. Поискал по словам "Cobol", "Кобол". Ни одной вакансии. Ноль! Аминь.
Меня тоже смутило это исследование от британских учёных:
>> результаты другого исследования от 2017 года показывают, что около 95 % банкоматов в мире используют код COBOL
Видимо речь о банкоматах где-то на Аляске
В начале карьеры (середина 90-х) я работал с двумя тётками, которые в молодости видели человека работавшего на КОБОЛ-е.
Была как-то 1 вакансия в Питере, полгода назад или около того.
есть предложение сделать диалект Cobol вторым языком для 1С.
Насчёт банкоматов брехня поди.
Вот всегда удивляло, а откуда у профи, у которых каждая минута по идее золотая, столько времени, чтобы писать такие комментарии-простыни?
В прошлом году я сменила деятельность на айти став junior developer на коболе. Если что - спрашивайте.
Взлет и падение языка COBOL. Где и как язык программирования, которому 60 лет, применяется и в наше время?