Pull to refresh

Comments 30

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

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

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

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

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

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

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

Молодым программистам никто не предлагает изучать 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, и выбрали для себя абсолютно правильную стратегию. Для принятия в стандарт, любая новая фича должна быть обкатана на живых проектах и иметь рабочий транспиллер, позволяющий даунгрейдить код.
Для принятия в стандарт, любая новая фича должна быть обкатана на живых проектах и иметь рабочий транспиллер, позволяющий даунгрейдить код.

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

Там все не просто. В хроме честно старались заимлементить как это сделано в Safari, но потом выпилили обратно bugs.chromium.org/p/v8/issues/detail?id=4698. Основная проблема с тем, что оптимизация хвостовой рекурсии непредсказуемо ломает стектрейсы при отладке. Для Apple это с самого начала не было проблемой («у вас проблемы? — игнорируйте»), а Google просто внимательнее относится к разработчикам.
Что мешает студентам запустить эмулятор манфрейма и поработать на нем?
Можно и без эмулятора. Есть, к примеру, 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 поставить — небольшая среда для работы с исходниками на локальном компе и заброса их на сервер.

Так что проблем где попробовать поработать с мейнфреймом нет.
Думаю дело в том, что z/OS сильно отличается от привычных операционных систем. Надо иметь сильную мотивацию и кучу времени, чтобы начать заниматься этим в смысле работы. С первого взгляда все выглядит так, что разработчики придумали какой-то альтернативный мир, где даже обычные вещи называются иначе и очень длинными словами. Привычные шаблоны и опыт туда практически не переносятся (обратно кстати тоже). По сравнению с ней Unix и Windows это близнецы. Когда был интерес, я первым делом споткнулся на создании файла. Обычно, чтобы написать какую-нибудь программу, создаешь файл в первой попавшейся директории и в него набиваешь свой неимоверно крутой код стыренный со stackoverflow. У этих товарищей даже здесь все придумано иначе — директорий и файлов в привычном смысле тупо нет. Потом разобрался, однако количество wtf!? было чересчур, что конечно же привело в дикий восторг.
С 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 — представители «школ» Среднего Запада — не были так сильно привязаны к проектным решениям, используемым другими компаниями.


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

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

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

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

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

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

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

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

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

Впрочем, полностью согласен с тем, что поддерживать legacy проект на древнем языке значительно труднее, чем что-то относительно современное. Но, как мне кажется, проблема не в том, что «молодое поколение не знает COBOLа», а в этом самом специфическом окружении — если программа может перестать работать просто потому что что-то поменялось в окружении, то даже человеку свободно владеющим этим языком (но не знакомым с данной программой) будет сложно что-то поменять.
Ну «окружение» можно понимать в широком смысле. Например, у мне на доработку как-т попала программа, которая начала работать некорректно просто потому, что у нее стаяла (обычная для нас) группа активации *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 не найти. Посему берутся обычные (желательно с опытом работы на С/С++). И обучаются. Как правило, месяца через полтора человек уже готов решать несложные типовые задачи. В полную силу входит через год-полтора.
Не, на Java и JS я написал в общей сложности всего 3 программы, я больше по C/C++ специализируюсь, и под «не составит труда» я не имел в виду «может сделать быстро». ;)

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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