LINUX.ORG.RU

США из-за коронавируса срочно ищут знатоков COBOL. И не могут найти.

 


1

3

Власти американского штата Нью-Джерси начали поиски программистов, знающих язык COBOL, из-за возросшей в связи с коронавирусом нагрузки на старые ПК в американской системе занятости. Как пишет The Register, специалистам потребуется обновить программное обеспечение на мейнфреймах 40-летней давности, которые перестали справляться с нагрузкой, резко выросшей на фоне увеличившегося числа безработных из-за пандемии CoVID-19.

Проблема нехватки знающих COBOL программистов затронула не только Нью-Джерси. В штате Коннектикут власти тоже ищут специалистов по этому языку, притом в этом случае поиск ведется совместно с чиновниками еще трех штатов. Tom’s Hardware пишет, что их усилия, как и в Нью-Джерси, к успеху пока не привели. https://www.tomshardware.com/news/new-jersey-cobol-coders-mainframes-coronavirus

Согласно опросу Computer Business Review (https://www.cbronline.com/news/cobol-code-bases) , проведенному в I квартале 2020 г., с проблемой необходимости модернизации ПО в настоящее время сталкиваются 70% компаний, по тем или иным причинам до сих пор использующим программы, написанные на COBOL. Точное количество таких предприятий неизвестно, но, по информации Reuters, во всем мире в 2020 г. используется 220 млрд строчек кода этого языка.

COBOL активно применяется не только в системах занятости, но и в финансовых организациях. На 61-летнем языке написано 43% приложений, используемых в банковских сферах, и 95% банкоматов по всему миру в тех или иных масштабах используют созданное с его помощью ПО.

К числу причин, по которым организации не спешат отказываться от COBOL и переходить программы, созданные при помощи актуальных языков программирования – это дороговизна обновления. На своем примере это доказал Банк содружества Австралии, решившийся на полную замену всех приложений, написанных на COBOL.

Представители банка сообщили, что переход на новое ПО занял пять лет – он проходил в период с 2012 по 2017 гг. Размер затрат на это крупномасштабное мероприятие известен – апдейт обошелся банку почти в $750 млн.

>>> Подробности

★★★★★

Проверено: Pinkbyte ()
Последнее исправление: Pinkbyte (всего исправлений: 1)
Ответ на: комментарий от stasolog

Губернатор Нью-Джерси ищет программистов на Cobol’е (комментарий)

И? Аргументов весомых то нет, а истории они такие, имеют свойство разниться.

С мертвого языка на мертвый? Классная идея.

Кобол чё мёртвый то, обновления есть, как платные так и бесплатные реализации. Фортран так же, ничё живой, обновы есть.

shpinog ★★★★
()
Ответ на: комментарий от shpinog

И? Аргументов весомых то нет, а истории они такие, имеют свойство разниться.

Я ссылку на комментарий дал.

Кобол чё мёртвый то, обновления есть, как платные так и бесплатные реализации. Фортран так же, ничё живой, обновы есть.

Ну я про это писал в том треде. Правда бесплатные реализации плохи.

stasolog
()
Ответ на: комментарий от stasolog

Я ссылку на комментарий дал.

Ссылка не аргумент, я о содержимом.

Ну я про это писал в том треде. Правда бесплатные реализации плохи.

Ну так не бомжи обновляются, могут и у mfi взять лицуху.

shpinog ★★★★
()
Ответ на: комментарий от shpinog

Ссылка не аргумент, я о содержимом.

Ну я думаю в их программах идет в основном работа с числами, и не с обычными, а специальными. В Java нормальной работы с этими числами нету, и на каждое действие нужно писать иногда по несколько строчек, так наверное выйдет что программы на Java будут более длинными и менее понятными, лол. Но в принципе они наверное могли бы заказать перегрузку операторов, или новый тип, тогда было бы попроще, но Oracle принимает в последнее время странные решения, например убили Java EE и отказали в передаче несчастного неймспейса Eclipse для развития, + новые версии теперь выходят часто, время жизни у них маленькое...

Ну так не бомжи обновляются, могут и у mfi взять лицуху.

Ну эт понятно. Я просто инфой делюсь.

stasolog
()
Последнее исправление: stasolog (всего исправлений: 1)
Ответ на: комментарий от stasolog

Ну я думаю в их программах идет в основном работа с числами, и не с обычными, а специальными.

Что за числа такие? Библиотеку накалякать не вариант?

писать иногда по несколько строчек, так наверное выйдет что программы на Java будут более длинными и менее понятными, лол

Я не думаю что там 90% строк это работа с числами, там 90% это бизнес логика. Собственно в фортране с мат либами всё отлично, так сказать эталон, если твоё предположение верно то почему нет?

, но Oracle принимает в последнее время странные решения, например убили Java EE и отказали в передаче несчастного неймспейса Eclipse для развития, + новые версии теперь выходят часто, время жизни у них маленькое…

Только всё это не имеет отношения к самому языку непосредственно, думаю там люди будут исходить не из наличия jave EE и недоIDE. Жаба конечно говно, но с точки зрения надёжности все пердят что хороша, сам не проверял.

shpinog ★★★★
()
Ответ на: комментарий от shpinog

Кобол чё мёртвый то, обновления есть, как платные так и бесплатные реализации

И кто же их выпускает? Оттуда программистов нельзя взять?

anonymous
()
Ответ на: комментарий от shpinog

Что за числа такие? Библиотеку накалякать не вариант?

Пройди по моей ссылке, там ниже я рассказывал. Библиотека не спасает, так как перегрузки операторов в яве нету.

Я не думаю что там 90% строк это работа с числами, там 90% это бизнес логика.

Которая работа с числами все же, не со строками же.

Собственно в фортране с мат либами всё отлично

Не думаю что там матан жеский нужен, или матрицы хотя бы, там проблема в устройстве чисел.

Только всё это не имеет отношения к самому языку непосредственно

Они могут взять яву 8 версии допустим, и заморозиться, но так себе вариант по моему. А так вполне надежна, исполняется в виртуальной машине, относительно проста, быстра, не особо меняется, инструментов много.

stasolog
()
Ответ на: комментарий от anonymous

будут брать. аккуратно, по ночам.

anonymous
()
Ответ на: комментарий от stasolog

Пройди по моей ссылке, там ниже я рассказывал. Библиотека не спасает, так как перегрузки операторов в яве нету.

А что нельзя эту библиотеку написать на том же Си\С++ там же вроде хорошая интеграция, да и к яве вроде можно почти всё прицепить не? Собственно я не думаю что там прям такая большая библиотека будет, да и задача скорее всего типовая и много раз решенная.

Которая работа с числами все же, не со строками же.

Но не напрямую, это уже абстракции и обёртки.А что где-то можно работать с числами не используя числа?

Не думаю что там матан жеский нужен, или матрицы хотя бы, там проблема в устройстве чисел.

В LLVM не решенная и потенциально не прилепимая к любому из кучи языков в него могущих ?

Они могут взять яву 8 версии допустим, и заморозиться, но так себе вариант по моему. А так вполне надежна, исполняется в виртуальной машине, относительно проста, быстра, не особо меняется, инструментов много.

Здесь мне кажется больше вопрос именно жлобства, просто выбор явы обусловлен меньшими затратами на обустройство этой надёжности, и дешевизне специалистов (человеко-часы) для реализации. При желании это всё можно хоть на C\C++ (учитывая последние изменения вполне можно писать надёжный код), хруст, GO, да и ещё кучу хипстоты. Через 10 лет это всё будет таким же говном легаси как джава.

shpinog ★★★★
()
Ответ на: комментарий от shpinog

А что нельзя эту библиотеку написать на том же Си\С++ там же вроде хорошая интеграция, да и к яве вроде можно почти всё прицепить не?

Проблема в синтаксисе, так то все реализуемо, посмотри на код по ссылке, программы делают одно и тоже, все в порядке по этой части, но если на коболе можно написать 2+2*2, то в яве это превращается в кучу кода с созданием классов, вызовом методов.

В LLVM не решенная и потенциально не прилепимая к любому из кучи языков в него могущих?

Ну можно и для явы препроцессор написать, или компилятор подправить, и никаких проблем, я уже выше написал. Только видимо какие то проблемы с этим, иначе почему эти траблы описывают? Может разрешено юзать только закрытый компилятор от ibm на их железе и за внесения правок и препроцессоры расстрел на месте с потерей лицензии.

Через 10 лет это всё будет таким же говном легаси как джава.

Код на С написанный по 89 стандарту и сейчас смотрится так же как современный, никаких отличий нету.

stasolog
()
Ответ на: комментарий от stasolog

Ну я думаю в их программах идет в основном работа с числами, и не с обычными, а специальными.

С каких пор вещественные числа с фиксированной точкой стали «специальными»?

например убили Java EE и отказали в передаче несчастного неймспейса Eclipse для развития,

И теперь Jakarta EE, не зависит от одного монополиста, профит же.

  • новые версии теперь выходят часто, время жизни у них маленькое…

LTS-версии никто не отменял. Да и то, не Ораклом единым, тех. поддержку можно и у других компаний купить.

ma1uta ★★★
()
Ответ на: комментарий от shpinog

Что за числа такие? Библиотеку накалякать не вариант?

Вещественные числа с фиксированной точкой, есть в стандартной библиотеке.

ma1uta ★★★
()
Ответ на: комментарий от ma1uta

С каких пор вещественные числа с фиксированной точкой стали «специальными»?

С таких, можно пройти по моей ссылке и почитать о проблеме.

stasolog
()
Ответ на: комментарий от stasolog

Во-первых, по ссылке субъективщина, а на вкус и цвет все фломастеры разные. Во-вторых, вещественные числа с фиксированной точкой вполне обычный класс, ничего там «специального» нет.

ma1uta ★★★
()
Ответ на: комментарий от ma1uta

Ну да, конечно. Ведь так же не видно никакой разницы между:

double length(point a, point b) {
        return sqrt(pow(a.x - b.x, 2) + pow(a.y - b.y, 2));
}

_Z6length5pointS_:
.LFB246:
        .cfi_startproc
        pushq   %rbp
        .cfi_def_cfa_offset 16
        .cfi_offset 6, -16
        movq    %rsp, %rbp
        .cfi_def_cfa_register 6
        subq    $48, %rsp
        movq    %xmm0, %rcx
        movapd  %xmm1, %xmm0
        movl    $0, %eax
        movl    $0, %edx
        movq    %rcx, %rax
        movq    %xmm0, %rdx
        movq    %rax, -16(%rbp)
        movq    %rdx, -8(%rbp)
        movapd  %xmm2, %xmm1
        movapd  %xmm3, %xmm0
        movl    $0, %eax
        movl    $0, %edx
        movq    %xmm1, %rax
        movq    %xmm0, %rdx
        movq    %rax, -32(%rbp)
        movq    %rdx, -24(%rbp)
        movsd   -16(%rbp), %xmm0
        movsd   -32(%rbp), %xmm1
        subsd   %xmm1, %xmm0
        movsd   .LC0(%rip), %xmm1
        call    pow@PLT
        movsd   %xmm0, -40(%rbp)
        movsd   -8(%rbp), %xmm0
        movsd   -24(%rbp), %xmm1
        subsd   %xmm1, %xmm0
        movsd   .LC0(%rip), %xmm1
        call    pow@PLT
        addsd   -40(%rbp), %xmm0
        call    sqrt@PLT
        movq    %xmm0, %rax
        movq    %rax, -40(%rbp)
        movsd   -40(%rbp), %xmm0
        leave
        .cfi_def_cfa 7, 8
        ret
        .cfi_endproc

Подумаешь на ассемблере как в яве числа просто так не сложишь, субъективщина все это...

stasolog
()
Ответ на: комментарий от stasolog

Есть люди, для которых второй вариант выглядит лучше первого, и наоборот, для кого-то первый нагляднее.

ma1uta ★★★
()
Ответ на: комментарий от stasolog

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

anonymous
()
Ответ на: комментарий от anonymous

Классно, возможно неплохой вариант, хотя мне кажется он еще сыроват может быть.

stasolog
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.