Как стать автором
Обновить

Комментарии 12

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

В проектах одного крупного клиента все COBOL части активно переписывается на яву и прочее. И раньше этим занимались, но последние 2 года прямо ускорились. Так что думаю лет через пять ничего не останется. Ни COBOL ни мэйнфреймов.

Вообще или у конкретного клиента?

У одного, у него мы и занимаемся одним из проектов. И насколько мне известно у этого клиента ещё много всякого на коболе, они даже сами порой не знают, что за модули у них там крутятся.

Более 20 лет назад отечественная компания продавала транслятор исходников Кобола на Яву.

Все эти трансляторы не то чтобы супер работают. А там где до сих пор Cobol используют часто речь идёт о точности в кучу знаков после запятой и/или нужна хорошая производительность.

А с трансляторами на Яву вообще нужно аккуратно быть. Например в контексте unsigned вещей.

Судя по IBM документации у них и нет unsigned типов
https://www.ibm.com/docs/en/zos/2.4.0?topic=definitions-cobol-data-type
А по производительности - если писать на Яве как на коболе, без динамической аллокации памяти - то и работать всё будет как на Коболе/Си. Возможно даже быстрее, благодаря JIT оптимизациям, которые языкам без JIT недоступны.

Судя по IBM документации у них и нет unsigned типов

Ну у вышеупомянутого gnucobol unsigned похоже есть.

если писать на Яве как на коболе, без динамической аллокации памяти - то и работать всё будет как на Коболе/Си.

Если вы хотите писать на Яве "как на Коболе" , то пишите лучше и дальше на Коболе :)

Да и судя по той же ссылке на типы с точностью не особо, максимальный float 16 бит в коболе против минимального 32 бит в джаве, а bignum арифметику-то можно везде делать.

Задача в отказе от исходных текстов на Коболе, чтобы дальше поддерживать кодовую базу на Яве или С.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Другие новости

Истории