Язык программирования COBOL старше Игоря Николаева. Люди, умеющие им пользоваться, часто того же возраста. Он лежит в основе целой финансовой системы и его нельзя оттуда убрать. Мы расскажем о том, как компьютерный язык управляет финансовой жизнью мира.
Когда Томас начинал программировать, на двое стоял 1969 год. Он был обычным парнем, только что выпустившимся из старшей школы в Торонто, не имея особых целей в жизни. Его отец был плотником, но в двери его семьи постучалась удача: оказалось, что руки у Томаса растут не из того места. «Мой отец знал, что я даже не смогу приколотить одну доску к другой», — смеётся он.
Поэтому его мать предложила нечто странное и новомодное: как насчёт… программирования компьютеров?
В 1969 году компьютеры всё ещё были странными новыми диковинками размером с большой шкаф. Но по всему миру компании начали понимать, что эти устройства бесценны для всех задач, требующих мгновенных бухгалтерских расчётов, например, подсчёта зарплат. Вакансии предлагались любому, кто хотя бы немного умел кодить. Поэтому Томас нашёл «небольшую школу-однодневку» в деловом центре Торонто и за следующие два месяца изучил самый популярный на то время компьютерный язык: COBOL (Common Business-Oriented Language).
После выпуска его приняли на работу в отдел сортировки чеков крупного канадского банка. (Он не захотел говорить его названия, банки скрытны; кстати, если вы еще не догадались, «Томас» — это псевдоним.) Тогда Томас ещё не был программистом банка, но за следующие несколько лет он чётко дал понять, что хочет им стать. Его работодатель оплатил несколько качественных курсов колледжа по кодингу и в 1978 году он начал долгую карьеру в качестве банковского программиста.
Томас полюбил работу. Она была похожа на постоянное решение головоломок, на игру в шахматы вслепую. Он садился за свой стол, писал от руки код, затем отдавал ему «оператору перфокарт», проделывавшему отверстия в картах, обозначающие программные инструкции. Дважды в день они вводили эти перфокарты в огромные «мейнфреймы» банка. Томасу требовалось несколько часов, чтобы убедиться в правильности работы кода или в том, что он совершил оплошность, из-за которой вся работа встала. Если случалось так, то он просматривал сообщения об ошибках, переписывал код на COBOL и пробовал снова.
За следующие несколько лет Томас хорошо освоил COBOL и написал тысячи бесценных строк кода. Когда банк производил платежи, именно код Томаса ежедневно помогал ему всё правильно подсчитать. Шли 70-е, 80-е и 90-е, Томас с коллегами-кодерами написали десятки миллионов строк на COBOL. Есть одна система, которой он особо гордится, это мгновенно работающая программа, способная обработать «от трёх до пяти миллионов транзакций в день. Это моё дитя!» Первые куски этой программы он написал в 1988 году.
И дело в том, что его код по-прежнему работает даже сегодня.
Томас уволился из банка в 2007 году в возрасте примерно 60 лет, и когда он ушёл, банк всё ещё использовал его систему, которой к тому времени исполнилось 20 лет. Она написана ещё тогда, когда на голове у Томаса было намного больше волос, а хитом чартов была «Groovy Kind of Love» Фила Коллинза. Сегодня этому коду уже больше трёх десятков лет. И он по-прежнему обрабатывает миллионы записей в день. Томас считает, что бОльшая часть кода, который он и его коллеги написали в своё время, всё ещё работает, потому что банк не сможет без него функционировать.
Когда в доме в небольшом городке рядом с Торонто, куда перебрался на покой Томас, сегодня звонит телефон, это иногда бывает кто-нибудь из банка.
«Здравствуйте», — говорят ему. «Эээ… можете нам помочь… обновить ваш код? Возможно, добавить в него новые функции?» Потому что, как оказалось, банк больше не нанимает никого, кто понимает COBOL так же хорошо, как Томас, того, кто может погрузиться в код и изменить его так, чтобы он выполнял новую задачу. Почти все ветераны COBOL, жокеи перфокарт, создававшие критически важные банковские системы в прошлом, знающие COBOL вдоль и поперёк — все они уволились. Они «покинули здание», как и Томас. И немногих молодых кодеров интересует изучение пыльного пятидесятилетнего компьютерного языка. Их гораздо больше вдохновляют волнующие новые области, например, развивающееся сообщество разработчиков искусственного интеллекта в Торонто. Они изучают свежие и новые языки программирования.
Поэтому этот крупный банк по-прежнему зависит от людей вроде 73-летнего Томаса, который не только обеспечивает работу кода, но и может добавлять новые возможности и улучшения.
Переживёт ли Томаса его код на COBOL?
«Вероятно».
Этот банк не одинок. Программы на COBOL, некоторые из которых были написаны ещё до появления цветных телевизоров, используются в нашей повседневной жизни повсюду.
Представьте: в более чем 80% личных транзакций финансовых организаций США используется COBOL. Когда вы проводите своей пластиковой картой, то в 95% случаев обработку выполняет COBOL. Bank of New York Mellon выяснил в 2012, что у него есть примерно 112 500 отдельных программ на COBOL, состоящих почти из 350 миллионов строк; вероятно, это типично для большинства крупных финансовых организаций. Когда ваш босс вручает вам зарплатный чек, есть вероятность, что он подсчитан при помощи COBOL. Если вы занимаетесь инвестициями, то ваша торговля акциями тоже выполняется на нём. То же самое происходит и в здравоохранении: страховые компании США используют «adjudication engines» — программное обеспечение, определяющее, сколько заплатят врачу или фармацевтической компании; они так же написаны на COBOL. Задумывались, почему при совершении покупок в розничном магазине продавец вводит данные в старомодный терминал с зелёным текстом на чёрном фоне? Потому что в системе инвентаризации используется COBOL. Или почему специалисты по бронированию авиабилетов пользуются тем же чёрным экраном с зелёными буквами, чтобы изменить данные рейса? «О, это COBOL, это совершенно точно COBOL», — смеётся ведущий инженер Faircom Крейг Бейли. Его фирма создаёт ПО, помогающее компаниям управлять этими старыми системами.
Никто точно не знает, сколько существует кода на COBOL, но, по оценкам, наиболее важные аспекты нашей повседневной жизни втихомолку обслуживает примерно 240 миллиардов строк кода. «Вторым по ценности ресурсом в США после нефти являются 240 миллиардов строк COBOL», — говорит Филип Теплицки, десятки лет писавший на COBOL для банков по всем США.
Нам часто говорят, что технологии процветают благодаря новым, передовым инновациям, желанию рисковать и создавать с помощью кода нечто новое, «двигаться быстро и сокрушать препятствия», как написал молодой Марк Цукерберг на своей стене в Facebook. И каждый день мы действительно видим, как появляется безумный новый код, написанный на модных и новых языках. Возможно, вы видели новый ИИ, способный писать предложения как человек — он создан благодаря Python, хорошо известному новому компьютерному языку. Когда Facebook добавляет новые функции в своё браузерное приложение, то кодеры часто используют JavaScript — ещё один популярный язык.
Но как насчёт более старых и массивных отраслей, являющихся центральными для экономики? В них по-прежнему вездесущ COBOL. Из-за этого инновации усложняются. Как создавать и прикручивать новые возможности с помощью древнего языка, который неинтересен энергичным молодым кодерам? Если крупные старые банки — это не компании, двигающие прогресс вперёд с помощью сервисов наподобие Venmo или Square, или других громких финтех-продуктов, то из этого следует, что COBOL является частью проблемы. Но если это так, то почему же Томаса по-прежнему тревожат на его заслуженной пенсии, чтобы он поддерживал жизнь в этих системах? Почему нельзя обойтись без них?
Частично это вызвано тем, что COBOL был первым, и он оказался инструментом, идеально подходящим для своей задачи. Во многих смыслах COBOL был той искрой, из которой возгорелась вся наша современная компьютерная эпоха.
Программисты начали разработку COBOL в 1959 году. Когда его наконец выпустили десять лет спустя, в 1969 году, он стал первым компьютерным языком, благодаря которому компьютеры можно стало активно использовать в повседневной жизни. В конце 50-х у компьютеров только завершилась «экспериментальная» стадия. Обычные компании начали взвешивать возможную ценность приобретения собственного компьютера для перемалывания чисел. Однако проблема заключалась в том, что до появления COBOL кодинг был непонятным и сложным в изучении. Программисты часто писали ПО на какой-нибудь разновидности «ассемблерных» языков, команды которых были ужасно мудрёными. (Например, команда
LXA A,K означает «взять число, загруженное в ячейку A компьютерной памяти и загрузить его в индексный регистр K».) Усугубляло ситуацию то, что производители компьютеров часто создавали для своих машин собственные уникальные языки. Если написать отличный код для машины, то он не сможет работать на компьютере, изготовленном другой компанией.Новое поколение амбициозных программистов считало это безумием. Одним из них была контр-адмирал ВМФ США Грейс Хоппер, обладавшая яркой индивидуальностью. (Именно она популяризировала выражение «проще попросить прощения, чем получать разрешение».) Хоппер считала, что языки программирования должны сильнее походить на английский, чтобы их было проще учить и читать. В 1955 году она разработала язык «FLOW-MATIC», предназначенный именно для этой задачи; например, для перемещения числа из ячейки A в ячейку D на нём нужно было просто написать
TRANSFER A TO D.В 1959 году программистка Мэри Хоуэс решила, что её отрасли нужен язык, на котором писать будет так же просто, как на FLOW-MATIC, способный при этом работать на любой машине. Она собрала комитет специалистов, в том числе из только зарождающейся отрасли бизнес-компьютеров, чтобы приступить к созданию языка под руководством министерства обороны. Задача заключалась в написании языка, который бы мог читать и понимать обычный менеджер компании, даже если он не учился на программиста.
Спустя десятилетие работы, активно продвигаемой множеством женщин-суперзвёзд этой отрасли, например, пионеркой компьютерных наук Джин Саммет, был создан язык, во многом напоминавший FLOW-MATIC и простой в понимании. Например, для сложения двух чисел можно было написать
ADD Num1, Num2 GIVING Result. Чтобы выполнить вычисление три раза, нужно было написать PERFORM 3 TIMES.«Сложно переоценить важность COBOL», — говорит адъюнкт-профессор истории Мар Хикс из Иллинойсского технологического института и автор книги «Programmed Inequality». «Он совершил в компьютерных вычислениях совершенно необходимый шаг. Язык заполнил ту нишу, которая оставалась пустой на протяжении первых лет компьютеров. И он изменил образ мышления, необходимый для написания программ».
Изменил он и круг тех, кто мог на нём писать. COBOL демократизировал кодинг; теперь компании могли нанимать обычных людей и обучать их, за несколько месяцев превращая в полезных программистов на COBOL, а через пару лет — в специалистов. Это было критически важно, учитывая, что компаниям отчаянно требовалось больше гребцов, чтобы писать ПО.
«Можно было брать людей с улицы», — рассказывает британский кодер Джон Пайк, изучавший COBOL в 1960-х. «И, по сути, учить их, как писать программы».
Ещё один плюс COBOL заключался в его скорости. Он проектировался специально для очень быстрого выполнения огромного количества «транзакций». Если вы работаете в розничной сети, то каждый вечер вам надо подсчитывать продажи и пересчитывать остатки. А у вас на это не так много времени — может быть, пара часов вечером, после завершения рабочего дня, пока ваш компьютерный персонал работает допоздна.
С банками та же ситуация: в течение рабочего дня они суматошно принимают транзакции, запросы на вывод и поступление денег клиентов на их счета. По вечерам у них есть несколько часов на подсчёт баланса всей этой бухгалтерии. Возможно, вы задавались когда-нибудь вопросом, почему клиринг размещённого вами чека занимает какое-то время. Частично это вызвано тем, что обоим банкам нужно провести все эти огромные вычислительные задачи на COBOL после ухода дневного персонала. В Citibank код Теплицки выполнялся в огромном центре из 248 компьютеров-мейнфреймов.
«У тебя есть временной промежуток в шесть-восемь часов, чтобы проделать кучу работы — провести все транзакции в определённом порядке», — рассказывает он мне. «Для выполнения миллиарда транзакций за шестичасовое окно требуется мощнейшее оборудование».
COBOL был оптимизирован для выполнения именно этой задачи: обработки целого множества транзакций. Компьютерные языки часто имеют определённую когнитивную или творческую специализацию; каждый из них создавался под конкретный тип задач. Python превосходно работает с data science и искусственным интеллектом; Fortran был создан для преобразования математических формул в код; JavaScript создавался, чтобы программисты могли делать веб-сайты интерактивными.
А что же COBOL? Он подстраивался под работу на этих мейнфреймах, которые сами проектировались специально для перемалывания миллиардов транзакций, мгновенного считывания и записи потоков данных. Он походит на высокооктановое топливо, изобретённое специально для спортивных автомобилей. На протяжении лет компиляторы COBOL — программы, превращавшие напоминающий английский язык синтаксис компьютерного кода в единицы и нули, которые может выполнять чип компьютера — всё больше совершенствовались, поэтому скомпилированный код COBOL стал чрезвычайно быстрым. То есть причина того, что COBOL находится в основе столь многих критически важных систем, заключается ещё и в том, что он на самом деле достаточно хорош в выполнении своей работы.
«У разработчиков было пятьдесят лет, чтобы сделать всё правильно», — замечает Билл Хиншоу, управляющий агентством COBOL Cowboys, предоставляющим услуги программистов на COBOL.
Как ни странно, сам возраст систем COBOL идёт ему на пользу. Поскольку его экосистема стара, её тщательно избавляли от ошибок и багов. Когда программа пишется впервые, она неизбежно имеет проблемы. Иногда это опечатка или команда не на своём месте; в другом случае пользователь делает нечто неожиданное для программиста, из-за чего всё разваливается. Когда появляется новое приложение, в нём много багов и оно подвержено вылетам: его создатели отправили его в мир со всеми этими несовершенствами. На обнаружение всех проблем уходят дни, недели или годы.
Кодеры и пользователи программ COBOL, которые управляют миром, имели десятки лет на выявление и устранение проблем.
Адриана Стерн (на этот раз это не псевдоним!), ещё одна программистка, с которой я общался, работала на крупные канадские банки. Её карьера началась в 80-х, когда из систем всё ещё устраняли различные странные баги. Однажды она выяснила, что один банковский терминал в Квебеке передаёт в систему буквы со знаками ударения, чего не предусмотрел программист системы.
«Поэтому когда система пыталась интерпретировать их, она зависала», — рассказывает Адриана. В другой раз постоянно вылетала ещё одна программа на COBOL. В конечном итоге Стерн разобралась: причина заключалась в имени нового клиента, содержащем одну кавычку, которую программа интерпретировала как инструкцию «конец массива данных», что приводило к остановке выполнения кода.
Стерн работала на банки тридцать лет, и по её оценкам, 85% работы заключалось не в создании новых функций для банка, а в «обслуживании». Её труд напоминал работу цифрового сантехника, устраняющего протечки и постепенно повышающего стабильность выполнения программ.
«Это была сложная работа, мы как будто поджигали свечу с обоих концов», — рассказывает она мне.
Именно поэтому такие системы COBOL настолько надёжны сегодня. Их отлаживали больше, чем практически любой другой код на планете. Громкое новое приложение наподобие TikTok может появиться и получить огромную популярность даже с кучей багов. Если количество «лайков» под твоим последним постом считается немного неправильно, то это не вызывает особых проблем. А если вдруг крупная розничная сеть ошибётся в инвертаризации или банк внезапно не сможет отправить деньги? Это вызовет масштабный финансовый хаос.
«Весь ВВП мира находится в движении по банковской сети», — говорит Теплицки. «Банк ежедневно дважды оборачивает свои активы. А для клирингового банка, допустим, в Нью-Йорке, это число может быть ещё больше… То есть в движении по сети находятся огромные суммы денег, и их обслуживают крупные бэкенд-системы. Они не имеют права на сбой! Если они обрушатся, произойдёт катастрофа мирового масштаба. Мирового масштаба».
COBOL не просто быстр; он, как сказал мне Томас, «стабилен, стабилен, стабилен». Один из разработанных им процессов получает каждый месяц файл с примерно 2,4 миллионов государственных пенсий и переводит соответствующие суммы на банковские счета людей. «Мы подтверждаем и проверяем их за 11 минут. За двадцать лет процесс ни разу не дал сбой».
Эта идея о том, что старый код может быть не только хорошим, но в критических аспектах и превосходить новый, противоречит мифологемам Кремниевой долины. Финансируемые венчурным капиталом стартапы зачастую расхваливают блестящие новые технологии. Основатели обычно не хвастаются всем, насколько стара их кодовая база. Всё наоборот: они хвалятся, насколько прогрессивен их код, написанный благодаря ночному труду сонных двадцатиоднолетних гениев. Но почти любой программист скажет вам, что чем недавней написано ПО, тем больше вероятность, что оно представляет собой сборище багов.
Хороший пример этого можно наблюдать во время пандемии. В первые дни Covid-19 бизнесы массово закрывались. Уволенные сотрудники рванулись онлайн, чтобы подать заявление на получение пособий по безработице, и веб-сайты многих правительств штатов не выдержали нагрузки. Губернатор Нью-Джерси сообщил прессе, что их системы COBOL отчаянно нуждаются в помощи, чтобы справиться с новыми потребностями. «У нас в буквальном смысле есть системы, которым от сорока и более лет», — заявил он.
Но технологи, работавшие за кулисами над устранением неполадок, знали, проблема заключалась не в перемалывающем числа COBOL. Эти старые системы работали хорошо. Нет, всегда ломались более новые элементы — программы, управлявшие самим веб-сайтом.
«С ума сходило веб-приложение между мейнфреймом и внешним миром. Именно оно падало», — рассказывает программистка и писательница Марианна Беллотти, годами работавшая с государственными системами и следившая за этой системой Нью-Джерси. Но, по словам историка Хикса, властям было слишком неудобно признать «ой, да, это сломались наши веб-системы».
Беллотти наблюдала подобные явления и в других государственных органах, например в Налоговом управлении США (IRS). Однажды её вызвали для помощи с неработающим веб-приложением IRS. После расследования выяснилось, что проблема и в самом деле была в новых программах, «в куске плохо написанного кода на Java». Мейнфрейм с запущенным COBOL, напротив, гнал вперёд подобно Ferrari.
«Мейнфреймы отвечали всего за несколько миллисекунд», — говорит она.
Однако «стабильность» и старость кода способны создать парадокс — проклятие успеха. Поскольку код хорошо работает без проверок, люди со временем будут от него уходить. Они перестают смотреть на него, перестают его изучать. И это означает, что они перестают понимать, как же именно он работает.
Они определённо знают, что он работает. Ведь он функционирует каждый день, за мгновение обрабатывая миллионы транзакций! Но никто точно не знает, как и почему. COBOL превратился в непостижимую загадку, в демона, покорно исполняющего свои задачи, но таким способом, который никто не понимает полностью.
Это может стать серьёзной проблемой, когда спустя долгие годы вам нужно будет изменить что-то или добавить новую функцию.
Дейв Гуарино стал непосредственным свидетелем этого. Он разработчик ПО, много лет проработавший в Code For America — некоммерческой организации, позволяющей талантливым кодерам помогать правительствам с обновлением их древних служб. Несколько лет назад он помогал писать новое веб-приложение, чтобы калифорнийцы могли более удобно подавать заявления на продуктовые талоны. Веб-приложение находилось поверх более старых систем Калифорнии; пользователи должны были взаимодействовать с приложением, которое передавало бы их запросы коду на мейнфреймах штата Калифорния, написанному десятки лет назад.
И вот здесь возникла проблема. Команда Дейва хотела реализовать способ бронирования времени для встречи получателей продуктовых талонов с чиновником. В старых системах Калифорнии уже был раздел, способный получать подобный запрос. Но в поле «Когда вам удобно прийти на встречу?» старая система позволяла ввести только 40 символов и запрещала использование тире, поэтому нельзя было использовать сокращения, например, «пн-ср», чтобы сообщить, что пользователь свободен с понедельника по среду.
«Ну и мучение», — подумал Гуарино. Он встретился с человеком, управлявшим этой старой системой ПО. «К сожалению, да, таковы реальные ограничения», — ответил ему человек. И это была проблема COBOL, он был написан несколько десятков лет назад. «Что же мы можем сделать? Можно сделать поле побольше, или ещё что-нибудь?», — спросил Гуарино. «И он сразу же такой — нет, здесь ничего не поделаешь!» К этому коду на COBOL никто и никогда не собирался прикасаться. У штата даже не было столько денег, чтобы оплатить время, необходимое для изучения этой кодовой базы.
Кроме того, их, скорее всего, пугало то, что если они попытаются изменить что-то критически важное, то сломают код. И это ещё один парадокс успеха COBOL. Из-за его скорости и стабильности правительства и банки за годы и десятилетия привыкли полагаться на эти старые системы. Поэтому даже если вы захотите их изменить, пробовать будет слишком опасно. В том банке, где работала Стерн, можно было поседеть от стресса работы с действительно древним, критически важным кодом.
«Исправление ошибок было связано с высоким уровнем риска, потому что можно было поломать что-то уже работающее», — рассказывает она мне. Поэтому чаще всего вместо обширного переписывания старого кода они просто добавляли небольшие новые кусочки кода, патча системы «по краям». «Разработчики всё время добавляли небольшие фрагменты, и со временем система начала походить на маленького Франкенштейна», — смеётся Адриана. Что, разумеется, только делало систему потенциально более непознаваемой и запутанной для будущих поколений.
Однако чрезвычайно редко так случалось, некоторые проектировочные решения, принятые десятки лет назад, оказывались ужасными, и банкам с компаниями приходилось внезапно, в панике, погружаться в дебри систем и обновлять внутренности действительно старого COBOL. Именно это произошло с печально известным багом Y2K.
Ошибка Y2K возникла вследствие старого конструктивного решения. Когда первые программисты на COBOL прописывали в своём ПО даты, они использовали две цифры: 1971 год, например, обозначался как «71». Так получилось, потому что у машин в 60-х и 70-х было очень мало памяти. Избавление от двух символов являлось серьёзной экономией. «Все программы использовали память очень продуманно — был дорог каждый байт», — рассказывает мне Томас. Кроме того, кодеры 60-х и 70-х даже не мечтали о том, что их ПО будет использоваться тридцать лет спустя, когда приблизится 2000 год.
Но 2000 год надвигался, и даты из двух цифр превратились в огромную дилемму. В новом тысячелетии ПО на COBOL не будет знать, что означает «00» — 2000 или 1900. Если банк будет вычислять проценты по вкладу, сделанному в году «01», то он может ошибочно предположить, что вклад был сделан в 1901 году и перечислить клиенту проценты за 99 лет. Огромное количество банковских, розничных и зарплатных транзакций используют даты, поэтому необходимо было обновить миллиарды строк программ. Поскольку 2000 год приближался, банки вызвали своих «старичков» с пенсии, заплатили им за изучение кодовых баз, нахождение всех мест, где используются даты, и исправление ситуации.
«На подготовку к Y2K мы потратили два с половиной года», — посмеивается Томас. «Это одна из причин, почему многие из программистов наподобие меня так хорошо знают наши системы. Нам пришлось разбираться в каждой программе».
Но даже при всём этом банку Томаса не хватило времени на полное решение проблемы. В некоторых случаях банки и фирмы не меняли код, чтобы можно было использовать полную дату из четырёх цифр, например, «2016». Вместо этого они применяли хак: «правило сдвига». Они выбирали год далеко в будущем, например, 2045, и делали его новой точкой разрыва. Поэтому если COBOL встречает дату из двух цифр, которая больше 45, то он предполагает, что она относится к 1900-м, то есть, допустим, «87» — это 1987 год. А если он встречает число меньше 45, то предполагает, что это 2000-е, то есть «33» означает 2033 год.
По словам Томаса, это означает, что проблема Y2K для них решена не полностью. Они просто отложили её решение. Когда наступит 2045 год, у них снова может возникнуть паника. А это означает, что специалистам по COBOL нужно будет исправлять новый COBOL.
Если только они ещё будут живы… Крейг Бейли из программной фирмы Faircom работал с клиентами, помогая им мигрировать со старых систем COBOL. Фирма работала с каждым клиентом, находя старых уволившихся сотрудников, которые изначально писали эти системы, но время от времени ветераны в процессе работы умирали.
«Однажды в понедельник утром нам позвонили: „боже, проект встал — такой-то работник умер“», — рассказывает Бейли.
Банкам приходится надеяться, что старички продержатся как можно дольше, потому что сегодня не так много молодёжи, изучающей COBOL.
«Нам постоянно звонят компании: „у вас есть кто-нибудь с любым опытом в COBOL?“ Они в отчаянии», — рассказывает Мэрилин Цеппетелли, бывшая сотрудница IBM, работавшая на мейнфреймах компании, ныне — профессор Marist College.
Marist — один из немногих университетов, обучающих COBOL на постоянной основе. Многие учебные программы не рекламируют его. В научных кругах COBOL давно находится в униженном положении. Когда этот язык получил популярность в 70-х, элитные компьютерные учёные скорбели — они заявляли, что COBOL стимулирует к выбору ужасных стилей кодирования, которые выходили из моды. Одним из таких примеров является конструкция «GOTO»: COBOL позволяет приказать программе внезапно перескочить с одной строки на другую, допустим, со строки 899 на строку 217. Честно говоря, компьютерные учёные правы! Подобный стиль кодинга приводит к созданию неряшливих, неупорядоченных программ, которые иногда сложно читать (это так называемый «спагетти-код»), а языки после COBOL в основном отказались от GOTO. Как бы то ни было, обвинения прилипли к языку. Для людей, серьёзно стремившихся к прогрессу в программировании, COBOL был языком неудачников, застоем.
«Работа с COBOL вредит мозгу; следовательно, его преподавание должно считаться уголовным преступлением», — так написал в 1975 году знаменитый компьютерный учёный Эдсгер Дейкстра. COBOL был скорее языком «рабочего класса», вторжением «синих воротничков» в святыню кодинга. Кроме того, когда в 80-х появились недорогие настольные PC, они стали привлекательной новой территорией для запуска кода. Купить их мог любой, а для изучения COBOL требовался доступ к огромным мейнфреймам, которые в основном были только у банков или крупных розничных сетей. «Когда малые и средние машины получили настоящую популярность, вузы перенесли весь процесс обучения на эти платформы, а мейнфреймы остались немного в стороне», — говорит Цеппетелли. В наши дни смартфоны сделали COBOL ещё менее актуальным для студентов: «Он просто не выглядит таким же „сексуальным“, как некоторые другие платформы».
Из-за малого количества специалистов многие банки, правительства и розничные продавцы уже давно используют аутсорсинг работ на COBOL. Они содержат в своём штате небольшое ядро кодеров, знающих язык, а когда им требуется написать что-то новое, нанимаются фирмы, имеющие полки кодеров на COBOL, например, «COBOL Cowboys» Билла Хиншоу или индийские компании.
Некоторые фирмы, озабоченные тем, что в будущем будет слишком трудно найти адептов COBOL, пытаются переписать всю свою систему на новом языке. Почти всегда это является адской задачей: необходимо продумать каждый аспект задач, выполняемый сложным, создававшимся десятки лет программным обеспечением, и воссоздать каждый малейший шаг на новом языке. Три года назад New York Times переписал систему циркуляции газет с COBOL на Java; попытка оказалась успешной, однако на подтверждение того, что новая система способна на всё то, что и старая, потребовалось неожиданно много времени.
И им ещё повезло. Commonwealth Bank of Australia попробовал переписать ядро системы на новом языке: на проект потратили вдвое больше ожидаемого, 1 миллиард австралийских долларов. Специалист по мейнфреймам с большим опытом Лен Санталусия однажды работал с финансовой организацией DTCC над исследованием возможности перехода с COBOL на Java.
«У них было примерно семьдесят пять миллионов строк кода на COBOL, и они выяснили, что это будет им стоить так много, что на восполнение затрат потребуется, возможно, пара веков. Это было смехотворно. А ведь у них больше денег, чем у Бога».
Поэтому банки пожимают плечами и говорят: чёрт с ним. Если не сломано, то не надо чинить. Продолжим работать со старым COBOL. «Эти программы работали круглосуточно в режиме 24/7 в течение тридцати-сорока лет. Зачем нам их менять?», — говорит Томас.
В то же время банки пытаются мотивировать как можно больше людей изучать COBOL. «Ты получишь работу на всю жизнь», — смеётся Томас.
Однако проблема банков в том, что несмотря на стабильность их кода на COBOL, ожидания их клиентов могут оказаться не столь постоянными. Как вы могли догадаться, ситуация в финансовой отрасли быстро меняется. Транзакции всё больше происходят в приложениях типа Venmo, позволяющих людям отправлять деньги друзьям; сервисы наподобие Coinbase позволяют покупать криптовалюты; существуют новые приложения для кредитовая наподобие Tala и Upstart. Сегодня люди ожидают максимально простых способов управления своими деньгами через ПО.
И в этой области банки, у которых должно бы иметься постоянное преимущество в перемещении денег, испытывают трудности. Им сложно быстро создавать новые функции, потому что приходится иметь дело со «стеками технологий» юрского периода. Таково мнение Дэниса Райана, бывшего банкира, который сейчас работает директором по росту в ирландской фирме Showoff, занимающейся созданием приложений для финтеха. Эти старые бекэнды под управлением COBOL хранят данные в различных источниках — по словам Дэниса, «у них много ячеек». И, разумеется, со старым кодом опасно слишком много экспериментировать: «Начинаются проблемы с ресурсами, технологиями, эксплуатацией и рисками».
При этом стартап может делать всё, что угодно. У него нет старых систем. Они находятся в ситуации, которую программисты с любовью называют «с чистого листа». Вместо покупки мейнфреймов ценой сотни тысяч долларов для хранения и обработки данных они просто арендуют пространство в облачной системе типа Amazon. Они могут писать код на новом языке, поэтому способны нанять любого энергичного студента компьютерных наук. И им даже не обязательно создавать что-то самостоятельно: когда Showoff пишет новое финтех-приложение, для выполнения сложной задачи она может использовать готовый сервис, например, Stripe для обработки платежей, а не пытаться создать это ПО для себя.
«Это снимает с команды большую долю эксплуатационной нагрузки, поэтому она может масштабировать свой продукт», — говорит Райан, — «и работать над продуктом, не особо заботясь об инфраструктуре». Иными словами, им не нужно беспокоиться о COBOL.
Вероятно, COBOL никогда не умрёт. Однако это не мешает многим кодерам снова и снова прогнозировать его роковой конец. Первое предупреждение о том, что COBOL умер, появилось ещё до того, как он был выпущен.
К 1960 году комитет, изобретавшего COBOL, проработал всего лишь год, однако один из членов комитета, представитель RCA Говард Бромберг, беспокоился, что они движутся слишком медленно. Он утверждал, что если не выпустить COBOL быстрее, то мир бизнеса может уйти вперёд! Изготовители компьютеров выпустят собственные уникальные языки, а в бизнес-программировании возникнет ситуация вавилонского смешения языков.
Поэтому Бромберг «в сердцах» решил отправить послание главе комитета по COBOL Чарли Филлипсу, работавшему в министерстве обороны. Бромберг привёз могильный камень, увенчанный гранитным знаком «жертвенного агнца», с выгравированным словом «COBOL». («Что это за имя такое?», — спросили его в агентстве ритуальных услуг.)
Бромберг засунул могильный камень в ящик и отправил Филлипсу в Пентагон. «По всей отрасли ходят слухи, что COBOL умирает», — позже вспоминала Грейс Хоппер.
60 лет спустя этот могильный камень находится в Музее компьютерной истории в Маунтин-Вью, Калифорния, а COBOL продолжает править миром.
