company_banner

Ускорение старения современных технологий

Автор оригинала: Marianne Bellotti
  • Перевод
Когда меня просят дать интервью, или когда приглашают выступить с рассказом о моей работе по модернизации устаревших систем, то, и так происходит всегда, все хотят говорить о мейнфреймах и о COBOL. Я так думаю, что собеседники ждут от меня хороших баек о тяготах возни со старыми системами. Эти байки интересно послушать программистам, которым о подобных вещах беспокоиться не приходится, так как их профессиональные навыки построены на современных технологиях.



Тут надо учитывать, что и меня, когда я начала работать со старыми системами, тоже привлекало в самых древних программах то, что можно назвать фактором «Хотите верьте, хотите нет» Роберта Рипли. Это — трепет, который охватывает исследователя, отыскивающего и препарирующего всё более старые системы, разбирающегося в забытых языках, о которых большинство программистов никогда не слышало, не говоря уже о работе с этими языками. Меня всегда привлекали низкоуровневые языки и системы, то волшебство, которое превращает изменения напряжения в математические и графические абстракции. Но позже я серьёзно заинтересовалась исследованием приближающегося «апокалипсиса устаревших систем» и изучением того, как замедлить рост технического долга в более новых технологиях. А этот долг с каждым годом растёт всё быстрее.

«Апокалипсис устаревших систем» — это не то, что случится после смерти последнего COBOL-программиста из поколения бебибумеров. Если честно, то этот кризис пришёл и ушёл. Когда люди говорят об опасности использования старых систем, они обычно любят обращать всеобщее внимание на статистические сведения, указывающие на то, как велик средний возраст COBOL-программистов. Например, в 2006 году этот возраст составлял 55 лет. Звучало это устрашающе. Получается, что множество очень важных сотрудников близки к пенсии! Кто же будет присматривать за их системами после того, как они уйдут?

Статистика может вводить людей в заблуждение. В одном и том же исследовании сказано, что возраст 52% программистов находится в диапазоне 45-55 лет, а возраст 34% программистов — 35-45 лет. Но, если говорить более конкретно, то через восемь лет, когда предполагалось, что все эти 55-летние программисты уйдут на пенсию, исследование программистов и других специалистов, связанных с COBOL, проведённое Micro Focus, показало, что их средний возраст снова равен 55 годам. А их же исследование 2019 года выяснило, что средний возраст тех, кто связан с COBOL, составляет 50 лет.

На самом деле, средний возраст COBOL-программистов оставался стабильным в течение десятилетий. Когда мой отец работал над проблемами Y2K, ему было около 50 лет. Возраст его коллег был примерно таким же. Каждый раз, когда я вижу, как кто-то придаёт большое значение возрасту членов COBOL-сообщества, я вспоминаю о том, что американская гобоистка Блэр Тиндалл написала в своей книге «Моцарт в джунглях» о слушателях классической музыки:

Ужас по поводу старения зрителей был довольно нелеп: их средний возраст уже какое-то время колебался в районе сорока с лишним лет. Довольно логично повременить до зрелости с посещением симфонических концертов. Когда дети выросли, кредиты выплачены, а свободного времени стало больше, концерты – отличный вариант, соответствующий возможностям и вкусам бывших бебибумеров.

Похожее можно сказать и о COBOL. В отличие от программистов, которые были молоды в 60-е, 70-е и 80-е годы, у современных молодых программистов нет институтских мейнфреймов, с которыми они могли бы поэкспериментировать. Если же в их учебном заведении и есть подобная машина, то она представляет собой «рабочую лошадку» администрации. Такая машина слишком важна для того, чтобы на ней позволили бы делать студенческие проекты. Молодым программистам никто не предлагает изучать COBOL. И если даже они этот язык и выучат, то сотни, а кто-то скажет, что и тысячи COBOL-вакансий не рассчитаны на новичков.

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

Беспокойство по поводу возраста COBOL-программистов можно объяснить страхом того, что когда исчезнет последний такой программист, некому будет поддерживать программы, написанные на COBOL. А эти программы в некоторых областях весьма важны. Это беспокойство вполне обосновано. Но многих удивит тот факт, что угроза неподдерживаемого устаревшего кода гораздо ближе, чем они думают. И мейнфреймы тут совершенно ни при чём.

64% Java-приложений застряли на Java 8


Если вы в курсе того, что происходит в мире Java, то знаете, что самой свежей версией Java является 14. Окончание поддержки Java 8 планировалось на 2019 год.

В Java 9 появились некоторые структурные изменения, направленные на то, чтобы повысить возможности языка по работе с модулями. Это должно было сделать так, чтобы язык лучше подходил бы для встроенных систем. Переход с Java 8 на Java 9 — это не рядовое обновление. Это — полномасштабная миграция. Кроме прочего, в Java 9 внутренние API JDK недоступны, из языка убрали некоторые инструменты и методы. Сдвиг в сторону модульной структуры требовал изменений в системе управления зависимостями. Другими словами, переход с Java 8 на Java 9, весьма вероятно, может потребовать переписывания больших объёмов кода.

В результате, по данным исследования Snyk, в 2020 более половины продакшн-приложений, написанных на Java, используют Java 8.

Python 2


Конечно, ярчайшим примером обновлений, которые, на самом деле, являются серьёзными миграциями, является переход с Python 2 на Python 3. Как и в случае с Java 8, Python 2 не спешит уходить из-за того, что миграция на Python 3 требует и переписывания собственного кода, и исключения Python 2 из всех зависимостей. Хотя инструменты, вроде six Бенджамина Петерсона, серьёзно упрощают эту задачу, понятие «зависимости» — это нечто большее, чем пакеты и библиотеки. Платформа, на которой выполняется код, это тоже зависимость, а платформы медленно реагируют на изменения. Хотя Python — чрезвычайно популярный инструмент для разработки скриптов, AWS Lambda не поддерживала Python 3 версии 3.6 до 2017 года. А это значит, что с момента выхода Python 3.6 до момента, когда эта версия языка получила поддержку AWS, прошёл год. В тот же год поддержка Python 3 появилась в Salt. Ansible представила поддержку Python 3 ещё через год, то есть — примерно через 10 лет после того, как вышел Python 3.

Сложно оценить объёмы Python 2-кода, которые продолжают использоваться в мире. По оценке JetBrains, объём такого кода в 2019 году составлял всего 10% от общего объёма Python-кода. Учитывая то, то в исследовании JetBrains приняли участие 24 тысячи респондентов из 150 стран, вышеозвученная цифра, вероятно, достаточно точна. Проблема Python 2 может заключаться не в количестве кода, который всё ещё используется. Проблема тут скорее в том — где именно используется такой код. В соответствии с данными JetBrains, области, в которых Python 2 всё ещё впереди Python 3 — это DevOps и автоматизация работы, это тестирование и сетевое программирование. Как оказалось, очень сложно полностью перевести на Python 3 всяческие разновидности Linux. И борьба Python 2 с Python 3 всё ещё не окончена. Каждый питонист, работающий на компьютерах от Apple, знает о том, что на эти компьютеры всё ещё, по умолчанию, устанавливается Python 2.7, что вызвано особенностями внутренних инструментов macOS.

Все ненавидят jQuery, но эта библиотека всё ещё применяется повсюду


C другой стороны ада зависимостей находится библиотека jQuery. Миграция с jQuery сложна не из-за зависимостей. Сложности при миграции вызывает то, что очень много всего зависит от jQuery.

Когда в 2019 году из зависимостей Twitter Bootstrap наконец убрали jQuery, суть происходящего была в том, что код jQuery просто перенесли в Bootstrap. Но даже при таком подходе на этот проект ушло два года.

jQuery — это жертва собственного успеха. Простой синтаксис библиотеки стал настолько популярным, что другие библиотеки и фреймворки, и даже сам JavaScript, начали внедрять его у себя. Кроме того, много устаревших технологий, совместимость с которыми даёт jQuery, наконец то были выведены из эксплуатации (я смотрю в твою сторону, Internet Explorer). Лично я полагаю, что вся эта шумиха вокруг jQuery несколько преувеличена, но я не JavaScript-программист. Похоже, что война с jQuery началась из-за конфликта между этой библиотекой и React — современной популярной JS-библиотекой для разработки интерфейсов.

Но, как и в случае со всеми остальными «священными войнами» в сфере технологий, здравые доводы по поводу выбора одной технологии, а не другой, становятся, чем чаще их повторяют, всё невнятнее. Полагаю, что история с jQuery чем-то похожа на историю с COBOL, когда в статьях об этом языке начинали разговор с того, что он присутствует повсюду, и имели в виду то, что, так как другие технологии могут решать те же задачи, эти технологии (более новые) должны быть лучше COBOL.

Проблема — в глубине деревьев зависимости, а не в возрасте технологий


Многое делает свой вклад в сложность поддержки устаревших систем. И возраст программистов, которые их поддерживают, это не особенно серьёзная проблема. Если говорить честно, то здесь важна потеря части коллективной памяти организации. Когда программист, который очень хорошо знает систему, уходит, часть коллективной памяти уходит вместе с ним. Но эта проблема не относится исключительно к достаточно старым технологиям. Организации теряют коллективную память из-за того, что их сотрудников переманивают другие компании, так же часто, как и из-за ухода сотрудников на пенсию (а возможно, даже чаще).

То, что в мире существует ограниченное количество программистов, разбирающихся в COBOL, это проблема, которую дешевле и проще всего решить, создав системы подготовки новых COBOL-кадров. Например, в этой сфере весьма активна компания IBM, представившая программу Master the Mainframe. То есть получается, что идея, в соответствии с которой COBOL-программисты — это исчерпаемый ресурс, который постепенно истощается, попросту не соответствует действительности.

Опыт подсказывает мне, что когда с COBOL-системой что-то идёт не так, проблемы практически никогда не связаны с самим COBOL. Я сталкивалась с отказами аппаратного обеспечения, видела ошибки систем, не выполняющих COBOL-код, но как-то поддерживающих COBOL-системы или как-то интегрированных с ними. Я видела задержки в добавлении в системы новых возможностей, вызванные тем, что код на COBOL был плохо документирован, что требовало от программистов разбираться с ним и искать пути его правильного изменения. Но мне не доводилось видеть множества происшествий, причиной которых был сам факт того, что в системе используется COBOL. Само по себе использование COBOL — это не проблема. Я не хочу сказать, что у тех, кто использует COBOL, нет причин перейти на что-то другое. Такие причины есть. Я просто не склонна соглашаться с тем, что миллионы строк COBOL не смогут поддерживать механизмы, обеспечивающие функционирование гражданского общества, ещё 60 лет. Эти механизмы, определённо, могут продолжать работать на COBOL.

С другой стороны, Java 8 и Python 2 — это гораздо более серьёзные угрозы. Когда системы не могут избавиться от технологий, которые больше не поддерживаются производителем, то в эти системы не устанавливаются обновления безопасности, в них не появляются новые возможности, не улучшается производительность механизмов, на которых они основаны. Чем дольше система держится за свой собственный технический долг, тем больше всего строится на базе устаревших технологий, и тем сильнее укрепляются позиции таких технологий.

Мы оказываем программистам медвежью услугу, когда ведём себя так, будто разговор о растущей угрозе, связанной со старым кодом, начинается с COBOL и им же заканчивается. Целое поколение программистов тратит своё рабочее время только на то, чтобы усугубить проблему. Они передают реализацию почти всего функционала своих приложений, кроме их совершенно уникальных механизмов, армиям библиотек, плагинов, модулей. За всем этим программистам практически невозможно уследить, не говоря уже о том, чтобы всё это нормально обновлять.

Настоящий всадник «апокалипсиса устаревших систем» — это глубина деревьев зависимостей. В современных стеках разработки ПО одни абстракции строятся на других абстракциях. Если инцидент с left-pad в 2016 году что-то и доказал, так это то, что даже опытные программисты бездумно добавляют в свои проекты зависимости. Ведь в их распоряжении имеется инфраструктура, до крайности упрощающая установку зависимостей. Современные среды разработки — это настоящие кондитерские, в которых лежат горы дешёвых и удобных зависимостей.

Эра фреймворков


Если ресурс Wikipedia можно считать авторитетным источником информации, то оказывается, что в 90-е годы наблюдался пик разработки совершенно новых языков программирования. Это случилось тогда, когда компьютеры стали доступны очень многим. Но тогда создавалось сравнительно мало неких инструментов, абстракций, основанных на чём-то другом. Интернет изменил и разработку языков, и разработку инструментов, сделав реальностью создание более сложных распределённых систем, но и расширив «радиус поражения» общества при инцидентах, связанных с компьютерной безопасностью. Необходимость в более высокой производительности и в более высоком уровне безопасности сделала разработку новых языков достаточно сложной задачей. Прошли те времена, когда продвинутый компьютерщик мог создать прототип языка «на коленке» и ждать того, что этот язык будет применён для решения реальных задач и принесёт реальную пользу. Сейчас существует огромное количество сложных задач, которые, как ожидается, языки программирования должны решать за программистов.

И даже хотя количество профессиональных программистов теперь значительно больше, чем в старые добрые 90-е годы, эти специалисты переключились с разработки новых языков на разработку новых фреймворков.

А фреймворк — это, в сущности, всего лишь поддерживаемая кем-то коллекция зависимостей с общим интерфейсом. Бесспорно то, что фреймворки позволяют быстрее разрабатывать программы, но они ещё и забирают у разработчиков возможность поддержки собственного кода. Развитие инструментов, которые увеличивают скорость разработки, неизбежно приводит к разрастанию деревьев зависимостей среднестатистических проектов.

Возьмём, например, платформу Node.js. Node.js — это интересный фреймворк, который позволяет запускать JavaScript-код в серверной среде. Но с его появлением появился (в виде зависимости) аккуратный и компактный менеджер пакетов NPM. Менеджеры пакетов существовали и до NPM, и NPM, определённо, не самый лучший из таких менеджеров. Но он дал программистам больше удобств, так как его разработчики учли недочёты тех менеджеров зависимостей, которые существовали до NPM. Он, по умолчанию, устанавливает пакеты локально, а не глобально. Его интерфейс командной строки изначально был создан в расчёте на работу с репозиторием пакетов. Его применение облегчает разработку и публикацию пакетов.

В результате средняя глубина дерева зависимостей в NPM составляет 4.39 пакета, в то время как такой же показатель у сравнимого менеджера пакетов (в данном случае — у PyPi) равняется 1.7. А средний размер дерева зависимостей в NPM — 86.55. В PyPi — это 7.33. Страшные цифры. Python-программисты не являются, по своей природе, более ответственными, чем JavaScript-программисты. То, что в JavaScript отсутствует хорошая стандартная библиотека, и то, что это был изначально «игрушечный» язык, созданный за неделю, делает JavaScript благодатной средой для разработки фреймворков, исправляющих его недостатки. Существует огромное количество npm-пакетов, которые реализуют мелкие элементарные действия. В других языках то же самое реализуется встроенными средствами. А NPM просто очень сильно облегчает процесс разработки и публикации пакетов.

Что произойдёт, если ECMA решит исправить некоторые недостатки JavaScript, пойдя тем же путём, которым пошли создатели Java 9 и Python 3 в попытке решить структурные проблемы соответствующих языков? Около 60% пакетов в NPM не обновлялось в течение года или более длительного периода времени. Но, несмотря на то, что эти пакеты плохо поддерживаются, их, всё равно, загружают миллиарды раз.

О том, что в JavaScript не планируется вводить изменения, нарушающие обратную совместимость, говорит и комитет ECMA в документе «One JavaScript»:

Но как избавиться от версионирования? Всегда поддерживать обратную совместимость. Это означает, что мы должны отказаться от некоторых из наших устремлений относительно «чистки» JavaScript. Мы не можем вводить в язык возможности, нарушающие обратную совместимость. Язык, поддерживающий обратную совместимость, это язык, из которого ничего не удаляют, и в котором ничего существующего не меняют. Суть этого принципа можно выразить так: «не ломайте веб».

Обсуждать достоинства вечной обратной совместимости можно без остановки. Главное тут то, что с ростом популярности JS-фреймворков колоссальная проблема зависимостей, которая всегда был присуща JavaScript, становится неизмеримо хуже. Оказывается, что те же инструменты, которые сглаживают множество структурных проблем в таком языке, как JavaScript, ведут к тому, что в новых версиях JavaScript эти проблемы невозможно исправить.

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

Итоги: стратегическое планирование, а не скорость разработки


Зависимости — это неизбежное зло, но их использование не обязательно означает неизбежное попадание проекта в ад устаревших технологий. Нам нужно начинать включать в обсуждения, касающиеся выбора технологий, вопросы о возможностях долгосрочной поддержки проектов. Никто не станет спорить с тем, что JavaScript-фреймворки способствуют разрастанию деревьев зависимостей, но несмотря на то, что NPM был разработан для серверной среды, 80% его возможностей используется во фронтенд-разработке. Мы постоянно отказываемся от старых фронтенд-технологий и заменяем их технологиями более новыми. В сообществе дизайнеров есть одна «народная мудрость», в соответствии с которой сайты подвергаются редизайну примерно каждые 3 года. В результате React-фронтенд с большим деревом зависимостей выглядит менее опасным с точки зрения модернизации устаревшего кода, чем Node.js-приложение с таким же деревом, но находящееся на более глубоком уровне архитектуры проекта.

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

И наконец, нам стоит перевести обсуждения в другую плоскость и перестать обвинять во всех грехах некие технологии только из-за того, что они устарели, и из-за того, что эти технологии созданы людьми, которые уже далеко не молоды. Большая часть COBOL-кода, существующего в мире, работает совершенно нормально. А проблемы, которые реально существуют, можно найти и в достаточно современных веб-приложениях. Тот факт, что COBOL — старый язык, к делу особо не относится. Этот факт просто отвлекает нас от проблемы растущей экосистемы кода, в которой используются технологии, жизненный цикл которых уже закончился.

Сталкивались ли вы с проблемами, связанными с использованием устаревших технологий?



RUVDS.com
RUVDS – хостинг VDS/VPS серверов

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

    +1

    Мысль по поводу расрастающихся зависимостей очень интересная. Если конкретно по JavaScript, то когда надо добавить код в страницу, я стараюсь использовать только чистый JS. jQuery по факту пока ни разу не пригодился.

      +8
      Чистый JS можно было использовать и пять, и пятнадцать лет назад. Просто jQuery удобнее.
        0

        Кому-то удобнее, кому-то нет. Я Вас понял.

          +3
          Не совсем так. 15 лет назад у каждого браузера реализация DOM и прочих Web Api сильно отличалась от других. И JQ появился, чтобы исключить зависимость от каждого конкретного браузера, чтобы дать возможность разработчикам писать кроссбраузерный код.
          В современном же вебе JQ потерял свою актуальность в связи с серьезной работой комитетов w3c по продвижению и утверждению web стандартов, и самое главное, в связи с переходом разработчиков на прогрессивные веб-фреймворки (React, Vue, Angular).
            0

            Кто-то перешёл, кто-то нет. Плюс многие коробочные расширяемые продукты типа CMS не спешат переходить и разработчики под них не хотят терять существующую поддержку. А для многих синтаксис jQuery удобнее чем нативные DOM и прочие Web API

          +6
          jQuery часто пригождается в виде «надо приделать слайдер/календарь/нав.панель» ровно как вот в той библиотечке, и встаёт выбор, или ставить jQuery и выполнить работу за час или писать всё с нуля «только на чистом JS» минимум день, а то и неделю. Заказчики, почему-то, обычно не одобряют такое стремление к чистоте.
          0

          Основная проблема — демотивация: читаешь анонсы, смотришь исходники, пробуешь дома новые версии используемых языков, фреймворков, либ, радуешься как они упрощают и ускоряют разработку, а потом возвращаешься на работу… И не можешь сделать какой-нибудь packager update потому что одна из зависимостей про новую версию язіка и не слышала...

            +3
            Молодым программистам никто не предлагает изучать COBOL. И если даже они этот язык и выучат, то сотни, а кто-то скажет, что и тысячи COBOL-вакансий не рассчитаны на новичков.
            COBOL для мейнфреймов не рассчитан на новичков потому, что это такая vendor-lock технология от IBM. Без посторонней помощи разобраться там практически не возможно лишь потому, что они продают всем заинтересованным изучение COBOL и консалтинг за кучу денег. Правда и готовят на этих курсах как космонавтов. В одной из своих публикаций представитель компании хвастался, что по статистике до финиша доходит не более пяти процентов обучаемых. Эти целеустремленные ребята будут мега-надежными сотрудниками для тех компаний, кто использует их мейнфреймы.

            Другими словами, переход с Java 8 на Java 9, весьма вероятно, может потребовать переписывания больших объёмов кода.

            Это не совсем так. Основная причина проблемы не техническая. Благодаря стараниям Oracle, Java 8 стала последней версией с нормальной лицензией.

            Что произойдёт, если ECMA решит исправить некоторые недостатки JavaScript, пойдя тем же путём, которым пошли создатели Java 9 и Python 3 в попытке решить структурные проблемы соответствующих языков?
            Радикальные изменения в JS произошли позже, чем появился Python3. На мой взгляд ECMA анализировали предыдущий опыт, в том числе перехода Python2 на Python3, и выбрали для себя абсолютно правильную стратегию. Для принятия в стандарт, любая новая фича должна быть обкатана на живых проектах и иметь рабочий транспиллер, позволяющий даунгрейдить код.
              +1
              Для принятия в стандарт, любая новая фича должна быть обкатана на живых проектах и иметь рабочий транспиллер, позволяющий даунгрейдить код.

              proper tail call кажется была исключением в ES 2005 — только в 2018, емнип, только Apple её кое-как реализовала. Остальные может и чешутся, но как-то без результатов уже 15 лет.

                0
                Там все не просто. В хроме честно старались заимлементить как это сделано в Safari, но потом выпилили обратно bugs.chromium.org/p/v8/issues/detail?id=4698. Основная проблема с тем, что оптимизация хвостовой рекурсии непредсказуемо ломает стектрейсы при отладке. Для Apple это с самого начала не было проблемой («у вас проблемы? — игнорируйте»), а Google просто внимательнее относится к разработчикам.
                0
                Что мешает студентам запустить эмулятор манфрейма и поработать на нем?
                  +1
                  Можно и без эмулятора. Есть, к примеру, PUB400.COM — публичный сервер на платформе AS/400. На этой платформе поддерживается концепция ILE — Integrated Language Environment в которую входят COBOL, RPG, CL, C, C++ Т.е. все эти языки там поддерживаются (компиляторы на уровне ОС зашиты). На том же уровне ОС там интегрирована БД (DB2) с поддержкой SQL. Документации на сайте IBM достаточно.

                  Регистрация бесплатная. Ресурсов дают немного, но для небольших учебных задач вполне хватит. Для работы вполне достаточно установить Access i Client Solutions (пакет для работы с серверами AS/400, включает в себя эмулятор терминала IBM5250, средство для работы со spool файлами, интерактивный SQL, средство для доступа к IFS — интегрированная файловая система и еще что-то). Качается бесплатно с сайта IBM. Можно еще бесплатный ILE Editor поставить — небольшая среда для работы с исходниками на локальном компе и заброса их на сервер.

                  Так что проблем где попробовать поработать с мейнфреймом нет.
                    0
                    Думаю дело в том, что z/OS сильно отличается от привычных операционных систем. Надо иметь сильную мотивацию и кучу времени, чтобы начать заниматься этим в смысле работы. С первого взгляда все выглядит так, что разработчики придумали какой-то альтернативный мир, где даже обычные вещи называются иначе и очень длинными словами. Привычные шаблоны и опыт туда практически не переносятся (обратно кстати тоже). По сравнению с ней Unix и Windows это близнецы. Когда был интерес, я первым делом споткнулся на создании файла. Обычно, чтобы написать какую-нибудь программу, создаешь файл в первой попавшейся директории и в него набиваешь свой неимоверно крутой код стыренный со stackoverflow. У этих товарищей даже здесь все придумано иначе — директорий и файлов в привычном смысле тупо нет. Потом разобрался, однако количество wtf!? было чересчур, что конечно же привело в дикий восторг.
                      +2
                      С IMB z не работал, работаю с IBM i. По описанию все тоже самое.

                      Хочешь что-то написать? Создай сначала объект типа *FILE с аттрибутом PF-SRC, потом в нем создай элемент (member) и в него уже можешь помещать свой код.

                      Благо у нас все это уже автоматизировано

                      Причем, фактически, этот самый PF-SRC является таблицей БД (объект типа *FILE с аттрибутом PF-DTA) с записью из трех полей — номер строки (sequence), временной меткой и собственно строкой. И его содержимое доступно для чтения (или записи) обычным SQL:

                      -- Выбираем нужный элемент в файле (их может быть много)
                      CREATE ALIAS QTEMP.FILEMEMBER FOR MYLIB.MYFILE(MYMEMBER);
                      
                      -- Читаем содержимое
                      SELECT * FROM QTEMP.FILEMEMBER;
                      


                      Мы этим пользуемся для тестирования — в поставке создается pf-src с элементами-сценариями и элементами с данными, а дальше тестовой программе указывается имя сценария, она читает его из pf-src, оттуда же читает данные и вызывает тестируемую программу с передачей ей данных

                      Система эта очень необычна. Вот что про нее пишет один из отцов-основателей Френк Солтис в книге «Основы AS/400»

                      Менее года назад я был в Буэнос-Айресе на встрече с группой пользователей этой системы. По окончании встречи молодой репортер газеты «La Nacion» спросил меня: «Сформулируйте, пожалуйста, коротко причины того, почему в AS/400 столь много новшеств?». И я ответил: «Потому что никто из ее создателей не заканчивал MIT.» Заинтригованный моим ответом, репортер попросил разъяснений. Я сказал, что не собирался критиковать MIT, а лишь имел в виду то, что разработчики AS/400 имели совершенно иной опыт, нежели выпускники MIT. Так как всегда было трудно заставить кого-либо переехать с восточного побережья в 70-тысячный миннесотский городок, в лаборатории IBM в Рочестере практически не оказалось выпускников университетов, расположенных на востоке США. И создатели AS/400 — представители «школ» Среднего Запада — не были так сильно привязаны к проектным решениям, используемым другими компаниями.


                      В целом это объектная система. Т.е. в ней «все есть объект». Кажды объект имеет имя и тип. Имя поменять можно, но тип не меняется — каким его создали, таким он и будет. И с каждым объектом можно делать только то, что разрешено делать с данным типом объектов.

                      Очень много концепция и сущностей, не имеющих аналогов в других системах.

                      Все это к тому, что для таких систем есть некоторый порог входа и он не очень низкий. Обычно несколько недель уйдет только на то, чтобы хоть как-то начать в ней ориентироваться и понимать что где и как.
                      0
                      дайте линк на репку в гитхабе с «емулятором мейнфрейма» )
                      0
                      Благодаря стараниям Oracle, Java 8 стала последней версией с нормальной лицензией

                      Вроде бы, на AdoptOpenJDK никто не жаловался. А с релизами 9+ от Oracle надо быть аккуратным, да
                      +1

                      Неплохой перевод, но точка в качестве десятичного разделителя режет глаз.

                        +3
                        Опасения по поводу возраста COBOL-программистов не обоснованы просто потому, что достаточно опытному программисту не составит большого труда поправить программу на незнаком языке (при наличие описания этого языка, хотя даже это не обязательно).

                        Я, например, сейчас поддерживаю проект на objective-C, а также иногда исправляю ошибки в проекте на C#, хотя никогда ни того ни другого не изучал. Могу ли я написать на этих языках приличный код? нет, конечно. Но наложить заплатку — пусть кривую до безобразия, но чтоб работало — с этим проблем пока нет.

                        С устаревшими вроде jQuery действительно не так просто, они сложнее, чем какой-то там COBOL.
                          +1
                          Я бы не был столь оптимистичен. Языки типа COBOL, RPG имеют весьма специфический синтаксис (особенно старый, fixed style, RPG где важно позиционирование). Кроме того, они имеют достаточно специфическую логику и специфические типы переменных. И работают в весьма специфическом окружении (часто программа может перестать работать просто потому что что-то поменялось в окружении).

                          В общем, чтобы на нем писать нужно не только вникнуть в сам язык, но еще и понимать хотя бы в общих чертах, особенности платформы на которой все это работает.
                            0
                            Ну, «понимать особенности платформы» — это и есть «старение технологий» про которые в статье говорится, а вовсе не особенность языка ;)

                            Впрочем, полностью согласен с тем, что поддерживать legacy проект на древнем языке значительно труднее, чем что-то относительно современное. Но, как мне кажется, проблема не в том, что «молодое поколение не знает COBOLа», а в этом самом специфическом окружении — если программа может перестать работать просто потому что что-то поменялось в окружении, то даже человеку свободно владеющим этим языком (но не знакомым с данной программой) будет сложно что-то поменять.
                              +1
                              Ну «окружение» можно понимать в широком смысле. Например, у мне на доработку как-т попала программа, которая начала работать некорректно просто потому, что у нее стаяла (обычная для нас) группа активации *CALLER, а в вызывающей программе по каким-то соображением поменяли группу активации с *CALLER на *NEW. Вылечилось заменой у себя группы активации с *CALLER на свою именованную.

                              Тут вопрос был не в синтаксисе, а в понимании что такое группы активации на AS/400 и как они работают. Аналога им на других платформах нет. Это специфика.

                              Но я на этой платформе уже несколько лет, а прили человек со стороны, он просто не поймет почему так происходит, даже имя в наличии все джоблоги и дампы (которые тоже надо привыкнуть читать — часто дефекты приходят именно в таком виде — «программа падает, вот джоблог и дамп»).

                              Я к тому, что если вы всю жизнь писали на Java и JS, а потом легко нашли ошибку в прграмме на C#, то это совершенно не значит что вы так же легко найдете ошибку в программе на COBOL или RPG, работающей на AS/400.

                              И дело не в легаси. Там может быть вполне современный ILE код. Программа состоит из десятка модулей, част из которых написана на RPG, часть на SQLRPG (надмножество над RPG, позволяющее вставлять непосредственно в RPG код SQL запросы, часть на C/C++ — тут еще надо знать как правильно написать RPG прототип для вызова Сишной функции из RPG кода).

                              Суть в том, что все это глубокий бэкенд — никаких фреймворков. Есть язык с его возможностями и логикой и есть системные API которыми можно пользоваться при необходимости. Ну особенности системы. Например, «а почему я поставил try, а программа все равно падает с ошибкой?».

                              Но то, что опытному разработчику все это под силу — тут полностью солгасен. Не согласен со сроками. У нас стандарт — 3 месяца. Готовых разрабов на RPG под AS/400 не найти. Посему берутся обычные (желательно с опытом работы на С/С++). И обучаются. Как правило, месяца через полтора человек уже готов решать несложные типовые задачи. В полную силу входит через год-полтора.
                                0
                                Не, на Java и JS я написал в общей сложности всего 3 программы, я больше по C/C++ специализируюсь, и под «не составит труда» я не имел в виду «может сделать быстро». ;)

                                В любом случае, я, наверно, просто неточно выразился (и, скорее всего, действительно был слишком оптимистичен и не дооценивал, что надо знать для того, чтобы «быть COBOL-программистом»). Изначально я имел в виду примерно то же самое, что ваше:

                                > Тут вопрос был не в синтаксисе, а в понимании что такое группы активации на AS/400 и как они работают.

                                Так что, сравнение с JQuery беру обратно, был не прав, а во всем остальном мы вроде согласны.
                                  +1
                                  Ну в целом да. Я тоже не имел ввиду что это невозможно. Просто потребует больше времени чем может показаться изначально.

                                  COBOL не пробовал, хотя он поддерживается на той платформе где работаю (там компиляторы сразу в составе ОС идут) Но синтаксис… И концепции… Меня старый RPG-то убивает своими подходами — все переменные глобальные, процедуры не используются, сплошной линейный код с подпрограммами (как в древнем Бейсике)

                                  Новые, конечно, пишем уже нормально — вполне себе процедурный язык (хотя использование подпрограмм внутри процедур иногда бывает удобным когда надо повторяющийся кусок кода вынести).

                                  Хотя в анамнезе тоже много (где-то с конца 80-х) лет на С/С++, так что легко и с удовольствием использую его для написания отдельных модулей там, где это удобнее сделать на С. Благо, концепция ILE это позволяет.

                                  Но определенные преимущества у RPG тоже есть. Он изначально для коммерческих расчетов делался (как и COBOL). Есть поддержка типов с фиксированной точкой (рекуррентное соотношение Мюллера на таких типах расходится раза в два медленнее чем на типах с плавающей точкой).

                                  Там достаточно богатый арсенал для работы с временем и датой (одних только форматов даты там… и все они легко конвертируются друг в друга). Неплохо работает со строками (если рассматривать строку как целый объект, а не последовательность байт). Есть некоторые заморочки при работе с указателями…

                                  Но в целом язык как язык если понимать что он сделан под конкретные задачи.
                          +1

                          Отвечу за Java: на самом деле одна из лучших технологий, которая максимально поддерживает обратную совместимость. То есть легаси код, написанный под Java 1.1, с большой вероятностью заработает на последней Java без всякого допиливания. Переход на Java 9+ не столь критичен, а лишь затрагивает способ упаковки и изолирования кода (modulepath), кроме того он опционален (classpath все еще в моде). Гораздо более тяжелым бы переход с Java 7 на Java 8 — потребовалось переписывание практически всей экосистемы, затачивая ее под лямбды. Но ничего, как-то справились.


                          Те не менее сравнивать ситуацию с COBOL с современными проектами не совсем корректно, потому как сильно изменилась бизнес-модель и цикл разработки. Если раньше клиенты платили единоразово за продукт или функционал, то сегодня компании продают по большей части сервис, который включает себя поддержку и сопровождение втечение всего цикла использования, а также гарантирует актуальность используемых технологий. Вопросы сопровождения и миграции, а также связанные с ними расходы, провайдер как правило берет на себя.

                            +1
                            потребовалось переписывание практически всей экосистемы, затачивая ее под лямбды

                            Это какой же код на Java 7 не заработает на Java 8, и его потребуется переписывать?
                            При желании — можно переписать, сделав покомпактнее (и, может, побыстрее)
                              +1
                              Это какой же код на Java 7 не заработает на Java 8, и его потребуется переписывать?

                              По большей части тот, который изначально заточен под Java 7, но запускается в среде Java 8 с классами, откомпилированными для восьмерки: фреймворки, библиотеки, сервера приложений. Основные сбои — это непроспособленность к новым default-методам коллекций, оптимистичное использование рефлексии, сериализация, операции на уровне байт-кода. Кроме того лямбды потребовали пересмотра и эволюции API для большинства фреймворков и библиотек. Однако jdk8 нарушало соместимость по байт-коду с ранними версиями, поэтому во многих проектах долгое время поставлялись две версии библиотек: для jdk7 и jdk8.

                              0
                              То есть легаси код, написанный под Java 1.1, с большой вероятностью заработает на последней Java без всякого допиливания.

                              особенно gradle при сборке андроид-проектов. на совершенно вообщем то ровном месте (добавление databinding к одной из активити хотя в проекте она уже).
                              Гуглинг показывает что кто альтернативно-умный выкинул jaxb.
                              Решение — либо использовать внешнюю java8 либо встроенную java Android Studio (что в некоторых случаях — неудобно очень).
                              –1
                              Чето статья ни о чем, открываем апворк и ищем по кобол.
                              www.upwork.com/search/profiles/?q=COBOL
                              С 10+ годами опыта от 11 баксов в час полно предложений. о каком кризисе вообще речь?
                                0
                                Вот интересно.
                                То что используются старые версии Pyton, не поддерживаемые производителем, это нехорошо, по мнению автора. И то, что в JavaScript поддерживается обратная совместимость — тоже не есть хорошо, по мнению автора. Ужели писать веб на COBOL?
                                  +1
                                  Давайте ещё вспомним Delphi, который умирает последние 20 лет и никак не умрёт. При этом на нём клепают проги против короновируса… потому что это быстро
                                  community.idera.com/developer-tools/b/blog/posts/delphi-in-healthcare-fighting-the-corona-pandemic
                                  В статье описаны очевидные и логичные вещи…

                                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                  Самое читаемое