Comments 88
"Не хотите ли поесть говна, по старой памяти? Но теперь за большие деньги!"
BTW, SQL основан не на реляционной алгебре, а на реляционном исчислении.
Благодарю вас, поправил.
как то за не особо большие деньги. Я вот сейчас вбил слово cobol на indeed.com - максимум, что я увидел (смотрел просто глазами, так что как статистику это не стоит рассматривать) - 220к в год, в среднем - порядка 120 что для США - ну явно не много. Есть несколько друзей там - сеньоры на современных языках - и у них зп значительно больше.
И вот меня все удивляло это: ну вряд ли кобол прям такой сложный, вряд ли не нашлось ни одного java сеньора, который за х2 к зарплате не осилил бы кобол. Но похоже, что они, конечно, ищут, умоляют, "но вы там держитесь".
Как бы у нас с Cobol'ом прикол в том что он востребован, а людей нет. А те кто есть, в основной своей массе уходят на самозанятость и поэтому в статистике зарплат не особо-то и видны. Но при этом зарабатывают они спокойно в полтора-два раз больше тех кто пишет на "популярных" языках.
Другое дело что вся эта возня с легаси(то есть не только Cobol, но и ряд других языков) дело очень мутное и нервное. И в принципе мало кто хочет с таким связываться. Даже с учётом больших зарплат.
А где все эти вакансии? И в полтора-два раза больше - это сколько?
Просто, я не в первый раз интересуюсь.
Пару лет назад я думал как раз поступить, вроде "Ну, какая разница, на чем легаси из пустого в порожнее переливать". Пошел смотреть вакансии (в том числе, чтобы выписать список требований, технологий - что учить) - и как-то не впечатлило.
А где все эти вакансии?
В смысле "где"? Местами на биржах вакансий. Хотя по большей части такие вещи идут через всяких HR-посредников или "личные знакомства".
И в полтора-два раза больше — это сколько?
Ну я знаю двух человек, которые таким занимаются, и у них получается примерно 100-140к€ в год. По их словам это норма для такого дела. Обычно самозанятый сениор у нас зарабатывает 75-90к€ в год. Не самозанятый 65-75к€. Но у самозанятых там ещё некоторые ньюнсы с дополнительными расходами.
Пару лет назад я думал как раз поступить, вроде "Ну, какая разница, на чем легаси из пустого в порожнее переливать". Пошел смотреть вакансии (в том числе, чтобы выписать список требований, технологий — что учить) — и как-то не впечатлило.
Ну у нас в принципе относительно сложно найти работу для самозанятого если смотреть вакансии на всяких онлайн-биржах. Не так чтобы такого вообще не было. Есть конечно.
Но много где самозанятых берут "по знакомству". То есть либо тебя самого должны откуда-то знать, либо кто-то тебя порекомендовать должен.
Однозначно глупость. То есть я не знаю почему, но какой-нибудь консалтинг за бешенные деньги берут куча фирм. А условно говоря взять того же разработчика напрямую как самозанятого многие не хотят.
То есть я в своё время так из консалтинга "прыгнул" на самозанятость: после того как сделал несколько проектов для одной фирмы и они мне только потом предложили работать с ними напрямую. При этом с консалтингом они продолжали работать и дальше и ни в какую не хотели брать самозанятых "с улицы".
Я думаю, что действительно основной "набор" идёт именно через сарафанное радио.
В моей прошлой конторе (США) на момент моего ухода год назад была одна из основных систем, введенная в эксплуатацию в 1987 году. Я несколько лет проработал на проекте миграции на новую и крутую систему, не переставая удивляться тому, насколько продуманно и грамотно была написана система существующая (мы постоянно упирались в то, что стандартный функционал старой системы либо вообще будет отсутствовать в новой, либо будет реализован через многомерные костыли, что нехило доставляло представителям бизнес-подразделений, но это ладно, я отвлёкся...)
Когда в какой-то момент в рамках миграции понадобилось разобрать авгиевы конюшни старой системы, нам сосватали команду из 3 или 4 седовласых и бородатых дядечек, которые ныне основали свою консалтинговую компанию и занимаются как раз спасением утопающих, которые в океане не той системы плавать не умеют. Они пробыли с нами недели 2 или 3, написали то, о чем их попросили, и распрощались. Размер их гонорара за этот микропроект после их ухода старались лишний раз не вспоминать - это была ОЧЕНЬ солидная цифра, сильно превышающая гонорар многих management consulting проектов похожей длительности. И, да, откатов/коррупции там, скорее всего, не было - они реально в вопросе разбирались, а задачу нужно было делать. Но это очень узкая ниша.
Не совсем понял, при чем здесь самозанятость. Это для работы на несколько заказчиков, или чтобы налоги не так кусались?
но если честно, это не выглядит как "где же вы, только найдитесь". Про зарплату без указания страны говорить не корректно. Очень уж от страны зависит.
Не совсем понял, при чем здесь самозанятость. Это для работы на несколько заказчиков, или чтобы налоги не так кусались?
Немного того и немного другого.
Просто для вещей вроде копания в легаси коде у многих фирм нет "объёма работ" чтобы брать человека на постоянку. Поэтому им проще брать людей под конкретные задачи. Что как бы в свою очередь скорее подходит для консалтинга-галер или самозанятых.
С другой стороны и в плане налогов самозанятость у нас для айтишника вполне себе выгодная штука. Но обычно фирмы её не особо любят.
Про зарплату без указания страны говорить не корректно. Очень уж от страны зависит.
Ну у меня страна в профиле указана. Но речь про Германию. Или точнее про юго-запад Германии.
кстати, ради интереса, а при работе через самозанятость что с пенсией? Платятся ли отчисления и будет ли она примерно того же размера(в том же возрасте? может другое какое отличие?), что и при обычном трудовом контракте? Что с другими соц. гарантиями? Пособие по безработице, насколько я помню, через страховку работает - как с ним будут обстоять
дела?
Всё добровольно. Но есть возможность платить в "обычный" пенсионный фонд, взять обычную медстраховку, платить страховку по безработице, и так далее и тому подобное.
С другой стороны у нас ту же пенсию на мой взгляд выгоднее делать через частные пенсионные фонды.
да везде это выгоднее. А может даже лучше через какие-нибудь инвестпакеты.
Мне скорее интересно сравнение с работой по обычному контракту, на сколько выгоднее получается и какие подводные камни. Что не включено в эту стоимость (может, отпуска?).
Спросил товарища из Польши (понимаю, что не то же самое) - говорит, сейчас пытается разобраться, но пока ничего не понятно.
Кстати, налоговая не гоняет за это? Я слышал, у нас могут квалифицировать, как попытку уйти от налогов и доначислить.
Мне скорее интересно сравнение с работой по обычному контракту, на сколько выгоднее получается и какие подводные камни.
Ну я бы сказал что получается где-то на 30-40% дешевле.
и какие подводные камни.
Ну например если взять приватную медицинскую страховку, то она выгоднее. Но на обычную потом практически не вернуться. И надо будет платить частную даже если уже не самозанятый.
Кстати, налоговая не гоняет за это? Я слышал, у нас могут квалифицировать, как попытку уйти от налогов и доначислить.
За что? Ты точно так же сдаёшь налоговую декларацию и указываешь доходы-расходы. И если налоговой что-то не нравится, то она тебе сообщит. Но у меня ни разу никаких проблем не было.
примерно 100-140к€ в год
Это ведь до налогов? Чо-то мало, столько сеньором можно и в Мск зарабатывать. И при этом не надо "есть говно" (с).
Хорошие однако зарплаты в Москве, неужели и вправду больше 1 млн RUB в месяц?!
В Европе > 100K EUR это уже высший класс developers или management.
Если речь про Россию, то такие вакансии исчезают, - многие переходят на софт написанный на более современных и "популярных" языках программирования.
>Другое дело что вся эта возня с легаси(то есть не только Cobol, но и ряд других языков) дело очень мутное и нервное.
ну это они только пишут что надо Cobol, а на самом деле 99% в чужом гуано придется разбираться к тому же плохо документированном, как обычно imho
В России лет 10 назад может и больше зарабатывали люди знающие Cobol, но это уже давно не так, есть АБС написанные на более современных "популярных" языках, они проще в освоении и удобнее в использовании. Наверное России даже повезло с тем, что финтех у нас помоложе чем в США, вот там реально без Cobol не обойтись и смогут ли они с него вообще слезть не понятно.
I believe you're trying to compare senior's salary for West coast with Cobol programmer's in East coast. Most Cobol jobs are in East coast.
Нет, я сравниваю зарплаты где угодно в США. Точнее, я сравниваю с сайтом indeed.com. Где он их выдает - там и сравниваю. А если про друзей - один из них живет вообще не на побережье, в Денвере.
Кстати, а почему есть разница, на каком побережье?
Кстати, а почему есть разница, на каком побережье?
Сравнить зарплаты по США "где угодно" это как сравнить зарплаты по России, например, и Москвы.. На Восточном побережье Washington DC, соответственно в примыкающих штатах, как то VA и MD много работы на федеральное правительство. Там зарплаты не настолько большие, но работа стабильная (читайте, пожизненная) и даже контракты длительностью 5-6 лет. У меня знакомый уже 12 лет работает на контракте и хорошо себя чувствует.
Западное побережье это, как правило, Калифорния/Долина. Там люди зарабатывают совершенно другие деньги, но там и стоимость жизни куда выше.
Мейнфреймы стоят в основном, в федеральном правительстве, правительстве штатов и, иногда, в некоторых крупных банках. Другое дело, что банки давно мигрировали свои мейнфреймы в облака IBM, а вот Агентства расчехляются медленно. Если на чек-поинте вашего агентствавы видите старичков, то это IBM пришел разрулить серьезные проблемы связанные с мейнфреймами.
Как-то так.
учитывая, что я смотрел на максимальные зарплаты в коболе - можно сказать, что я сравнивал их "в лучшем месте в США" (да, формулировка так себе).
А еще на восточном побережье есть Нью Йорк. И там зарплаты вполне на уровне.
А насчет старичков вы не правы. Работал я в прошлом в интеграторах, занимался в основном СХДшками для всех этих мейнфреймов (symmetrix), ну и немного IBM-овскими серваками (pSeries - знаю, что это не мейнфреймы, хотя и выглядят солидно). И возраст большей части коллег и инженеров вендора был лет 30-35.
Шо, опять???
http://rosettacode.org/wiki/Category:COBOL
P.S. Как понимаю, что для России это не так актуальная тема Cobol «страданий»?
Да, COBOL нас почти не задел. Зато в России есть Delphi. И RPG во многих крупных банках. И 1С.
Сильно же вы не любите 1С.
Ну с 1С то проблем нет, он сам рефакторится вместе с версиями, ЯП в 1С6.0 был совсем не такой как в 1С7.0 и тд. Поколения программистов уходят реже чем версии 1С
Кстати, видел как в одной крупной штатовской конторе попался старый проект на Dephi. Никто не знал, что это такое и что с этим делать.
Про Pascal знали немного по-наслышке, а вот про Delphi ничего.
Ради прикола попытался узнать историю проекта, но никакой информации не нарыл. Видимо, какой-то свежий русский программист решил так "пошутить".
А ничего, что сам Delphi как раз в Штатах и разрабатывается. Причем каждый год новые версии выходят, вполне современные. Вот недавно компиляцию под процессор Apple M1 для MacOS запилили.
Как видно выше, место разработки мало влияет на популярность. А если взять определённую область (например, финансы), так там ещё другие критерие накладываются, которые не будут способствовать популяризации.
Есть много других языков и проектов, которые начали свой путь совсем не в штатах, но сегодня в штатах они популярны или минимально о них знают во многих индустриях.
Согласен. Но что супер-популярно сейчас не факт что будет супер-популярно через 5-10 лет. А такие инструменты как Delphi живут десятками лет. Хотя конечно в этом скорее заслуга Windows — он жив и Delphi жив. Помрет Windows, скорее всего помрет и Delphi. Понятно, что сейчас под винду больше на C# пишут, но и на Delphi остаются проекты, в т.ч. крупные.
По поводу популярности и 10 лет, то это 100% именно так, совершенно верно.
Delphi живой, но не везде. Потому я и заметил, что в некоторых сферах он не только не живой, но о нём даже никто ничего не знает. В тех же финансах (а это ведь достаточно древняя сфера) его нет, там прочно сидят другие инструменты, которых не мало.
По поводу крупных проектов: что бы далеко не ходить, то крупные проекты есть и на COBOL'е, но только это не идёт ему в плюс сегодня. Начинать новый большой проект на COBOL'е сегодня -- мягко говоря, будет не очень разумным решением.
P.S.: кстати, тот проект на Delphi я предложил взять только для того, что бы портировать его на что-то другое. Народ даже согласился, но потом его просто свернули, так как нашли более удобные альтернативы.
Понятно почему банки готовы платить `компенсация х2` * `работники х2` -- "лишь бы всё не упало"
Но совсем непонятнО: почему не перенесут всё то же самое на человеческий стек (ну хотя бы в "кобол-нитерпретатор") в перспективе пары лет?
Потому что там реально тысячи человеко-лет кода, причём махровейшей бизнес-логики.
Перенести её куда-либо один-к-одному, написав волшебный конвертер - вы получите тот же Кобол, только написанный на Яве, то есть потеряете все преимущества, сохранив все недостатки.
Переписать с нуля? Аналитики, которые могут объяснить исходную задачу, уже на пенсии или в могиле, нужно воспитывать новых и учить их Коболу. Нужно нанимать целую команду, которая будет переписывать код несколько лет, потом тестировать его, потом мигрировать на него, а что в итоге? Тот же функционал, что и пять лет назад.
На коболе остались в основном глубоко бэк-офисные процессы, которые меняются довольно медленно. Пока лучше платить двум седовласым гуру Кобола и одному падавану двойную ставку каждый год, чем нанимать двадцать человек на переписывание.
Но в итоге это приведёт к тому, что эти седовласые гуру умрут, а для новых поколений разработчиков кобол станет ещё менее предпочтительным вариантом, потому что прочие ЯПы сделают ещё один шажок вперёд.
Вся эта история имхо об опасности подхода "работает - не трогай" и том, что рефакторинг должен быть постоянным, а система должна постоянно освежаться и модернизироватся.
Потому что иначе очень быстро система становится волшебной, а любые манипуляции с ней - опасными и сверхдорогими.
Вся эта история имхо об опасности подхода "работает — не трогай"
Это история про то что черные ящики надо научиться документировать. Хорошо документировать. Чтобы вот буквально рядом с ящиком стоял (толстенный) учебник, который можно прочитать и понять, где там что тыкать и крутить надо в случае чего.
А не "лучшая документация — это код"
Это, жадность IBM и специфические исторические знания о системной архитектуре конкретных компаний. Сам язык прост как валенок. Впрочем, такой же универсальный.
Так документация часто даже есть. Только это руководство пользователя, а не для разработчика. Как раз то, что надо было для бизнеса того времени и не более. Ведь писать дополнительную документацию по коду -- это дополнительные деньги, которые налогоплательщики давать не хотят.
>Но в итоге это приведёт к тому, что эти седовласые гуру умрут, а для новых поколений разработчиков кобол станет ещё менее предпочтительным вариантом
>Это история про то что черные ящики надо научиться документировать. Хорошо документировать.
большинство "седовласых гуру" уже того, типа сверху с интересом наблюдает за происходящим, про то "как должно быть" хорошо рассуждать, когда время для рассуждений имеется, что в общем в бизнесе редкость, ну и реакция современной индустрии как всегда прямолинейная - нужен программист-ассенизатор (cobol specialist) весьма востребованная категория, как кстати и обычные janitor, что будет в будущем - на это просто воображения не хватает
ps
проблема касается не только cobol'a конечно
COBOL это "клей" с синтаксисом, близком к английскому языку (чтобы даже бизнес аналитик мог понять). Сходить в базу данных или файлы, отпроцессить ответ по шаблону и выплюнуть наружу XML (или ещё какой формат) - в коболе это эссе в несколько человекочитаемых строчек. На Java за это время вы успеваете только открыть IDE и быть может нагенерить кучу невнятного boilerplate кода (с ООП, классами и тому подобной, не относящиеся к делу, ерундой). Насколько я понимаю, затее переписать на Java там столько же лет, сколько самой java. Но чисто с технологической точки зрения это не даёт ни каких плюшек.
Миграция с мейнфреймов существует как бизнес лет 40. Все есть, и даже в облаках. Язык не причём.
Java
Уже есть такой, Lisp (с диалектами). Постарше COBOL будет(на один год), и живее всех живых при этом. Да, не в первой десятке по популярности, но и не исчезающее количество актуальных проектов на нем, даже если не брать всякие Clojure, Scheme и прочие Racket.
Согласно википедии фортран появился раньше. И до сих пор используется, на нем даже относительно свежие программы пишут
Ответ получим лет через 10-15-20 :)
Мне кажется у Rust'а есть перспективы, раз уж его в ядро линукса уже готовы(?) принимать
Вообще COBOL вещь интересная и не однозначная. АБС написанные на данном языке, с одной стороны, трудны в освоении, могут пугать отсутствием привычного пользователям GUI из-за чего может возникнуть множество серьёзных ошибок. При этом, с другой стороны, они обладают гибкостью и надёжностью, а опытный пользователь способен работать с ними на очень быстро и эффективно.
В нашем ВЦ за терминалом сидит группа бухгалтеров.
Их учат Коболу.
Я сижу в стороне и до меня долетают отдельные фразы.
Казалось, они проходят мимо моего сознания. Но вот начал читать эту статью и сразу уловил что-то знакомое, забытое, из давнего-давнего прошлого :)
Теперь понятно, откуда взялось 80 символов на строку в textmode
у разработчика-одиночки нет денег, чтобы взять в аренду мейнфрейм
ИМХО сейчас это не проблема — в сетке можно найти много эмуляторов на ПК. "IBM 370" покажет бешенную скорость.
Какой там популярный?! Одно старое дряхлое ведомство, столкнувшись с "внезапным" из-за пандемии резким ростом обращений за пособием по безработице, не может обработать 3,6 млн обращений в месяц, что любой современный сервер делает за минуту. И вместо того, чтобы обновить парк и приобрести любой современный CRM из тысяч вариантов на рынке, они только и делают что распространяют сказки про мёртвый язык программирования в тшетной надежде, что найдётся некромант, который магическим образом в несколько раз ускорит им обработку таблиц. Интернет помнит всё, и особенно новостные заголовки!
Мы сталкивались с той же самой проблемой. Даже отдельную статью писали для этого.
Другое дело, что предметный бизнес-ориентированный язык должен быть простым для освоения. Одна из его задач должна быть в том, чтобы можно было легко ему научить человека из бизнеса.
То есть проблема должна решаться относительно легко (именно так мы ее и решали) :
Ищете человека из бизнеса с техническо-аналитическим складом ума.
Даете ему больше денег (выше рынка). Если не находите, то даете еще больше. Теорема : рано или поздно найдется.
Быстро обучаете его этому высокоуровневому языку (если человек способный, а язык нормальный, то на это уйдет максимум месяц).
PROFIT !!!
Конечно, правильный вариант - это переписать это все нафиг на нормальные современные технологии. Но если уж заранее не сделали, то тут, как говорится, "desperate times call for desperate measures".
Другое дело, что предметный бизнес-ориентированный язык должен быть простым для освоения. Одна из его задач должна быть в том, чтобы можно было легко ему научить человека из бизнеса.
Давайте горшки будет делать гончар, а сапоги сапожник. Программы писать должны IT специалисты (весь стэк), а люди из бизнеса - должны заниматься бизнесом. Если обычного и специализированного естественных языков для общения и согласования не хватает - есть тот же ГОСТ, UML и проч.
Действительно работающий COBOL не всякий программист прочтёт, не то что бизнес аналитик. Тут та же история что с SQL, когда хотели сделать "язык для бхгалтеров". В простых, учебных примерах - бухгалтера вполне себе понимали. Но запрос, который реально работает на практике сейчас и программист предпочитает не смотреть, а абстрагироваться через ORM
Программы писать должны IT специалисты (весь стэк), а люди из бизнеса - должны заниматься бизнесом
А люди, которые пишут макросы в Excel - это кто ? А 1Совцы ? Чем программист принципиально отличается от не программиста ? Тем, что он может алгоритмы/архитектуры описывать на плоском языке, а не в виде схем/диаграмм ?
Давайте горшки будет делать гончар, а сапоги сапожник.
По такой логике, можно начать гнобить и Full Stack Developer. Типа "пусть фронтендом занимаются фронтендеры, бэкендом - бэкендоры, а базой - разработчики БД". Да, есть случаи, когда это имеет смысл. Но есть случаи, когда и не имеет.
Действительно работающий COBOL не всякий программист прочтёт, не то что бизнес аналитик
Если бизнес-аналитика обучить языку, на котором читать, то он может читать и получше программиста, если там декларативная, а не императивная логика.
Чем программист принципиально отличается от не программиста ? Тем, что он может алгоритмы/архитектуры описывать на плоском языке, а не в виде схем/диаграмм ?
Да, ровно этим. И да, программирование - отдельная проффесия.
По такой логике, можно начать гнобить и Full Stack Developer. Типа "пусть фронтендом занимаются фронтендеры, бэкендом - бэкендоры, а базой - разработчики БД".
Вполне обоснованная претензия, между прочим. В более или менее сложных проектах фронт и бек неизбежно разбегаются ибо везде свои тонкости.
Если бизнес-аналитика обучить языку, на котором читать, то он может читать и получше программиста, если там декларативная, а не императивная логика.
Пусть читает, кто ж против. Только поддерживать всё это нужен всё равно программист. Которого искать всё труднее становится. Такие дела.
В общем, ораторы выше поддерживаю полностью.
Да, ровно этим. И да, программирование - отдельная проффесия.
То есть достаточно для того-же Java кода построить возможность задавать его визуально в виде стрелочек и формочек, и тогда это перестанет быть программированием, и будет другой профессией ? А оно станет по такой логике гораздо проще ?
Вполне обоснованная претензия, между прочим. В более или менее сложных проектах фронт и бек неизбежно разбегаются ибо везде свои тонкости.
Да, во многих проектах разделение оправдано. Тем не менее профессия Full Stack Developer'ов существует и достаточно востребована. Значит и в ней есть смысл.
Пусть читает, кто ж против. Только поддерживать всё это нужен всё равно программист. Которого искать всё труднее становится. Такие дела.
Зачем нужен программист ? Например, у нас прекрасно разрабатывают сложные системы люди, которые никогда не были программистами. При этом ни к каким программистам не обращаются. Что мы делаем не так ?
То есть достаточно для того-же Java кода построить возможность задавать его визуально в виде стрелочек и формочек, и тогда это перестанет быть программированием, и будет другой профессией ? А оно станет по такой логике гораздо проще ?
Может я как-то плохо выразился. Не надо воспринимать технических специалистов, как программистов графиками. У программистов склад ума отличается. И идея сделать "понятный менеджеру" язык программирования обречена на провал. Пример - SQL.
Тем не менее профессия Full Stack Developer'ов существует и достаточно востребована.
Я имел в виду то, что идея гнать на фулл стек имеет под собой основания и не является чем-то немыслимым. Естественно, всё зависит от конкретной ситуации.
Зачем нужен программист ? ... Что мы делаем не так ?
Ну, это была шпилька на тему основной идеи статьи. Если Кобол такой понятный техническим специалистам, то почему бы им самим не сделать всё что надо? Зачем для это искать программиста да ещё и за 100500 денег?
Что касается Ваших знакомых/коллег, то скорее всего у них изначально есть способности к программированию. Либо сложность системы несколько преувеличена. Без данных сложно сказать что-то определённое.
Не надо воспринимать технических специалистов, как программистов графиками. У программистов склад ума отличается
А что если есть человек, у которого склад ума такой же, как у программиста, но он сейчас работает не программистом, а менеджером/учителем/аналитиком/трейдером/бухгалтером/администратором и т.д. ? Он тогда кто по-Вашему ? Программист или нет ? Или должна быть категория "потенциальный программист" ?
Что касается Ваших знакомых/коллег, то скорее всего у них изначально есть способности к программированию
Так я про это и говорю. Есть много людей с достаточно развитым аналитическим мышлением, которые просто не являются программистами. При этом они могут на хорошем уровне, например, освоить SQL, но не могут (или не хотят) управлять памятью и многопоточностью в C++ или хотя бы в Java. Их можно тогда задействовать в разработке на том же COBOL - нужно лишь их мотивировать. Самый простой вариант - деньгами.
А что если есть человек, у которого склад ума такой же, как у программиста, но он сейчас работает не программистом, а менеджером/учителем/аналитиком/трейдером/бухгалтером/администратором и т.д. ?
Кстати, в 70х в нашей школе факультативно проходили курс программирования (на Алголе и Фортране).
И были среди нас отличники, которые сейчас работают менеджерами, инженерами и врачами (хотя возраст уже вполне пенсионный). Есть даже один историк :)
Программистами они не стали по причине низкого спроса на эту профессию в то время, когда и ЕС ЭВМ были новинкой.
Тем не менее, это противоречит тому, что написано в топике: предпочитают искать готовых программистов, а не переучивать технических специалистов. Я не сторонник считать, что они все там дураки и ничего не понимают. А значит в этом есть смысл.
Ну и был у меня коллега с достаточно развитым аналитическим мышлением. Так перешёл в программисты. Так что да, считаю таких людей потенциальными программистами, особенно у нас.
То есть достаточно для того-же Java кода построить возможность задавать его визуально в виде стрелочек и формочек, и тогда это перестанет быть программированием, и будет другой профессией? А оно станет по такой логике гораздо проще ?
Этот подход реализован в HiAsm
в разных пакетах для его применения в поддерживаемых языках (к примеру и C#)
P.S. Да, этот подход ближе к «строительству» программ, в отличии от классики программирования.
Мой тезис в том, что важен не способ задания программы (визуально, или в виде кода). Важна архитектура/парадигма той платформы, в которой создается эта программа.
Например, языки в Java и C# немного отличаются, но платформы - похожи. А в Java и C++ языки похожи, но принцип разработки отличаются гораздо сильнее.
И визуальное программирование требует значительно более высокого уровня абстрагирования, и, соответственно, другой платформы. А мышкой это делается в графике, или кодом - это не столь принципиально.
да нафиг он нужен, этот кобол
вот реально, потерять год-два на.. что? Научишься чему-то новому и востребованному? Поднимешь какие-то скиллы до нужного уровня? Это ж болото и тупик, деградация себя как торговца своей рабочей силой на рынке
В 1978 году на COBOL в виде развлечения я написал не экономическую программу (бизнес тогда был под запретом в СССР), а программу "Автооператор", которая управляла потоком заданий на перфокартах. Программу эту даже купили.
Ох... "Эта музыка будет вечной..." (с)
COBOL разрабатывался как очень специализированный язык для вполне конкретных приложений. Равно как FORTRAN изначально разрабатывался для расчетов математических
Кстати, были времена когда под коммерческие вычисления делались специальные модификации RISC процессоров - C-RISC — «Commercial-RISC».
И в сове области COBOL был хорош. Он давал очень быстрый и эффективный код. И именно поэтому на нем столько написано именно в области коммерческих приложений. И он до сих пор остается быстрым и эффективным, что бы там ни говорили.
Тот случай с системами занятости, который так любят мусолить, на самом деле к COBOL не относится:
В первые дни Covid-19 предприятия массово закрывались. Уволенные работники кинулись в Интернет, чтобы подать заявление на получение пособия по безработице, а веб-сайты правительств многих штатов рухнули под нагрузкой. В Нью-Джерси губернатор заявил прессе, что их системы COBOL отчаянно нуждаются в помощи, чтобы справиться с новыми требованиями. «Буквально, у нас есть системы, которым более 40 лет», — отметил он.
Но технологи, работавшие за кулисами над устранением проблем, знали, что проблема не в COBOL, вычисляющем цифры. Это старое оборудование работало нормально. Нет, сбой произошел в более новых вещах — программах, обеспечивающих работу самого веб-сайта.
«То, что вышло из строя, было веб-приложением между мэйнфреймом и внешним миром. Именно оно и развалилось», — говорит Марианна Беллотти, программист и писательница, которая много лет работала с правительственными системами и наблюдала за работой системы Нью-Джерси. Но признать, что «о, наши веб-системы сломались», слишком стыдно, как отмечает историк Хикс.
Беллотти видела, как то же самое происходило с другими государственными учреждениями, например, с налоговой службой. Однажды ее позвали помочь с веб-приложением Налогового управления, которое не работало. Когда они провели расследование, то обнаружили, что, действительно, проблема была в более новых программах, «в этом куске плохо написанного кода на Java». Мейнфрейм, работающий на COBOL, напротив, мчался как Ferrari.
«Мейнфреймы, — говорит она, — реагировали в течение миллисекунд».
https://habr.com/ru/company/itelma/blog/577736/
Дело в том, что такие системы многослойны. Есть мейнфрейм, где хранятся все данные и реализуется вся логика, есть фронт-системы, реализующие пользовательский интерфейс и всякие модные и креативный фичи и есть middle слои, реализующие API для фронта, которые преобразуются в запросы к мейнфрейму (который может быть вообще изолирован от внешнего мира - общение с ним идет через шину или очереди). Фронты и middle реализуются на современных стеках, но там нет ни работы с данными, ни какой-то серьезной логики.
Проблема COBOL не столько проблема самого языка, сколько окружения в котором он работает - чтобы писать эффективный код на таком уровне, надо понимать как все это работает в целом (там реально может быть очень много тонкостей - сам пишу, хоть не COBOL, RPG под IBM i - очень много чисто системных особенностей, которые сильно влияют, порой можно буквально на порядок снизить потребление процессорных ресурсов и повысить скорость просто используя особенности системы).
Тут возникает второй вопрос - умирают мейнфреймы или нет. На эту тему периодически возникают разные обзоры. Например: https://idcdocserv.com/US46775720
Общий вывод - нет. Не умирают. Область их использования достаточно локализована и специфична, но жить они будут еще достаточно долго и вполне себе развиваются и поддерживаются. Эти системы проектировались для одновременного выполнения множества процессов (заданий). Например, та же IBM i (AS/400) спроектирована так, что накладные расходы на переключение контекста процессов там существенно ниже, нежели в Win и *NIX системах. Что в целом повышает общую производительность именно в многопроцессной работе (например, при использовании систем, построенных на модели акторов).
Аренда мейнфрема, конечно, дорого, но есть эмуляторы (насколько близко к реальност они эмулируют второй вопрос), есть публичные сервера - тот же PUB400 (публичный IBM i сервер с бесплатной регистрацией, 2 библиотеки, 300Гб дискового пространства. Там есть C/C++, CL, RPG, COBOL). В целом особых проблем с обучением нет.
Переход с COBOL на "современный стек" неоправдан. В силу огромного количества эффективно работающего, отлаженного кода. Причем, в очень сложных системах где огромное количество таблиц, программных модулей, одновременно работающих тесно интегрированных между собой процессов. Перевести все это на новый стек, не потеряв эффективности и сохранив функциональность та еще работа (с учетом вникания в бизнес-логику, переписывания огромного количества кода и огромного количества ретестов). Причем, результат не факт что будет лучше - "новый" стек может точно также устареть через 10-15 лет.
Из известных попыток крупная пожалуй только одна. Банк Содружества Австралии и Океании. Переписали старый код на новый стек. Заняло у них это 5 лет (2012-1017гг) и обошлось в $750млн. Плюс некоторое количество сбоев в процессе перехода (самый известный - внезапное обнуление кредиторской задолженности всех клиентов - поправили, восстановили, но это тоже затраты сил и времени). Других желающих не нашлось.
Такие предложения идут чаще от молодых-проактивных, привыкших работать с модными фреймворками, но совершенно не имеющих опыта в работе с такими системами на уровне их ядра. Для тех же, кто со всем этим работает, "легаси" воспринимается как надежный, эффективный, достоверно работающий код, который не надо лишний раз трогать.
В целом, COBOL как-то продолжал развиваться, по крайней мере до 2014-го года. Даже были какие-то попытки внести туда ООП. Но в настоящее время не слышал чтобы на нем разрабатывалось что-то новое (хотя в той же IBM i он поддерживается на уровне системы).
Сейчас вместо него используется RPG (по крайней мере на платформах IBM). Который хоть и вырос из бланков и перфокарт (RPG Fixed Style - ранние версии), но в настоящее время очень сильно модифицирован (Free Style без необходимости позиционирования) до нормального процедурного языка, умеющего работать с указателями, динамическим выделением памяти и т.п. При этом в нем присутвует все, что необходимо для коммерческих расчетов - типы данных с фиксированной точкой, мощные средства работы со строками, возможность работы с таблицами и индексами напрямую (что не исключает использование SQL где это необходимо - SQL операторы могут встраиваться непосредственно в RPG код). И при этом получается весьма эффективный код.
Есть определенные сложности при работе с многопоточными приложениями. Но это уже скорее специфика области применения - в job isolated многозадачных системах, требующих постоянного сопровождения, предпочитают распараллеливать обработку большого количества данных на несколько заданий, но не потоков. Так проще для сопровождения т.к. если в потоке что-то пошло не так, останавливать придется всю задачу целиком (да и диагностировать такую ситуацию сложнее). Задание же полностью изолировано. В случае критического исключения оно просто переходит в соответствующий статус, который сразу виден сопровождению, не затрагивая другие задания (т.е. если у нас есть 1 головное задание, собирающее данные для обработки и раздающее их обработчикам + несколько заданий-обработчиков, то падение одного из обработчиков никак не скажется на всех остальных во-первых, во-вторых, сразу будет обнаружено и диагностировано сопровождением).
В общем, как-то много получилось... Но вопрос COBOL это не вопрос синтаксиса или возможностей, но вопрос очень комплексный - задачи, окружение, требования к надежности, эффективности, сопровождаемости. И пока старый код с этим задачами справляется, никто, кто умеет считать деньги, просто так, ради какой-то "концептуальности", ничего переделывать не будет. Слишком дорого и сложно.
Что же касается высказываний "я этим заниматься не буду - это не даст мне ничего, что я потом смогу применить где-то еще" - ну это просто личное мнение. Спрос на разработчиков в таких областях не так высок. Но он есть и достаточно стабилен (если судить по соответствующим группам в том же LinkedIn). Правда, там достаточно замкнутое сообщество и очень много вакансий закрывается без публикации, просто через знакомых и знакомых знакомых человек переходит с одного места на другое. И те, кто туда сознательно попадают (а молодежь приходит), обычно остаются на всю жизнь. Просто потому что что-то в этом для себя находят. И не только деньги.
Освежите ваш COBOL: почему на язык 60-летней выдержки вдруг резко возник спрос?