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

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

А почему бы этим компаниям не предлагать какие-либо специальные условия для программистов? Например банально больше денег. Это хорошая компенсация тому, что программист будет тратить время на технологию, которая врядли в перспективе ему принесет что-либо полезное.
Не все решают деньги.

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

Мотивации для выпускников нету.
Ведь сейчас мода на стартапы, JAVA, .NET, iOS приложения, Ruby и т.д. Все эти технологии позволяют продемонстрировать публике что-то классное. А код на COBOL сидит глубоко в системе и не виден никому особо. Еще COBOL означает работу с людьми, которые почти пенсионеры, это вызывает дискомфорт для молодых людей.
Развитие — это не обязательно переписывание системы с нуля на последнем модном языке.
Моя позиция, что развитие — это что-то новое.
Ведь так хочется сделать что-то эдакое, которое можно назвать своим и другим показать:)
Так в чем проблема? Вслушайтесь как звучит:

Смотрите, я сделал это на Коболе! И оно работает!
Я считаю, что это почти не получиться никому показать.

1. Банки не позволят (безопасность);
2. Почти нет людей, знающих COBOL;
3. Не все ценят код, кому-то хочется увидеть что же он делает в конечном итоге, а с этим проблемы.
Т.е. если Linux Kernel как начали писать на C, так и пишут на С 20 лет спустя, то это не развитие, и ничего нового там нет?
А слова «Моя позиция» понять сложно?)
Слабо признать, что у других может быть свое мнение?)

Системным программистом не каждый может быть. Для меня важно написание программ, которые взаимодействуют с людьми, а не с другими программами.
А с нуля и не надо переписывать все разом. Это раз.

Кобол-коболом, но необходимо учитывать риски. Вот они уже поняли, что все плохо с программистами на коболе. Почему вместо того, чтобы потихоньку переписывать на языках, снижающих стоимость разработки и «bus-factor» (фактор, что человека, хранящего знание собьет автобусом — утрировано), они идут по пути набольшего сопротивления и держутся за системы, которые никто не может поддерживать?

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

Плюс, надо понимать, что кобол перестал быть популярным не просто так, а потому что он имеет недостатки.

Если нельзя создать рынок для кобола, нужно подстраиваться под текущие веяния.
Потихоньку не получится.
Нужно написать сразу готовую систему, полгода-год использовать параллельно со старой — это в два раза больше работы для операторов, а потом переходить на новую.
Это очень дорого.
И в конце может оказаться, что старая система была таки лучше в работе и дешевле в сопровождении — по крайней мере, каждому пользователю не нужно было покупать отдельную лицензию :)
Нет такой пакости, которую не выучил бы программист ради 200% прибавки к зарплате.
Ну вот не надо, даже от такой прибавки можно отказаться. Даже от 300%-ной.
Ну всё-таки это очень зависит от наличия семьи, детей, жилья, ну и от такого какой у вас текущий уровень.
Пожилому миллиардеру на пенсии можно и отказаться, конечно.
Хм… наверное я идеалист, потому что это именно то что я сделал — отказался от должности кванта-девелопера в Голдман Сакс, с зарплатой в три раза больше чем имею сейчас. При этом есть семья (детей правда нет пока), съемное жилье, ну и миллиардов разумеется тоже нет. Тупо не хотелось работать в банке, а ведь у них даже не Кобол, а связка Slang / C++.

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

Но статистическое большинство мыслит иначе.

Хотя очень многие ИТ-шники ненавидят работать в банке (мне кажется, даже не из-за специфики работы или дресс-кода, а потому что глаза режет контраст, сколько зарабатывают рядом находящиеся не слишком отличающиеся по количеству напрягов)
Статистическое большинство вообще не способно мыслить самостоятельно,…
Это не я придумал, это Маркс сказал.
Не путаем капиталиста и программиста.
И помним про Перельмана, миллион и сколько это процентов было прибавки.
НЛО прилетело и опубликовало эту надпись здесь
Видимо все таки есть предел. 400?
Не все измеряется в деньгах. Я бы и на 1000% не согласился если мне это не интересно.
В нашей стране в случае ABAP большое количество выпускников на практике выглядят таки очень мотивированными.

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

Т.е. всё просто — выпускники видят, сколько через пару лет после вуза зарабатывают их предшественники + есть понятные точки входа в отрасль для новичков.
Ну SAP ещё очень архитектурно интересная штука вообще-то. ABAP-ом она пронизана сверху до низу, и если вверху это выглядит туповато, то в комплексе всё очень здорово.
Очень вероятно, что и в упомянутых банках система на коболе им и дорога тем, что там всё очень сдорово.
На поверку тридцатилетняя система на коболе оказывается лучше — гибче, быстрее и дешевле, чем монстр SAP.
Ну как бы я это имел и ввиду. Перспективы нету, как вы и описали. И это должно компенсироваться деньгами.
странная психология какая-то. Думаю, сантехники не согласились бы с таким мнением. И почтальоны.
В данном случае вопрос как раз в деньгах. Мне кажется, это похоже на переход от нефти к альтернативной энергии. Пока это невыгодно, бизнес не начнёт «чесаться». Лично я за быстрый рост зарплат COBOL-программистов. Рентабельность, беспощадная ты сука)
А что с аппаратной частью этих мэйнфреймов? Тоже не апгрейдили с 1959 года?
Виртуализируется.
Пожалуй, большинство банковских систем работает на IBM мейнфреймах которые обновляется по железу без проблем.
Там, на самом деле, не мэйнфреймы, чаще всего, то есть не z-Series, а AS400 какие-нибудь, но от этого не легче.
И, да, они часто не купленные, а лизинговые. За счет этого решается проблема апгрейда.
Ну а те, что на самом деле мэйнфреймы, которые с 60-х, те точно арендованные, IBM долгое время не продавала, а сдавала в аренду системы (и софт), и, тем самым, решалась проблема апгрейда, это была забота IBM.
На счет IBM AS/400 согласен, с утра зачем то отнес их к мейнфреймам…

Лизинг далеко не у всех, знаю на примере как Российских, так и европейских компаний.
Я не понимаю, в чём проблема изучения языка вне стен университета. Литературы и примеров кода должно быть навалом.
вот вот :) у них похоже за получение нелицензионных знаний (вне университета) расстрел на месте скоро будет полагаться :)
Думаю еще проблема с бизнес логикой. Сам язык прост, но запрограммированы на нём эпичные бизнес процессы. По хорошему нужен сильный экономический и математический багаж.

Вряд ли задачи по поддержке состоят только из изменения внешнего вида отчётов. Иначе Индия решила бы все проблемы.
Помимо того что написал предыдущий оратор про бизнес логику и знания в предметной области, ограничения есть и чисто бюрократического характера — нужна бумажка об образовании. HR не будет HR'ом если допустит человека без образования и опыта работы к святая святых банка.
Сами себе могилу копают
НЛО прилетело и опубликовало эту надпись здесь
Никто, конечно, не запрещает изучать язык самостоятельно. По моему, автор имеет ввиду следующую проблему. В университете формируется большая часть профессионального мировоззрения молодого специалиста, его отношение к предмету. Сейчас в основном готовят программистов, приученных мылить в объектно-ориентированной форме (в западных ВУЗах точно, там принципы ООП даются раньше, чем основные алгоритмические конструкции). Старые языки требуют другого образа мышления и других подходов к разработке программных систем. К тому же, по моему опыту, обучение какой-либо парадигме программирования редко сопровождается анализом области ее применимости. В результате появляются специалисты, применяющие объектно-ориентированный подход повсеместно.
Ушел создавать стартап по переносу кода с COBOL на php c автогенерацией комментов на хинди
Это, кстати довольно-таки серьёзная индустрия — разработка софта для реинжиниринга софта. Сам в такой работал некоторое время.
И сколько лет они собираются поддерживать код полувековой давности? 70? 100? Все равно придется рано или поздно, но лучше уж рано, пока действительно есть специалисты по полу-мертвым языкам.

Ответ: пока он работает.

Между прочим тут имеется огромный простор для стартапов. Только они должны быть не beta качества, а не менее надежные и функциональные, чем имеющийся кобольный код. Тот кто построит надежную масштабируемую систему обработки финансовых операций или хотя бы некоторых потоков не обретёт известости Цукерберка, но бабла заработать может не меньше.
Интересно, где же сейчас этот талантливый сотрудник банка (явно это не студенту писать)?
Вы о ком сейчас? Если о мне, то выпады про талантливость явно не к месту. Один из банков в Скандинавии, разработка новой функциональности на коболе, бюджет проекта сроком в несколько месяцев — около четверти миллиона евро.
Хей, а какие есть рецепты «как познакомиться с полем боя, не работая 10 лет в банке»? Фиг с ними со стартапами, мне просто интересны задачи и проблемы, которые там возникают.
Я бы сказал что нужно учить матчасть, т.е. знать чем занимается бизнес. Касательно ценных бумаг если, то понимать как и что работает в SWIFT-протоколе, какими последовательностями сообщений обрабатываются какие виды операций, как работают депозитарии, какая каким инстанциям нужна отчётность. Это нудно, сложно, не всегда непротиворечиво и поэтому сравнительно немного людей это понимает. Перед тем как влезать стоит подумать хочется ли жизнь связывать с обслуживанием сферы ничего реального не производящей, но это так, философия, чтобы не жалеть потом. :)
Для меня это сфера производства программ, и не более того. Интересна только как место, где можно пописать сложные программы, требующие высокой надежности.

А книги, рекомендованные ресурсы есть? Чтобы заделывать брешь, надо сначала ее увидеть…
Я бы не сказал что сами программы отличаются какой-либо алгоритмической сложностью или необычайной надежностью. Они сложны и надёжны потому что шаг за шагом, в течение многих лет, проб и ошибок, подгонялись под нужды конкретной компании и ответ на каждый «почему здесь это так» — история случившаяся сколько-то там лет назад, при участии людей, которые «no longer there», а все документы безвозвратно утрачены. Но оно работает.

Описание самого SWIFT формата открыто: www.iso15022.org и www.iso20022.org По теме ценных бумаг есть такая книжка: Адамова К.Р. «Депозитарные операции кредитной организации. Экономические основы и международный опыт». Но начать можно и с чтения статей в той же Википедии по теме.
К этому коду полувековой давности предъявлялись такие требования качества, которым современные системы на «продвинутых» языках даже близко не соответствуют. В статье русским по белому сказано, что переписывание жизненно важных частей системы связано с огромными рисками. Один косяк разработчика программы, разработчика компилятора или проектировщика, который раскрыл загадочную суть системы — и мало никому не покажется.
Вы сгущаете краски:)
Возможно. Но я не хотел бы, чтобы программу, отвечающую за проведение моих платежей или отвечающую за финансовые потоки моего государства писал какой-нибудь Java-программист, в идеале знающий, что такое полиморфизм, полагающийся только на результаты модных тестов и ничерта не понимающий, как работает железо. А именно таких кадров производит система высшего образования в сфере IT — «рынок требует». Надо знать, когда допустимо повышать уровень абстракции.
P.S. На Хабре проскакивали статьи вроде «Программисты не инженеры, а садовники». Это мейнстрим. Но! Такие системы должны проектировать и реализовывать инженеры.
И сколько лет они собираются поддерживать код полувековой давности? 70? 100? Все равно придется рано или поздно, но лучше уж рано, пока действительно есть специалисты по полу-мертвым языкам. Ещё идёт активное развитие языков программирования, постоянно появляются новые, топ языков медленно, но шевелится, внутри них самих возникают новые версии и стандарты, несовместимые со старыми. В общем пока идёт такая вакханалия, банкирам лучше пересидеть на своём старом добром коболе, пока ситуация не устаканится.
В крайнем случае через несколько десятков лет, если к тому времени вообще не останется коболистов, наверняка изобрету какой-нибудь искусственный интеллект, и его можно будет научить переводить программы с одного языка на другой.
В общем опасения не беспочвенны, но серьёзные проблемы маловероятны.

Да даже пусть все олд программеры закончатся, и банки все как разорятся и позакрываются. Миру станет лучше без банков.
В начале должна быть цитата
И сколько лет они собираются поддерживать код полувековой давности? 70? 100? Все равно придется рано или поздно, но лучше уж рано, пока действительно есть специалисты по полу-мертвым языкам
Вырастет спрос, появятся и программисты. Фраза «неучат COBOL в университете» вообще нелепа. Тут больше подходит «никто не изучает это гавно мамонта, потому что за него не так много платят».
Надо просто подождать еще десяток лет, тогда за кобол начнут платить и народ снова вернется к его изучению, причем тот, кто вернется первым, получит больше всего денег:)

А, вообще, хорошему программисту должно быть без разницы на чем писать: синтаксис изучается за несколько дней, платформа — за несколько недель, специфика работы — за несколько месяцев. И все, нет больше проблемы, вопрос лишь в цене, но первый абзац остается актуальным и кто-то на этом неплохо заработает:)
Всегда удивляли такие высказывания, синтаксис за несколько дней это очень и очень круто, ну разве что вы владеете скорочтением и фотопамятью.
Платформа за несколько недель? да какую-нибудь «windows internals» или «mac os x internals» изучать не меньше года, поверхностно. Пять известных томиков Intel Manuals — еще несколько лет.
Специфика — это опыт который приходит с годами.

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

Что касается синтаксиса за несколько дней, в чем тут проблема? Минимальный набор необходимых синтаксических конструкций — это не доскональное изучение всех возможных извращений, который позволяет делать язык. Это тот уровень, после которого можно начинать исправлять баги и поддерживать код. Лично я так пересаживался за перл, шарп и яву в свое время, оба раза проходили без каких либо особых проблем.
Тоже самое с платформой, не нужно знать все досконально, чтобы поддерживать чей-то код, нужно знать где искать и иметь представление о том, что нужно искать. На счет специфики и опыта согласен, опыт — это годы, но конкретные текущие проблемы должны пониматься быстрее. Хотя человек может иметь опыт работы с финансами, тогда все гораздо проще и быстрее.

Прогресс же в этой области, насколько я понимаю, очень даже стоит на месте, причем уже не один десяток лет:)

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

Лично я так пересаживался за перл, шарп и яву в свое время, оба раза проходили без каких либо особых проблем.

Конечно, ведь это довольно сходные языки. А если бы вы пересаживались на лисп или пролог, вы бы затратили намного больше времени.

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

Кстати, посмотрел тут примеры программ. Не сказал бы я, что он такой уж экстраординарный.
Там дело не в синтаксисе или среде разработки, а сложности кода и предметной области. По сути, чтобы исправлять, человек должен понимать как работает бизнес лучше самого клиента. Это весьма непросто.
На уровне того, что дается в вузах синтаксис реально учится за месяц-другой. Хотя бы потому, что именно столько на него в вузах и тратят. А если вам нужно знать на более высоком уровне, вам все равно нужно идти на работать в компанию, где на этом языке программируют. Тем более в статье речь идет о поддержке.
Именно.
Например, на изучению C++ уделяют 192 академических часа или 96 астрономических часов. Пусть мы изучаем со скорость 8 часов в день (ведь у нас есть огромное желание) тогда получаем: 96/8 = 12 дней. Вот за столько реально поднять свои знания в C++ до уровня предлогаемого в ВУЗе.
В высшем образовании помимо аудиторных занятий есть еще и самостоятельная работа. Ее обычно не указывают, т.к. заставлять работать дома строго определенное количество часов глупо.
За пару часов вам расскажут основы языка, еще 4-6 на синтаксис, остальное — разбор конкретных моментов параллельно с самостоятельной работой студента.
Это не школа, где дома делают только домашние задания.
> «В высшем образовании помимо аудиторных занятий есть еще и самостоятельная работа.»

Самостоятельная работа предполагается. Давайте не будет говорить о том, что студент придя домой сразу же начинает повторять и угляблять знания, а не идет гулять, отдыхать и т.д.

Ко всему же у студента мативация изучать тот или иной язык программирования это в основном получение зачета или сдача экзамена, а у специалиста это получение заработной платы. Это разные вещи.
> Давайте не будет говорить о том, что студент придя домой сразу же начинает повторять и угляблять знания, а не идет гулять, отдыхать и т.д.

А, в общем-то, стоило бы. В университетах США (по крайней мере в Virginia Tech), например, считается нормальным после занятий пойти в библиотеку, засесть за компьютер и шлифовать до самого вечера полученные знания, потому что иначе ты просто тратишь время, просиживая штаны в универе.

Если бы (ох, если бы!) и у нас требовали по полной программе, то процентов 80 вылетело бы буквально сразу :) Так что имеем то, что имеем.
> «Если бы (ох, если бы!) и у нас требовали по полной программе, то процентов 80 вылетело бы буквально сразу :) Так что имеем то, что имеем. „

Вот с этим я полностью согласен. Высшее образование сейчас развивается скорее в количественном плане (осваивая все больше денег), чем в качественном.
НЛО прилетело и опубликовало эту надпись здесь
Можно подумать, вы никогда не сталкивались с программистом, который полгода назад вам пообещал, что этот модуль перепишет за выходные :)
Это не так, даже для одинес и похапе.

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

На объективно серьезный уровень выходят только через года два — пять реальной работы.
Честно скажу, я никогда не писал на коболе. Но, исходя из моего понимания проблемы, там не надо делать что-то новое и сложное. Там надо потихоньку поддерживать и допиливать существующее. Годы опыта — это хорошо, тут спору нет, но начать работать человек сможет и после месяцев. Через десяток лет у всех этих контор не будет никого вообще, они не смогут ждать еще 5 лет, чтобы кто-то обзавелся опытом. Я это имел в виду.
Ну это скорее местечковая проблема, характерная для некоторых стран Европы. Там есть и не менее экзотические профессии, как то возжигатель свечей в замке, истопник… Не думаю что банковская система Казахстана или Молдавии находится в руках специалистов COBOL.
У меня брат служит на станции слежения на кавказе, под черкесском. Рассказывает что многие ключевые части на алголе. Собственно у них тажа проблема, специалистов которые этот комплекс могут обслуживать (как аппаратную часть, так и программную) крайне мало, переучиваются на месте.
Постсоветское пространство эта беда практически обошла стороной потому что финансовые организации появлялись в 90-х а тогда уже были совершенно другие технологии, нежели в 70-х.
Вы будете смеяться, но попробуйте найти «готового» специалиста по Perl. Квест выполнимый, но уже сложный.

А тут народ плачется о коболах… Такая масса кода без обслуживани не останется, кобол язык простой, логика читаемая, про идиомы и стандартные трюки не знаю, но их не должно быть много.

Проблема несколько в другом — становиться меньше программистов универсалов и людей желающих (и умеющих) читать чужой код. И меньше HR-ов умеющих оценивать универсалов и рисковать брать на работу человека без строчки в резюме. Проще делать вид, что специалистов нет.
Согласен — люди есть, но придётся подождать пока человек подрастёт до уровня специалиста, главное выбрать того, кто сможет быстро это сделать, а это только испытательный срок, во время собеседования вобще трудно, что либо понять на счёт обучаемости и трудолюбивости работника.
Либо «специалист» обучится и свалит к конкуренту на бо́льшую зарплату.
У нас часть системы на Roxen/pike написано, ничего, программисты поплюются, но починить если сломалось могут.
Мне вот не понятно, почему поддерживая старое говно на коболе нельзя параллельно переписывать всю эту бодягу кусками на новых платформах? Потому что стоимость поддержки старого убожества все равно со временем будет расти.
Как говорится, лучшее — враг хорошего.
Старое убожество работает и просит немного ресурсов на поддержку. Пусть это немного растет, но оно работает.
Будет ли работать новое стабильно, никто не знает. Но факт то, что на разработку нового надо оооочень много ресурсов.
Поэтому для финансистов вопрос очевиден: лучше потихоньку платить за старое надежное, чем иметь шанс потерять все.
Проект по переходу с одной системы такого уровня на новую занимает в лучшем случае лет 5. При этом все это время нужно оплачивать большую коанду разработчиков, которые будут писать, тестировать, исправлять и еще раз исправлять систему. После чего произойдет слож стный и иногда мучительный запуск. Стоимость такого проекта не сравнить со стоимостью поддержки существующей системы.
Причем за время проекта в мире программирования может поменяться очень много и технология опять окажется устаревшей.
Пишу на личном опыте, у нас в компании как раз идет смена ключевых бизнес систем с «устаревших» на новомодные.
Перенос старого функционала это большая и затратная задача на которую, как всегда, нет лишних денег. Поэтому пока затраты на поддержку не выросли настолько, что внедрение новой системы окупится за пару лет — вряд ли кто что-то будет менять.
Да это просто тупо опасно! Одно неловкое движение и за всю жизнь не расплатишься, ни ты ни компания которая переписывает/обслуживает код.
Ну, блин, в космос то вон как-то летают, хотя тоже вроде как опасно. :)
Капитализм!©

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


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

Так что или они наконец-то перенесут обработку на что-нибудь приличное, или им будет всё тяжелее латать свои кадровые дыры.
Ну я вот на него сейчас взглянул — поприятнее какого-нибудь ПХП будет.
PHP — далеко не из любимых мною языков.
^__^
Не пинайте, может я чего не знаю или не понимаю, но почему бы компаниям этим не стоять на месте, а идти вместе с развитием технологий?
Разве лучше альтернатив нет?
А если смотреть на проблему с другой стороны, то в чем проблема разобратся айти специалисту с любым из языко программирования? Для него лишь плюс.
1. Закрепленная за ним должность (на его должность вряд ли кого посадят).
2. Он развивается (ранее говорилось на хабре).
3. Ему это даст возможность, стать еще более востребованым (или как минимум опыт, в будущем, учитан в резюме.
4.… Разнообразные интересные обои (извините).
Ммм. Тут на самом деле сложный выбор.
С одной стороны — программа, которая у нас есть. В общем-то работает, требования удовлетворяет. Поддерживать ее с каждым годом, правда, становится сложнее

А с другой стороны замечательная, технологичная, современная программа с преферансом и поэтессами. Вот только одна проблема. У нас ее нету. Если начать разрабатывать, то через пару-тройку лет (я оптимист, да) она по функционалу выйдет на уровень того что было. Это если проект не завалится, естественно.

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

А что вы хотели, автоматизация бизнес-процессов non penis canina est.
Здесь оценивается не наличие или отсутствие альтернативных технологий (они в большинстве случаев есть), а риски, которые многократно возрастают при смене технологий. IT руководство банка принимает решение о переходе в первую очередь, на основе взвешенного анализа всех «за» и «против» этим оно и отличается от начинающих программистов, которым море по колено (а потом получается — как в старом анекдоте про клячу на скачках "… извини, мужик ну не смогла, не смогла"). Думаю, очевидно что даже минимальный fail такой системы не сопоставим с ЗП программиста и прочее.
Каждая большая (и особенно — старая) ИТ инфраструктура уникальна и неповторима, хотя и строится по общим принципам. И в ней содержится масса своей энтропии, которая проявится в самый неожиданный момент. Посему, поиск Кобол программистов — это нормальное управленческое решение.
— Когда нужна ракета?
— Вчера.
— А срок разработки 5 лет. Поэтому начинаем — сегодня.

Грамотные решения — это как-то так.
Потому что бизнес заинтересован тратить по возможности меньше денег на ИТ сейчас. Их не особенно интересует какая жопа наступит через 10 лет потому что большая часть из них надеется быть там, где выше и теплее.
Ассемблер старый? о_О Я перестал понимать мир…
К сожалению, теперь это удел одиночек-энтузиастов. Веяния времени уже не требуют борьбы за каждый байт. Даже под встраиваемые системы пишут на сях, жавах и васиках. И вирусы модно ваять на дельфях и upx-ить.
Помню кучи военных начинок и софта на ассемблере,
а для кучи:

-Н-ное количество бухгалтерского софта на Коболе от препода по проектированию и внедрению, потому что зачем менять старое, если оно работает.
-Ада еще используется (ну да как и раньше — узко).
-Ну и да, фортран — на нем, насколько помню, друг рассказывал, Обнинская АЭС работает.

Но все равно ассемблер по-крайней мере в универе проходится и чаще остальных динозавров юзается.
Вот ассемблер всё еще под DOS и int 21h проходится (в УГАТУ) или уже под Win32 API?
я проходил под дос) но я учусь в педе)
охохо ) вы для МК не программировали )) там все еще ведется «война за байты» )))
При нынешнем ассортименте мелкоконтроллеров всегда можно взять чип с дополнительным запасом памяти еще на этапе проектирования. Это если не стоит задачи впихнуть код в уже закупленное, добавить фишечек в готовое устройство, или случай «что было в ящике стола, то и поставим».
>всегда можно взять чип с дополнительным запасом памяти

и повесить рядом ещё одну батарейку?
И еще доплатить $0.11 * 340 000 000 = $37 400 000.
Мобилки, что ли?
Мне кажется, что рынок сам должен регулировать такие вещи. Если будет спрос — будет и предложение
А он и регулирует. Вообще ситуация один к одному совпадает к тому, что я описал в своей статье черт-те знает когда.

Старые технологии находятся после точки А — в зоне угасания технологии. И у разработчиков есть уникальная возможность заработать больше на резком спаде интереса.
НЛО прилетело и опубликовало эту надпись здесь
Жадные банкиры настолько жадные, что вместо того чтобы попытаться поднять уровень зарплат, попросили Karen Scott, исполнительного директора Hudson IT Scotland, написать статью о том как всем нужен COBOL. Жадные жадные жадные свинки.
У нас сейчас часто открываются курсы Кобола и постоянно набирают коболистов. Правда места куда берут — довольно ограниченны (крупные игроки финансового и «страховочного» сектора). Предыдущее поколение вымирает (уходит на пенсию) а мое — занимает их места.
У работы на Коболе нет «дополнительной радости» или «фана», как в «динамических и быстро растущих» стартапах, которые открываются и закрываются со скоростью фонд-райсинга. Зато стабильность — как нигда.

П.С. на экзамене по Коболу, в свое время, вышел с судорогой в руке от количества кода который писали ОТ РУКИ. Две стандартные экзаменационные тетради исписал, формата А4… Ностальжи…
80% мэйнфреймов страны работает именно с COBOL, и их бизнес-системы требуют непрерывной поддержки и развития.

Ключевая фраза. Жаль что менеджмент понимает ее как «ну допишите вот тут вот это побыстрому», а не «мы больше не найдем программистов чтобы поддерживать этих мамонтов, давайте снижать риски переходя к более популярным технологиям».
Как-то раз дали мне на поддержку проект на FoxPro.
Это был кошмар — мало того что я этот язык в первый раз видел, так и код был написан безграмотно и недокументирован.
Я конечно разобрался, пофиксил, подправил — заработало как надо. Но потратил кучу нервов.

А ведь FoxPro это еще не такой уж старый язык. До сих пор полно работающих систем. Про КОБОЛ я вообще слышал только в легендах :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Изменить настройки темы

Истории