Казалось бы, COBOL должен был остаться только в памяти старых программистов, как смутное воспоминание давних времен. Ан нет! Буквально в течении двух дней мне на глаза попалось две новости, связанные с COBOL-ом.
Первая новость о том, что почтовая служба США произвела миграцию своей системы контроля посылок на сервера под управлением Linux. При этом сама система, написанная на COBOL, не была переписана, а только адаптирована к работе на Linux-е. Вот так вот. Бог весь когда созданная система работает до сих пор, обрабатывает порядка 40 миллионов посылок в день. И даже не думает переписываться на чем-то более современном.
Вторая новость о том, что некая компания выпустила инструментарий для миграции COBOL приложений с мейнфреймов под Windows. При этом подчеркивается, что в отличии от других подобных решений (есть еще подобные средства!), этот инструмент не требует модификации COBOL приложений для организации работы с MS SQL Server. Т.е. опять COBOL-программы не получат шансов быть переписанными :)
На мой взгляд, это хорошие иллюстрации к понятию “бессмертности языка программирования” – после некоторого объема написанных с помощью конкретного языка приложений, язык уже не может просто так исчезнуть. Он будет жить до тех пор, пока живут написанные на нем системы. Которые, как показывает пример COBOL-а могут жить очень долго. Для меня, как old-school C++ программиста, это хорошо :)
Небольшое лирическое отступление. Про COBOL я слышал всего несколько раз. Впервые, когда в аспирантуре пытался разобраться с историей развития СУБД. Ведь до распространенных сейчас РСУБД доминировали другие типы БД: иерархические и сетевые. И были даже т.н. предложения CODASYL, которые я пробовал изучать. Затем, как раз на волне ажиотажа с ошибкой 2000-го года я слышал, что крупные оффшорные компании (например, BelIBM в Минске) не хило поднялись за счет модификации COBOL-овских программ для западных заказчиков. Потом, уже вскоре после 2000-го года я где-то видел статистику, согласно которой подавляющее большинство бизнес-приложений в мире было разработано на COBOL. Но не могу утверждать, что эта статистика заслуживала доверия. А в последний раз я слышал про COBOL, наверное, в 2002-м году, когда мы со специалистом из Сбербанка РФ обсуждали детали реализации интерфейса к одной из их систем. Тогда в разговоре этот специалист упомянул, что ему свою часть работы придется делать на COBOL, т.к. нужная нам система в СБРФ как раз на COBOL-е и сделана.
Такие дела.
Работаю в конторе которая пишет на MUMPS'е (MSM версия). GUI - на дельфях. Я написал что-то вроде iBATIS'а на C# и на Java, для работы с WinMo и линуха. Потому что перейти на SQL - нереально никак. Кроме кучи работающего MUMPS кода - низкие требования к серверной части у MSM. Апгрейд железа у клиентов явно не вызовет воодушевления. Да и сам код... MSM позволяет напрямую работать с com портами, а железа перефирийного в виде электронных замков, датчиков - хватает, вот и написано на M такого низкоуровнего кода, который придется переписывать. Вобщем - смерть конторы просто будет :)
ОтветитьУдалитьСпасибо за комментарий.
ОтветитьУдалитьПро MUMPS я читал, когда лет пять назад на работе готовил лекцию об истории языков программирования. Тогда первый раз про него услышал и прочитал что-то в том же духе: во многих местах используется (кажется, чуть ли не все здравохранение в США было окучено программами на MUMPS-е). И переписать все это дело на чем-то другом не представляется возможным.
С другой стороны, в этих унаследованных системах и языках есть некая гарантия безопасности для разработчика: попробуй такого уволить, где на его место замену взять? Молодежь на MUMPS и COBOL не особо ведтся :) Но это при условии, что системы развиваются, а не доживают, имхо.
Да, он оттуда и пошел, из задач здравоохранения в США. И сейчас там потому используется. Последний писк - Gt.M - с JIT компиляцией Мкода. Ну и конечно Intersystems Cache (которая и поглотила Micronetics, разработчиков MSM - версии MUMPS)
ОтветитьУдалитьМолодежь же... ведется на зарплаты :) Но понятно, что лучшие уходят в аутсорс, а нам достаются - такие себе :) Сейчас вот молодого натаскиваю. MSM + Java, потому что есть в планах коммерческих клиентов перевести с дельфей на джаву. Бюджетные же (медицина) так пока и останутся. Потому что даже переводить с дельфи на что-то другое - смысл?
Кстати, думается мне что потому и вхождение новых технологий, ЯП в массы замедляется и будет замедляться. Например - молодежь уже массово фыркает - Java? фи, старо, умрет скоро. Да только как с COBOL'ом, а кто же будет переписывать ПО с Java на нечто другое, моднявое?
Поэтому и разговоры вокруг Хаскеля, Scala, ... еще долго останутся - разговорами.
Примерно так и вокруг руби с питоном. На пэхапэ и перле понаписано немало. Кто оплатит переписывание? Или перевод на "рельсы" и джангу.
Или, более локально - кто подвинет 1С?
То есть, я бы сказал что языки-технологии скорее не сменяют друг друга, а укрепляются в новых, до этого отсутствующих областях. Не было понятия мидлваре, не было вэбщины, Си/С++ было достаточно. Появились десктопы с оконным GUI, понадобился визуал бейсик с дельфи. Появился вэб, понадобилось что-то для быстрой разработки CGI, и т.д. То есть для того же Хаскеля и ФП - нужна новая область, чтобы выйти из маргинального состояния. И даже у Scala - очень совместимой с Java - туманные перспективы.
Я пару лет назад у кого-то из умных людей прочитал (Страуструп, Хайлсберг, Вирт, Гослинг -- вот не помню, хоть убей, но личность такого калибра) -- новые языки не конкурируют друг с другом, а занимают новые ниши. Т.е. локальная конкуренция местами есть, но не очень большая. Так что вы правы на этот счет.
ОтветитьУдалитьА по поводу молодежи... Я несколько раз за последние годы сталкивался с отношением -- зачем мне изучать C++, Ruby, Scala, ..., если я с Java или C# найду себе работу в [имя компании] и буду получать [сумма в долларах]? Сразу не знаешь, что и ответить... :(