Комментарии 125
НЛО прилетело и опубликовало эту надпись здесь
Я писал на Коболе. Куда обращаться?
НЛО прилетело и опубликовало эту надпись здесь
Да, это так. Любой бизнес всегда имеет расходы. И это ещё вопрос, что было бы дешевле и надёжнее, если бы переписывать систему каждые 10 лет на новомодных технологиях. Потому что это было бы 5 новых внедрений новых систем, 5 раз сбор требований и вот это всё (надеюсь не нудно объяснять требования собранные 10 лет назад сейчас никем восприниматься не будут). Я считаю себя в меру старпёром по отношению к технологиям, и согласен что COBOL устарел, но сказать что переписывать всё потому что не модно я не могу.
Эх, если бы «каждые 10».
Ну, более-менее средний бизнес — порядка пары сотен работающих, 1с — шестерка почти не считается 1997 — 7.5, с 2000-7.7, с 12-8.2 (обычные формы), с 2017 — 8.3 (управляемые). — получается «каждые 5».
Ну, более-менее средний бизнес — порядка пары сотен работающих, 1с — шестерка почти не считается 1997 — 7.5, с 2000-7.7, с 12-8.2 (обычные формы), с 2017 — 8.3 (управляемые). — получается «каждые 5».
Тем более. И вот я вообще не уверен что затраты сейчас будут больше чем 10 раз переписать систему.
Не совсем понял…
в смысле, переписать один раз в 40 лет — затраты больше, чем переписать 10 раз за эти 20 лет? наверняка. Даже прямых меньше. а основные затраты — косвенные
в смысле, переписать один раз в 40 лет — затраты больше, чем переписать 10 раз за эти 20 лет? наверняка. Даже прямых меньше. а основные затраты — косвенные
Нет, я считаю что переписать раз в 40 лет это кратно меньше затрат чем 10 раз переписать, 10 раз отладиться, 10 раз внедриться и переучить персонал.
Так если с функционалом всё ок, то можно ж переписывать с сохранением интерфейса, тогда переучивать никого не нужно будет.
Вот серьёзно, так бывает? Кто-нибудь вживую это видел? И второй вопрос, зачем? Т.е. если ничего не измениться, то зачем переписывать?
Для пользователя не изменится. А архитектура приложения и управлением им может кардинально измениться — в реалиях тех времен, когда это писалось актуальным было: если раньше синхронизация данных, введенных операторами, была через дискеты, то стала сразу через сеть (кто-то ещё помнит Netware Novell). И уже современнее: потом приложения стали работать в браузере и появилось удобство администрирования, большая безопасность (данных на компьютере пользователя нет; авторизация; SSL «из коробки» или другие криптопровайдеры), простота обновления. А основной интерфейс при этом часто не менялся, за исключением добавления новых возможностей.
Переписывать для упрощения поддержки и внедрения нового функционала. Однажды так переписали лепру, но половина функционала после этого ещё много лет не работала.
Вот серьёзно, так бывает? Кто-нибудь вживую это видел?Настолько старые вещи не пробовал, а вот, например, в переписывании раздела веб-приложения с мешанины ASP.NET Razor+jQuery+Knockout на SPA с React/Redux/Typescript и REST API, с полным сохранением UI — участвовал. Подо всем этим было переписано ещё и часть кода под существующим API, с сохранением интерфейса (да, опять сохранение интерфейса). Зачем? Затем, что старый код не работал приемлемо на достаточно больших данных, а дорабатывать его означало всё равно местами переписывать с нуля, только ещё и копаясь в древних версия библиотек без типизации и нормальной поддержки IDE.
И второй вопрос, зачем? Т.е. если ничего не изменитВы серьёзно считаете, что если интерфейс не поменялся, то и ничего не поменялось? Сам смысл отделения интерфейса от реализации — именно в том, чтобы менять реализацию, не меняя интерфейса.ься, то зачем переписывать?
Вы слабо себе представляете масштаб бедствия.
Статья эта — перепечатка, давно уже по сети гуляет. Я в первый раз столкнулся с ней на CNews — www.cnews.ru/news/top/2020-04-07_ssha_izza_koronavirusa_ponadobilis
Так вот, там был абзац в конце, который сюда не попал:
Вот вам масштабы. Можете сравнить это с тем, с чем сталкивались Вы.
Как разработчик в банке могу вам сказать что подобная операция потребует
1. Немалого количества человеко-часов работы аналитиков для проработки FSD.
2. Огромного количества человеко-часов работы разработчиков для реализации всего этого в коде — количество строк кода, работающего на банковских серверах я лично затрудняюсь оценить количественно даже примерно, а качественно оцениваю как очень-очень-очень дофига.
3. Опять аналитики — любое, самое минимальное изменение в коде требует ретеста. Тестирование ПО проходит в несколько этапов — компонентное (соответствие кода требованиям FSD), бизнес (соответствие FSD+реализации заданию на разработку от бизнеса), интеграционное (непротиворечивость различных компонентов системы друг другу, отсутствие конфликтов и паразитных влияний), нагрузочное (потребление ресурсов и поведение в условиях пиковых нагрузок).
Ну и последнее — внедрение. Банк штука такая — его невозможно становить даже на час «подождите, мы тут ПО обновляем». Так что все это должно внедряться или путем постепенной замены элементов действующей системы или включением параллельной системы, получением подтверждения что она на 100% повторяет работу старой, незаметным для пользователя переключением на нее и потом вывода из эксплуатации новой старой системы.
Это огромная нагрузка на сопровождение и поддержку.
В общем, масштаб затрат (времени, денег, ресурсов) ту колоссальный. И просто так на это никто не подпишется. Это не отдельный сайт, который можно положить на час-два-три и кроме недовольства пользователей ничего не будет.
Статья эта — перепечатка, давно уже по сети гуляет. Я в первый раз столкнулся с ней на CNews — www.cnews.ru/news/top/2020-04-07_ssha_izza_koronavirusa_ponadobilis
Так вот, там был абзац в конце, который сюда не попал:
К числу причин, по которым организации не спешат отказываться от COBOL и переходить программы, созданные при помощи актуальных языков программирования – это дороговизна обновления. На своем примере это доказал Банк содружества Австралии, решившийся на полную замену всех приложений, написанных на COBOL.
Представители банка сообщили, что переход на новое ПО занял пять лет – он проходил в период с 2012 по 2017 гг. Размер затрат на это крупномасштабное мероприятие известен – апдейт обошелся банку почти в $750 млн.
Вот вам масштабы. Можете сравнить это с тем, с чем сталкивались Вы.
Как разработчик в банке могу вам сказать что подобная операция потребует
1. Немалого количества человеко-часов работы аналитиков для проработки FSD.
2. Огромного количества человеко-часов работы разработчиков для реализации всего этого в коде — количество строк кода, работающего на банковских серверах я лично затрудняюсь оценить количественно даже примерно, а качественно оцениваю как очень-очень-очень дофига.
3. Опять аналитики — любое, самое минимальное изменение в коде требует ретеста. Тестирование ПО проходит в несколько этапов — компонентное (соответствие кода требованиям FSD), бизнес (соответствие FSD+реализации заданию на разработку от бизнеса), интеграционное (непротиворечивость различных компонентов системы друг другу, отсутствие конфликтов и паразитных влияний), нагрузочное (потребление ресурсов и поведение в условиях пиковых нагрузок).
Ну и последнее — внедрение. Банк штука такая — его невозможно становить даже на час «подождите, мы тут ПО обновляем». Так что все это должно внедряться или путем постепенной замены элементов действующей системы или включением параллельной системы, получением подтверждения что она на 100% повторяет работу старой, незаметным для пользователя переключением на нее и потом вывода из эксплуатации новой старой системы.
Это огромная нагрузка на сопровождение и поддержку.
В общем, масштаб затрат (времени, денег, ресурсов) ту колоссальный. И просто так на это никто не подпишется. Это не отдельный сайт, который можно положить на час-два-три и кроме недовольства пользователей ничего не будет.
Погодите, вы приводите цену полного обновления как ответ на мой поинт о том, что можно что-то внутри обновить, не поменяв ничего снаружи?
Банк штука такая — его невозможно становить даже на час «подождите, мы тут ПО обновляем».Какое отношение это имеет к обсуждаемой статье про службу учёта безработных?
Так что все это должно внедряться или путем постепенной замены элементов действующей системыЯ где-то писал, что нужно менять всё сразу? Отделение интерфейса от реализации это же не (только) про пользовательский интерфейс, но и про интерфейс взаимодействия элементов системы.
В данноом случе «обновить что-то» не получится. Там все на коболе. Ну или 80-90%. А тут речь о том что «почему бы не переписать это на нормальном языке». Так вот переписывать придется все.
И не стоит думать что служба по учету безработных сильно проще банковского ПО. Уверен, что не проще. И не меньше по объему обрабатываемых данных. И ее нельзя вот так взять и остановить «подождите пока перепишем».
И требования по надежности там не меньше.
Так что мой пост просто как пример того, что просто так системы такого масштаба не переписываются. Очень затратно.
И тут речь ведь не о том, что оно не работает. А о том, что оно не справляется с пиковой нагрузкой. Т.е. требуется не просто переписать, требуется оптимизировать. А это само по себе непростая задача. Обычно сначала проводится аудит (у нас для этого вызывают спецом из IBM). Аудиторы проводят нагрузочные исследования, выявляют наиболее ресурсоемкие участки кода, а потом уже разработчики морщат мозг на тем как это можно сделать эффективнее.
Сам иногда такими вещами занимаюсь — у нас целый список задач на оптимизацию в беклоге висит, как время от текучки чуть освободилось, берем в работу.
И не стоит думать что служба по учету безработных сильно проще банковского ПО. Уверен, что не проще. И не меньше по объему обрабатываемых данных. И ее нельзя вот так взять и остановить «подождите пока перепишем».
И требования по надежности там не меньше.
Так что мой пост просто как пример того, что просто так системы такого масштаба не переписываются. Очень затратно.
И тут речь ведь не о том, что оно не работает. А о том, что оно не справляется с пиковой нагрузкой. Т.е. требуется не просто переписать, требуется оптимизировать. А это само по себе непростая задача. Обычно сначала проводится аудит (у нас для этого вызывают спецом из IBM). Аудиторы проводят нагрузочные исследования, выявляют наиболее ресурсоемкие участки кода, а потом уже разработчики морщат мозг на тем как это можно сделать эффективнее.
Сам иногда такими вещами занимаюсь — у нас целый список задач на оптимизацию в беклоге висит, как время от текучки чуть освободилось, берем в работу.
И не стоит думать что служба по учету безработных сильно проще банковского ПО. Уверен, что не проще. И не меньше по объему обрабатываемых данных. И ее нельзя вот так взять и остановить «подождите пока перепишем».Думаю, что и проще, и данных меньше, и обновляться можно в нерабочие часы сколько угодно. У неё же пользователи — только горстка госслужащих.
И требования по надежности там не меньше.
Вот не уверен. Иначе откуда проблема с пиковыми нагрузками
Ну, может, во времена её создания считалось нормальным сохранять данные по 5 минут, например, не знаю.
Честно говоря, из своего опыта, я даже не уверен что проблема там в коболе как таковом. Это может быть что-то платформенное.
Но чтобы решить эту проблему нужно переписать часть кода. Который на коболе.
Ну вот как пример из нашей практики. В режиме пиковой нагрузки одна из таблиц значительно разрослась и, совершенно неожиданно, время на аллокацию дополнительного простраства при добавлении новых записей подскочило в 100 раз (в сто раз!!!) что привело к существенному замедлению всей работы. И это в условиях пика!
Чтобы система вообще не встала сопровождение было вынужденно отключить один из модулей (временно, до выяснения проблемы). В результате в течении пары часов не проходили расчеты по пластиковым картам. В масштабах страны, между прочим.
Ситуацию поправили сначала временным решением, потом внесли изменения в код.
Вполне возможно, что там ситуация ну если не подобная, то носит схожий характер — надо где-то что-то переписать более оптимально. Но на коболе. Который для этого желательно знать не по краткому курсу, а на опыте реального использования.
Но чтобы решить эту проблему нужно переписать часть кода. Который на коболе.
Ну вот как пример из нашей практики. В режиме пиковой нагрузки одна из таблиц значительно разрослась и, совершенно неожиданно, время на аллокацию дополнительного простраства при добавлении новых записей подскочило в 100 раз (в сто раз!!!) что привело к существенному замедлению всей работы. И это в условиях пика!
Чтобы система вообще не встала сопровождение было вынужденно отключить один из модулей (временно, до выяснения проблемы). В результате в течении пары часов не проходили расчеты по пластиковым картам. В масштабах страны, между прочим.
Ситуацию поправили сначала временным решением, потом внесли изменения в код.
Вполне возможно, что там ситуация ну если не подобная, то носит схожий характер — надо где-то что-то переписать более оптимально. Но на коболе. Который для этого желательно знать не по краткому курсу, а на опыте реального использования.
НЛО прилетело и опубликовало эту надпись здесь
«Работает — не трогай» нормально, проблема в данном случае(как я понял) что уже не работает, а они все еще пытаются реанимировать свою старую умершую инфраструктуру, а не перевести все на новое железо и софт, чтобы не иметь проблем с ее поддержкой хоть на какой-то срок.
Да судя по всему работает, просто систему никто не рассчитывал на рост нагрузки в 100 раз, что с системами иногда случается в процессе перевода с пред прода/теста на прод :), а вот увеличить производительность просто нашлёпав инстансов в avs архитектура не позволяет...
Сначала экономишь бюджет на работе с тех долгом, потом выступаешь с новостями Извиняйте мы внезапно узнали о негибкости наших технологий
Вы забыли про цену ошибки. Для систем уровня государства она очень не маленькая. В 21-м веке на Нью-Йоркской фондовой бирже еще использовали телетайпы. Бывает, что дешевле держать заводик по производству нужного старого оборудования, чем переделывать систему на новое.
С программами — так же. А чтобы находились специалисты — менеджмент должен работать а не… И понимание того что для таких языков придётся иметь избыточный штат и платить иногда просто за факт присутствия на работе. Потому что когда припечёт взять таких спецов будет не где.
С программами — так же. А чтобы находились специалисты — менеджмент должен работать а не… И понимание того что для таких языков придётся иметь избыточный штат и платить иногда просто за факт присутствия на работе. Потому что когда припечёт взять таких спецов будет не где.
НЛО прилетело и опубликовало эту надпись здесь
Это вы наверно с веб языками перепутали. У явы и шарпа основные фреймворки используемые в энтерпрайзе ненамного младше самих языков.
Хм, Spring Framework с 2002 года, вроде ещё доминирует на рынке.
Да будут они через 10 лет жить и процветать.
Вы и правы и в то же время нет. Сейчас подход поменялся.
Раньше язык создавался, жил какое-то время не меняясь и помирал, когда появлялся более удобный язык.
Сейчас языки постоянно развиваются. Java сейчас и Java 15 лет назад — это две огромные разницы.
По факту, происходит точно такая же смена поколений языков, но теперь они делают это не «всё выкинуть и переписать с нуля», а итеративно, по возможности сохраняя старые наработки и обратную совместимость в пределах экосистемы. Соответственно, через 20 лет программу нужно будет переписывать не с Java на «убийцу Java», а с устаревшего диалекта Java на современный, что на порядок проще.
Раньше язык создавался, жил какое-то время не меняясь и помирал, когда появлялся более удобный язык.
Сейчас языки постоянно развиваются. Java сейчас и Java 15 лет назад — это две огромные разницы.
По факту, происходит точно такая же смена поколений языков, но теперь они делают это не «всё выкинуть и переписать с нуля», а итеративно, по возможности сохраняя старые наработки и обратную совместимость в пределах экосистемы. Соответственно, через 20 лет программу нужно будет переписывать не с Java на «убийцу Java», а с устаревшего диалекта Java на современный, что на порядок проще.
Тут еще надо знать особенности кобола, ориtнтированные именно на бизнес-вычисления.
Один из аспектов описывался тут:
habr.com/ru/company/ruvds/blog/467251
habr.com/ru/company/ruvds/blog/467253
Из современных (по крайней мере развивающихся ныне) языков наиболее близок RPG.
Один из аспектов описывался тут:
habr.com/ru/company/ruvds/blog/467251
habr.com/ru/company/ruvds/blog/467253
Из современных (по крайней мере развивающихся ныне) языков наиболее близок RPG.
Нет. Это обратная сторона медали «Мы обновились и перестаём выпускать и поддерживать старые версии, даже за деньги».
Во многом те системы были надёжны из за однозначности и строгости в том числе входящих в них языков. Да и просто, они были надёжны. Чего не скажешь о современной флеш-памяти, не говоря уже об SSD.
Проблема же со специалистами очень несложно решается при условии наличия адекватных языков программирования (прежде всего я говорю здесь об однозначности интерпретации программного кода) использованием трансляторов, например, из Ada в Pascal, и в обратную сторону (там конечно есть ограничения, и не мало, но тем не менее).
Во многом те системы были надёжны из за однозначности и строгости в том числе входящих в них языков. Да и просто, они были надёжны. Чего не скажешь о современной флеш-памяти, не говоря уже об SSD.
Проблема же со специалистами очень несложно решается при условии наличия адекватных языков программирования (прежде всего я говорю здесь об однозначности интерпретации программного кода) использованием трансляторов, например, из Ada в Pascal, и в обратную сторону (там конечно есть ограничения, и не мало, но тем не менее).
ССД достаточно надёжны. В случае настоящих больших систем — HDD и SSD являются расходниками. Они выкупаются целыми партиями у производителя. Данные всегда резервируются и существуют целые датацентры в которых биороботы, а кое-где и обычные роботы, целыми днями выкидывают старые диски и втыкают новые. Так вот, у HDD в зависимости от партии и производителя время жизни всегда было 3-5 лет. У SSD среднее время измеряется циклами перезаписи и близящаяся смерть прекрасно мониторится контроллером.
Нет, SSD менее надёжен чем HDD. Умирают SSD, как правило, молча и внезапно, не давая шанса скопировать данные. Контроллер зачастую показывает проблему постфактум, когда диск уже превратился в кирпич, а за день до этого бодро рапортует о превосходном здоровье, и клятвенно обещает прослужить ещё столько же, сколько он уже прослужил. Можно сказать, что на сегодняшний день SSD — самый ненадёжный носитель из существующих.
Нужно же учитывать, что текущие специалисты Cobol'а сейчас как раз находятся в основной зоне риска короновируса.
Коронавирус резко увеличил спрос на ИВЛ со стороны кобол-программистов.
Неужели за столько лет нельзя было сделать транслятор с какого-нибудь подмножества модного современного языка на Кобол и назад? Хоть бы с Питона.
Кобол — древний и не бог весть какой сложный язык.
Кобол — древний и не бог весть какой сложный язык.
НЛО прилетело и опубликовало эту надпись здесь
Дело в том что современный подход к Коболу не лучше. Они же не просят написать новый модуль на нем. В реальном предприятии ТЗ будет в виде: нужна веб морда, с бекендом (это хорошо если никому в голову еще не взбредет сюда микросервисы всунуть), который может вызвать Кобол подпрограмму, которая сделает расчёт и может быть тыцнет БД. Хотя они еще псевдо-табличные отчеты любят на нём создавать для последующей распечатки. Стоимость ошибки с двумя прокси и оторванность десятичных расчётов Кобол от того к чему мы привыкли (в Кобол десятичные расчёты именно десятичные, а не Double/BigDecimal) хуже чем переписывание или перенос ответственности всех DataMapping («все есть строка» в Кобол) на транслятор.
На одной из прошлых работе (в одном, гм, небольшом ритейле) была числодробилка с подобной «архитектурой»: в Excel на 10—15 листах готовились данные, VBA перелопачивал таблицы в подходящий формат и скармливал бинарнику, написанному на Фортране.
Потом господа-экономисты всё же взялись за ум и переписали всё это на Java/SQL Server. Но «фронтэнд» и «отладчик» на Excel работает, наверное, до сих пор.
Это если писать транслятор из Python в Cobol на регулярках
Вполне достаточно было бы им хотя бы прописать логику в BPMN для начала.
Думаю, завернули все это в виртуалку для соответсвующей архитектуры и засунули в клауд
"Знал бы, солому подстелил".
Странно, что никакая компания ранее не поняла выгоды по обслуживанию клиентов на Коболе.
cobolcowboys.comТогда почему «губернатор штата Нью-Джерси разыскивает программистов, знающих язык Cobol», а не фирму этих ковбоев? Стартап есть, но он не взлетел. Хотя теперь может и подлетит.
Часто на Хабре пишут, что в Штатах много вакансий для коболовцев — это говорит о том, что нормального интегратора то и нет. А это как раз их случай — работы немного, но она очень специфическая — типичный аутсорс (опоздал).
Знал одного человека который весьма неплохо подрабатывал, у них была группа которая брала на себя задачи по различным доработкам, в качестве постоянной прибавке к з.п. отнимающей немного времени вполне, при этом я так понял они все (заказчики и исполнители) хорошо друг друга знают, в т.ч. расценки на срочную работу.
Дык, клиент денег платить не хочет столько, чтобы было интересно запариваться
Счастливые, у них пособия есть.
Было бы смешно если бы не было так грустно. При нынешних ценах на Кобол программистов им может дешевле будет заказать какой нибудь конторке аутсорсеру интегратору новый софт чем свой допиливать.
Вот же — пожилые ковбои лабают на Коболе
habr.com/ru/post/403037
habr.com/ru/post/403037
В таких ситуациях призывы «переписать» звучать очень… как бы кого не обидеть… не очень серьезно. Переписать такую систему именно сейчас — это не в лужу пукнуть, это проект с тендером на несколько лет. Там же куча сторонних систем (конечно же, на том же Коболе, небось, или что похуже) и баз данных (на перфокартах! :) ).
Именно сейчас, когда горит, — разумеется, проще найти спеца и заплатить ему всё: от 10 тыщ зелени в час, хилтон, и полный бентли шлюх с багажником кокаина, чем затевать модернизацию системы (я даже уверен, что этой модернизации все сами сторонятся, потому что ждут, пока придёт следующий мэр/губер/председатель_совхоза и сделает уже он.
Именно сейчас, когда горит, — разумеется, проще найти спеца и заплатить ему всё: от 10 тыщ зелени в час, хилтон, и полный бентли шлюх с багажником кокаина, чем затевать модернизацию системы (я даже уверен, что этой модернизации все сами сторонятся, потому что ждут, пока придёт следующий мэр/губер/председатель_совхоза и сделает уже он.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Работа не постоянная с непонятной перспективой и с местами некоторыми требованиями к резидентству/гражданству, + закрытость, в принципе не имея выхода на заказчиков изучать смысла нет, а те кто имеет выход хорошо понимают ёмкость рынка и не заинтересованы в наплыве специалистов.
Да, для реальной работы надо понимать в бэкграунде очень много, начиная от форматов машинных команд S/360 (или на чём там он работает). JCL – уже где-то на уровне вишенок торта.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
В кок (идрис/хаскел/миранда/изабелль) вам помимо языка придется подучить систему типов и погрызть пару десятков научных работ (ну или их популярных интерпретаций) Люди которые «за вечер» это делают либо уже сделали это заранее и не за вечер а как минимум за полгода (имея бэк в не пару лет программирования) либо просто п*здѢ.
НЛО прилетело и опубликовало эту надпись здесь
Я как минимум могу оценить объем знаний необходимых для вхождения. Объем соответствующих работ такой что просто прочитать (как художественную литературу) за один вечер не получится. Даже не понимая прочитанного, просто прочитать.
НЛО прилетело и опубликовало эту надпись здесь
если так переживаете за карму — то я имею два вопроса:
1. Почему Вы не в курсе что с моей кармой я не могу голосовать?
2. Что Вы тут делаете?
>кое-что поменять в исходных файлах в зависимости от некоторых условий
и сваять с нуля (пусть и очень простенькое) — это разные вещи.
В хаскел для вывода в консоль Вам придется разобраться с монадами, вот прям сразу с порога. И это далеко не единственное в чем придется перестроить мышления переходя с императива. В кок Вам придется разобраться с Calculus of constructions не считая того что надо будет понимать как строятся доказательсва, индукция, вот это вот все.
>И это при том, что я не программист.
Вам не приходило в голову что люди, зарабатывающие ремеслом могут знать о нем немного больше Вас? И развивая мысль — Вам не приходило в голову что (возможно, чисто гипотетически, в одном инстансе Мультивселенной) Вы можете быть неправы?
1. Почему Вы не в курсе что с моей кармой я не могу голосовать?
2. Что Вы тут делаете?
>кое-что поменять в исходных файлах в зависимости от некоторых условий
и сваять с нуля (пусть и очень простенькое) — это разные вещи.
В хаскел для вывода в консоль Вам придется разобраться с монадами, вот прям сразу с порога. И это далеко не единственное в чем придется перестроить мышления переходя с императива. В кок Вам придется разобраться с Calculus of constructions не считая того что надо будет понимать как строятся доказательсва, индукция, вот это вот все.
>И это при том, что я не программист.
Вам не приходило в голову что люди, зарабатывающие ремеслом могут знать о нем немного больше Вас? И развивая мысль — Вам не приходило в голову что (возможно, чисто гипотетически, в одном инстансе Мультивселенной) Вы можете быть неправы?
НЛО прилетело и опубликовало эту надпись здесь
Но упомянутые языки — немножко другое. Даже с опытом функционального программирования в несколько лет плюс пяток прочитанных книг по матлогике и теории типов продуктивно писать на идрисе заняло некоторое время
В порядке интереса, что--то коммерческое на этих языках делается? А коробочное, т.е. предназначенное более чем для одного кастомера?
НЛО прилетело и опубликовало эту надпись здесь
кобол — это «вроде фортрана».
причем со своими особыми тараканами.
Ну и своим стилем напейсания (не, безусловно, можно выдавать и на фортране-4 код, хотя и использующий goto, но структурированный. Но это если ты писал на чем-то типа паскаля/си. если же ни на чем кроме фортрана-алгола-паскаля не писал — стиль будет соответствующий...)
причем со своими особыми тараканами.
Ну и своим стилем напейсания (не, безусловно, можно выдавать и на фортране-4 код, хотя и использующий goto, но структурированный. Но это если ты писал на чем-то типа паскаля/си. если же ни на чем кроме фортрана-алгола-паскаля не писал — стиль будет соответствующий...)
> Всем известно, что хороший программист способен выучить язык программирования за вечер.
Не всё так просто. Для этого язык идеологически должен быть похож на уже известные программисту языки. Для меня когда-то давно функциональные языки стали настоящим откровением, потому что весь предыдущий опыт знания (в разной степени) большого количества языков оказался бесполезен.
А тут ещё и мейнфреймы, которые в принципе не то же самое, что привычные нам компьютеры.
Не всё так просто. Для этого язык идеологически должен быть похож на уже известные программисту языки. Для меня когда-то давно функциональные языки стали настоящим откровением, потому что весь предыдущий опыт знания (в разной степени) большого количества языков оказался бесполезен.
А тут ещё и мейнфреймы, которые в принципе не то же самое, что привычные нам компьютеры.
Кстати, да. Последние года три для AS/400 пишу — архизанятная система. Чем глубже в нее влажу, те больше нравится. Но не суть.
Суть в том, что там огромное количество сущностей, абсолютно чуждых миру винтов и никсов. Аналогов которым нет ни там ни там. А сущности эти часто основополагающие — без их понимания (не знания, а именно понимания) можно на ровном месте наплодить изрядное количество багов, часть из которых далеко не всегда проявятся в тесте.
Суть в том, что там огромное количество сущностей, абсолютно чуждых миру винтов и никсов. Аналогов которым нет ни там ни там. А сущности эти часто основополагающие — без их понимания (не знания, а именно понимания) можно на ровном месте наплодить изрядное количество багов, часть из которых далеко не всегда проявятся в тесте.
Вчитайтесь внимательно — там требуется оптимизация работающей системы. А оптимизация требует достаточно глубокого знания языка и платформы на которой система работает (в рамках привычной мне AS/400 это к примеру понимание что быстрее и ресурсоэффективнее *DTAARA или *USRSPC, *DTAQ или *USRQ или как избежать лишнего переоткрытия файлов путем кеширования файловых дескрипторов — на RPG, на котором написан код, к примеру, это так просто не решить, надо писать на C + RECIO, а это уже знание двух языков + некоторое понимание внутренностией AS/400). А это уже не «хороший программист, освоивший язык за один день».
Что можно освоить — я знаю. Проходил через это. Но вот получить опыт, пригодный для решения задач по оптимизации нужно время. Это именно опыт работы с конкретной системой.
Что можно освоить — я знаю. Проходил через это. Но вот получить опыт, пригодный для решения задач по оптимизации нужно время. Это именно опыт работы с конкретной системой.
Не очень понятно, откуда такая паника и вообще термин «специалист по Коболу». Для любого внятного инженера не составляет особого труда вникнуть в еще один язык/технологию, потому что в современных реалиях это приходится делать если не ежемесячно, то ежегодно точно. А если брать реалии больших компаний (гуглы-фейсбуки-др.), так там просто из коробки уже используются с десяток языков, между которыми нужно постоянно переключаться. Сомневаюсь, что прийти и с нуля подправить какой-то код на Коболе сложнее, чем начать использовать какую-нибудь новую и существенную либу из экосистемы Node, переписать реакт-компоненты с классов на хуки, переехать с AWS на Google Cloud или задействовать в продакшене какую-нибудь новую СУБД.
Ну вот я немного застал COBOL в начале 90х на больших машинах System/370. Начнем с того, что ОС и окружение полностью ортогональны тому, к чему привыкли современные программисты.
Это просто другой мир, скачайте эмулятор VM/SP и попробуйте в нем написать и запустить программку типа Hello, World на REXX. Все другое — шелл, редактор, типы файлов, вообще все. Я в свое время умел загружать эту технику и даже что-то понимал в процедуре генерации; в том году скачал эмулятор и первый час просто вспоминал как этим вообще пользоваться.
COBOL, конечно, язык не сложный, хотя и некрасивый внешне, на мой взгляд. Но как во всякой технологии времён System/360 там решает не язык, а библиотеки. И базы данных, хорошо если просто DB2. И это все тоже мало похоже на современные подходы к построению этих компонент системы. Документация занимает красивые полки и некрасивые ящики и не вся есть на самой машине.
Мои коллеги, съехавшие после 1998 года коболировать в Канаду, рассказывали, что они по большей части никакой исторический код не правят, а варят очередной слой клея над предыдущими для стыковки этого легаси-мамонта с современным фронтендом.
Это довольно унылая и абсолютно не творческая работа, гарантирующая пожизненную занятость™ в отсутствие гонки технологий. Такой вид почетной пенсии, в своем роде.
Я вот каждый год обычно на пару недель полностью погружаюсь в ассемблер 6502, что использовался в NES/Dendy, и который гораздо старше меня самого. Получаю от этого какое-то особое удовольствие. И я не один такой. Кто-то даже умудряется как-то на этом зарабатывать. Может, есть и такие же любители COBOL, которые только и мечтают найти такую работу, да не знают где? =)
получать удовольствие от 6502? ух ты ж…
не ожидал, что он может удовольствие доставить…
не ожидал, что он может удовольствие доставить…
Это все знания, угасающие без практики, к сожалению. Я вот был мастером REXX, варил интерактивные экранные формы и был просто монстром в ассемблере 360. Из этого всего я сейчас вспомню разве что бессмертное:
BALR 15,0
USING *,15
Испытываю теплые чувства к REXX и, отчасти, к PL/I; допускаю, что где-то существуют люди, которым нравится COBOL, но тут, скорее, не они не знают, где работу найти, а работа не знает, где таких людей искать.
Как я понимаю, мечта таких лавок это человек с активным опытом коболирования на мейнфреймах, который умеет в J2EE в варианте от IBM. Энтерпрайз с кровавостью на уровне Nightmare, одним словом, XML с CDATA в кодировке EBCDIC, и прочие игрушки для взрослых..
S/360-370 это ведь то, из чего вырос современный IBM z?
Сейчас имею удовольствие работать с их параллельной веткой — линейкой S/36-38 AS/400, ныне IBM i. Тоже ни на что не похожая платформа. Со множеством особенностей в которые надо вникнуть чтобы писать надежно и эфективно.
Для любителей «освоить за вечер» простенький тест — зарегистрироваться на PUB400 — получите 300мб дискового пространства и две личных библиотеки. TN5250 можно бесплатно скачать с сайта IBM (Access i Client Solution — целый пакет). Установив и настроив его (это совсем просто, фактически, когда есть логин и пароль к серверу там просто надо создать конфигурацию введя адрес сервера, остальное оно само сделает).
После этого попробуйте написать, собрать и запустить под отладчиком Hello Word на любом из доступных в ILE языков — COBOL, RPG, CL, C/C++.
Все средства от редактора до компилятора и отладчика там есть. Прям в составе ОС.
Дальше можно попробовать создать простенькую табличку с хотя бы одним индексом и простенький интерфейс для добавление, редактирования записей и вывода их на печать.
Гарантирую много интересных открытий на этом пути :-)
Сейчас имею удовольствие работать с их параллельной веткой — линейкой S/36-38 AS/400, ныне IBM i. Тоже ни на что не похожая платформа. Со множеством особенностей в которые надо вникнуть чтобы писать надежно и эфективно.
Для любителей «освоить за вечер» простенький тест — зарегистрироваться на PUB400 — получите 300мб дискового пространства и две личных библиотеки. TN5250 можно бесплатно скачать с сайта IBM (Access i Client Solution — целый пакет). Установив и настроив его (это совсем просто, фактически, когда есть логин и пароль к серверу там просто надо создать конфигурацию введя адрес сервера, остальное оно само сделает).
После этого попробуйте написать, собрать и запустить под отладчиком Hello Word на любом из доступных в ILE языков — COBOL, RPG, CL, C/C++.
Все средства от редактора до компилятора и отладчика там есть. Прям в составе ОС.
Дальше можно попробовать создать простенькую табличку с хотя бы одним индексом и простенький интерфейс для добавление, редактирования записей и вывода их на печать.
Гарантирую много интересных открытий на этом пути :-)
Все же какой-нибудь питон — это комьюнити, библиотеки, иде под него заточенные, фреймворки, найденные и задокументированные нюансы работы (включая производительность), масса документации, примеров использования и так далее.
Упрощенно говоря — если человек полиглот, то не факт что увидев неизвестную науки клинопись он сможет на ней заговорить «без особого труда вникнув»©
Упрощенно говоря — если человек полиглот, то не факт что увидев неизвестную науки клинопись он сможет на ней заговорить «без особого труда вникнув»©
Это проблема современных программистов. Они изучают синтаксис, а не семантику. Если бы изучая программирование начинали со второго, то освоить синтаксис за пару дней нового для них языка не составило бы трудностей.
Ваши бы слова да археологам в уши.
Ну чтобы любую клинопись расшифровывать сходу
Ну чтобы любую клинопись расшифровывать сходу
Не знаю как клинопись, а мертвые языки начинают изучать с похожего. Время же изучение дольше из-за куда большего разнообразия чем всего 6 семантик.
Я вот завидую всем хорошим программистам под этим постом. Постоянно работаю с Джавой уже лет 5 как минимум, учу спецификации, читаю книги и до сиз пор не могу сказать, что знаю всё, что там есть. Начиная от легаси со всех этих Java EE стандартов, конфигураций различных серверов, и до последних фич новых версий Джавы. При этом то аспектно-ориентированное программирование вылезет, то какие-то хаки с рефлектом, то фреймворки, которые уже никто не поддерживает, но под которые надо продолжать доделывать бизнес логику… И это живой язык, с отличной поддержкой IDE от тех же JetBrains, множества учебных материалов доступных онлайн в любой момент, и живым сообществом, где всегда можно найти ментора, котолрый мог бы тебе помочь.
А тут люди утверждают, что способны Кобол за вечер освоить. Преклоняюсь перед такими титанам, которые со всей уверенностью способны давать такие утверждения. Совершенно не представляю, что бы это могло бы быть пустым бахвальством, за которым ничего не стоит.
А тут люди утверждают, что способны Кобол за вечер освоить. Преклоняюсь перед такими титанам, которые со всей уверенностью способны давать такие утверждения. Совершенно не представляю, что бы это могло бы быть пустым бахвальством, за которым ничего не стоит.
НЛО прилетело и опубликовало эту надпись здесь
Написать на листочке простенькую программу на коболе, постоянно заглядывая в учебник несложно.
А вот ту же программу собрать и запустить на, к примеру, сервере AS/400 общаясь с ним через эмулятор терминала IBM5250 — это уже посложнее будет. Еще сложнее будет понять что делают эти несколько тысяч строк на коболе и почему они работают не так быстро как хочется.
А вот ту же программу собрать и запустить на, к примеру, сервере AS/400 общаясь с ним через эмулятор терминала IBM5250 — это уже посложнее будет. Еще сложнее будет понять что делают эти несколько тысяч строк на коболе и почему они работают не так быстро как хочется.
НЛО прилетело и опубликовало эту надпись здесь
Фух, я уж было подумал, что вирус всех сотрудников CobolCowboys того… ну, вы понимаете…
Cobol
http://rosettacode.org/wiki/Category:COBOL
Кобол
QuickSort Cobol
http://rosettacode.org/wiki/Sorting_algorithms/Quicksort#COBOL
BubbleSort Cobol
http://rosettacode.org/wiki/Sorting_algorithms/Bubble_sort#COBOL
http://rosettacode.org/wiki/Category:COBOL
Кобол
QuickSort Cobol
http://rosettacode.org/wiki/Sorting_algorithms/Quicksort#COBOL
BubbleSort Cobol
http://rosettacode.org/wiki/Sorting_algorithms/Bubble_sort#COBOL
Имею дело с древнятиной, восходящей к середине 70х — системой обсчёта экспериментальных данных с детекторов флуоресценции и поглощения, в обозримом будущем не подлежащей замене, ибо привязана к актуальному оборудованию и относительно современной информационной системе более высокого уровня. Исходно работало под CP/M, позже было перенесено на MS-DOS.
Благодаря встроенному языку, позволяющему описать любые экспериментальные протоколы и мало того, взаимодействие с оборудованием, система обладает потрясающей гибкостью, но проблема с том, что специалистов, владеющих низкоуровневыми настройками системы, можно сосчитать по пальцам одной руки.
Поражает консервативность компании-производителя данного оборудования PerkinElmer — до сих пор поддерживают древний DOS-овский софт и ARCNET в качестве интерфейса, при этом надёжность данного легаси превосходная.
Благодаря встроенному языку, позволяющему описать любые экспериментальные протоколы и мало того, взаимодействие с оборудованием, система обладает потрясающей гибкостью, но проблема с том, что специалистов, владеющих низкоуровневыми настройками системы, можно сосчитать по пальцам одной руки.
Поражает консервативность компании-производителя данного оборудования PerkinElmer — до сих пор поддерживают древний DOS-овский софт и ARCNET в качестве интерфейса, при этом надёжность данного легаси превосходная.
Есть немаловажный момент в том, что при переписывании с Кобола (да с чего угодно) на любой другой ЯП нужно не просто код перевести строчка за строчкой (или процедура за процедурой), но и сэмулировать вообще всё, от багов (на которые ориентируются другие куски кода, сами пользователи), и до процедур обмена данными со всеми другими частями всего-всего.
Не говоря, что пользователи какого-о монстра привыкли, скажем, уже лет 20 набивать входные данные на перфокарты. У них процедура ввода привычна, точно работает, для неё наняты люди, и все выстроено. Ок, меняем перфокарты на клавиатуру и красивые экранные формы — и что, старые сотрудники тупо будут путаться, польза делу будет отрицательна, годами система будет нестабильно работать… Оно нужно?
Не говоря, что пользователи какого-о монстра привыкли, скажем, уже лет 20 набивать входные данные на перфокарты. У них процедура ввода привычна, точно работает, для неё наняты люди, и все выстроено. Ок, меняем перфокарты на клавиатуру и красивые экранные формы — и что, старые сотрудники тупо будут путаться, польза делу будет отрицательна, годами система будет нестабильно работать… Оно нужно?
Посмотрел лист Кобола и что-то мне это очень напомнило (1С):
Program-ID. Fibonacci-Sequence.
Data Division.
Working-Storage Section.
01 FIBONACCI-PROCESSING.
05 FIBONACCI-NUMBER PIC 9(36) VALUE 0.
05 FIB-ONE PIC 9(36) VALUE 0.
05 FIB-TWO PIC 9(36) VALUE 1.
01 DESIRED-COUNT PIC 9(4).
01 FORMATTING.
05 INTERM-RESULT PIC Z(35)9.
05 FORMATTED-RESULT PIC X(36).
05 FORMATTED-SPACE PIC x(35).
Procedure Division.
000-START-PROGRAM.
Display "What place of the Fibonacci Sequence would you like (<173)? " with no advancing.
Accept DESIRED-COUNT.
If DESIRED-COUNT is less than 1
Stop run.
If DESIRED-COUNT is less than 2
Move FIBONACCI-NUMBER to INTERM-RESULT
Move INTERM-RESULT to FORMATTED-RESULT
Unstring FORMATTED-RESULT delimited by all spaces into FORMATTED-SPACE,FORMATTED-RESULT
Display FORMATTED-RESULT
Stop run.
Subtract 1 from DESIRED-COUNT.
Move FIBONACCI-NUMBER to INTERM-RESULT.
Move INTERM-RESULT to FORMATTED-RESULT.
Unstring FORMATTED-RESULT delimited by all spaces into FORMATTED-SPACE,FORMATTED-RESULT.
Display FORMATTED-RESULT.
Perform 100-COMPUTE-FIBONACCI until DESIRED-COUNT = zero.
Stop run.
100-COMPUTE-FIBONACCI.
Compute FIBONACCI-NUMBER = FIB-ONE + FIB-TWO.
Move FIB-TWO to FIB-ONE.
Move FIBONACCI-NUMBER to FIB-TWO.
Subtract 1 from DESIRED-COUNT.
Move FIBONACCI-NUMBER to INTERM-RESULT.
Move INTERM-RESULT to FORMATTED-RESULT.
Unstring FORMATTED-RESULT delimited by all spaces into FORMATTED-SPACE,FORMATTED-RESULT.
Display FORMATTED-RESULT
Ну робяты, в чем проблема? Берёте зарплату программиста в гугле, умножаете ее на два или на три — и вот у вас сломанные от кандидатов дверные петли.
На самом деле, история с мэйнфреймами в гос учреждениях, это не показатель какой-то особой экономической эффективности или надежности мэнфреймов. По моей практике, это скорее показатель консервативности и неспособности к изменениям. Если рынок буквально заставляет меняться и улучшаться частный бизнес, то гос бюрократию ничто не жмет в этом плане. Вот потому и продолжают греть атмосферу эти мастодонты. Там где есть конкуренция — с мэйнфреймов съезжают все. Не так давно казалось, что GDS уж точно останутся на мэйнфреймах надолго. А сегодня они практически все от них избавились.
К чему я это говорю? Тут призывают молодежь учить кобол и т.д. Не ведитесь. Такие специалисты требуются только в абсолютно замшелых конторах с людьми пенсионного возраста, которым нужна молодежь чтобы подносить утку. Провести молодые годы в доме престарелых — не лучший выбор.
К чему я это говорю? Тут призывают молодежь учить кобол и т.д. Не ведитесь. Такие специалисты требуются только в абсолютно замшелых конторах с людьми пенсионного возраста, которым нужна молодежь чтобы подносить утку. Провести молодые годы в доме престарелых — не лучший выбор.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Коронавирусный кризис резко увеличил спрос на программистов, знающих Cobol