«Второй по ценности актив в США — после нефти — это 240 миллиардов строк кода на 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 вдоль и поперек, ушли на пенсию. Они покинули стены банка, как и Томас. И мало кто из молодых программистов заинтересован в изучении пыльного компьютерного языка 50-летней давности. Они гораздо больше увлечены новыми оживленными областями, такими как бурно развивающаяся в Торонто индустрия искусственного интеллекта. Они изучают новые современные языки программирования.
Поэтому этот крупный банк по-прежнему зависит от таких людей, как Томас, которому 73 года, которые не только поддерживают работу, но и добавляют новые функции и улучшения.
Переживет ли его COBOL?
«Возможно».
Этот банк не единственный. Программы на COBOL — некоторые из них написаны так давно, что цветное телевидение еще не было в ходу — повсюду в нашей повседневной жизни.
Задумайтесь: Более 80% личных операций в финансовых учреждениях США проводятся с использованием COBOL. Полностью 95% времени, когда вы проводите по своей банковской карте, где-то на заднем плане работает COBOL. Bank of New York Mellon в 2012 году обнаружил, что у него 112500 отдельных программ COBOL, составляющих почти 350 миллионов строк; вероятно, это типично для большинства крупных финансовых учреждений. Когда ваш начальник выдает вам зарплату, есть вероятность, что она была рассчитана с помощью COBOL. Если вы инвестируете, ваши биржевые торги тоже проходят на нем. Так же как и здравоохранение: Страховые компании в США используют «механизмы вынесения решений» — программное обеспечение, которое определяет, сколько врач или фармацевтическая компания получит за услугу — которые были написаны на 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.) Хуже того, производители компьютеров часто придумывали свои собственные специальные языки для своих ЭВМ. Если вы написали отличный код для машины, он не мог работать на компьютере другой компании.
Грейс Хоппер и команда разработчиков COBOL.
Новое поколение амбициозных программистов считало это безумием. Одной из них была Грейс Хоппер, контр-адмирал военно-морского флота США, работавшая на раннем экспериментальном компьютере и обладавшая ярким характером. (Именно она популяризировала фразу: „Проще попросить прощения, чем спрашивать разрешения“). Хоппер считала, что языки программирования должны быть более похожи на английский, чтобы их было легче изучать и читать. В 1955 году она разработала язык под названием „FLOW-MATIC“, который был нацелен именно на это; чтобы переместить число из позиции A в позицию D, например, вы просто напишите „TRANSFER A TO D“.
В 1959 году программист по имени Мэри Хоуз решила, что ее отрасли необходимо разработать язык, который был бы так же прост в написании, как FLOW-MATIC, и который мог бы работать на любой машине. Она собрала группу экспертов — в том числе многих из зарождающейся индустрии бизнес-компьютеров — для создания языка, работая вместе с Министерством обороны. Цель заключалась в том, чтобы создать язык, который мог бы прочитать и понять средний менеджер компании, даже если он не был обучен программированию.
В результате этой десятилетней работы, в которую внесли большой вклад многие женщины-суперзвезды, такие как пионер компьютерных наук Джин Саммет, был создан язык, очень похожий на FLOW-MATIC, который был прост для восприятия. Например, чтобы сложить два числа, можно было написать „ADD Num1, Num2 GIVING Result“. Чтобы выполнить вычисление три раза, вы напишете „PERFORM 3 TIMES“.
»Трудно переоценить значение COBOL", — говорит Мар Хикс, доцент истории в Иллинойском технологическом институте и автор книги " Программируемое неравенство". «Он делал нечто совершенно исключительное в вычислительной технике. Он заполнял эту нишу, которая оставалась незаполненной в первые годы развития вычислительной техники. И это изменило способ, посредством которого вы могли бы подумать о написании программ».
Это изменило и тех, кто мог писать на нем. COBOL демократизировал кодирование; компании могли брать обычных людей и обучать их быть востребованными программистами COBOL за несколько месяцев, а за год или два они становились экспертами. Это было крайне важно, учитывая, что компаниям отчаянно требовалось больше теплых рук для написания программного обеспечения.
«Вы могли подбирать людей на улице», — говорит Джон Пайк, британский программист, изучавший COBOL в 1960-х годах, — «и в целом учить их, как это делается».
Другая особенность COBOL заключалась в том, что он был быстрым. Он был разработан специально для быстрого выполнения огромного количества «транзакций». Если вы работаете в розничной сети, вам нужно подсчитывать продажи и пересчитывать запасы каждый вечер. И у вас не так много времени на это — возможно, пара часов вечером, после окончания рабочего дня, пока ваш компьютерный персонал работает допоздна.
Так же и с банками: днем они лихорадочно принимают транзакции, запросы от клиентов на ввод и вывод денег со счетов. Ночью у них есть несколько часов, чтобы свести баланс всех этих операций. Если вы задавались вопросом, почему чек, который вы положили на депозит, не проходит некоторое время, то это отчасти потому, что оба банка должны выполнять свои огромные задания на COBOL после ухода дневного персонала. В Citibank код Теплицкого проходил через огромный комплекс с 248 мэйнфреймами.
«У вас есть шести-, восьмичасовое окно, когда вы должны сделать, извините за выражение, хренову тучу работы — вы должны провести все транзакции в определенном порядке», — говорит он мне. «Нужно большое, большое железо, чтобы прогнать миллиард транзакций через шестичасовое пакетное окно. Это просто ужас».
COBOL был оптимизирован именно для такой задачи: обработки гигантских транзакций. Компьютерные языки часто имеют своего рода когнитивный или творческий уклон; каждый из них был создан с учетом конкретного типа задач. Python отлично подходит для науки о данных и искусственного интеллекта; Fortran был создан для отображения математических формул в коде; JavaScript был создан, чтобы помочь программистам сделать веб-сайты функциональными.
COBOL? Он был создан для работы на мейнфреймах, которые сами по себе были созданы специально для обработки миллиардов транзакций, чтения и записи потоков данных в быстром темпе. Это было похоже на высокооктановое топливо, разработанное специально для спортивного автомобиля. С годами «компиляторы» COBOL — программное обеспечение, которое берет английский синтаксис компьютерного кода и преобразует его в единицы и нули, которые может выполнить компьютерный чип, — совершенствовались все больше и больше, так что «скомпилированный код» COBOL стал исключительно быстрым. Это означает, что отчасти COBOL лежит в основе многих жизненно важных вещей, которые мы делаем, потому что он действительно очень хорош в этом.
«У них было 50 лет, чтобы сделать это как следует», — замечает Билл Хиншоу, руководитель COBOL Cowboys, агентства, предоставляющего COBOL-программистов.
Возраст этих COBOL-систем, как ни странно, на самом деле работает в их пользу. Поскольку они старые, их неустанно отлаживали. Когда программа только написана, в ней неизбежно возникают проблемы. Иногда это опечатка, неправильная команда; в других случаях пользователь делает то, чего программист никак не ожидал, и все рушится. Когда вы получаете новое приложение, если оно глючное и склонное к сбоям, то вот почему: создатели отправили его в мир с множеством таких мелких недочетов. На выявление всех проблем могут уйти дни, недели или годы.
А программы на COBOL, которые управляют миром? У кодеров и пользователей были десятилетия, чтобы обнаружить все проблемы и устранить их.
Адриана Штерн (на этот раз не псевдоним!), еще один кодер, с которым я беседовал, работавшая в крупных канадских банках, начала свою карьеру в 80-х годах, когда в системах еще устранялись некоторые странные ошибки. Однажды она обнаружила, что определенный банковский терминал в Квебеке посылает системе буквы с акцентом — а первоначальный программист никак не ожидал, что такое произойдет.
«Поэтому, когда система пыталась их интерпретировать, она тормозила», — рассказывает она. В другом случае другая программа на языке COBOL постоянно падала, и в конце концов она поняла, что это происходит потому, что в имени нового клиента была одна кавычка, которую программа случайно приняла за инструкцию «конец набора данных», что привело к остановке кода.
Штерн проработала в банках 30 лет, и, по ее данным, 85% ее работы составляло не написание новых смелых функций для банка, а «техническое обслуживание». Считайте это своего рода цифровой сантехникой, устранением утечек, чтобы все работало постепенно все более и более гладко.
«Это была тяжелая работа — ты горишь свечой с двух концов», — сказала она мне.
Именно поэтому системы на языке COBOL сейчас так надежны. Их отлаживали больше, чем практически любой код на планете". Шикарное новое приложение в стиле TikTok может быть запущено и пользоваться огромной популярностью даже при наличии большого количества ошибок. Если количество отметок «нравится» на вашем последнем сообщении немного ошибочно, ничего страшного. В отличие от этого, если крупный розничный торговец неправильно подсчитает свои запасы или банк вдруг не сможет отправить деньги? Это вызывает финансовый хаос в масштабах страны.
«Весь ВВП мира находится в движении в [банковской] сети в любой момент времени», — как отмечает Теплицкий. «Каждый день банк переворачивает вдвое больше своих активов, выходя и входя. У клирингового банка, скажем, в Нью-Йорке, это может быть больше… Так что огромное количество денег находится в движении в сети и в больших внутренних системах, обеспечивающих ее работу. Они не могут выйти из строя! Если они выйдут из строя, миру придет конец. Мир закончится».
COBOL не просто быстрый; он также «стабильный, стабильный, стабильный», как сказал мне Томас. Один из процессов, который он разработал, каждый месяц берет файл с примерно 2,4 миллионами государственных пенсий и кладет нужные суммы на банковские счета людей. «Мы проверяем их и перечисляем за 11 минут. За 20 лет ни разу не было сбоя».
Эта идея — что старый код может быть не только хорошим, но и в решающих аспектах превосходить более новый — противоречит многим мифам Кремниевой долины. Стартапы, финансируемые венчурным капиталом, обычно рассказывают о блестящем и новом. Основатели не хвастаются тем, насколько старая у них кодовая база. Совсем наоборот: они хвастаются тем, что их код является передовым, написанным за всю ночь 21-летними гениями с горящими глазами. Но, как скажет вам почти каждый программист, чем новее и свежее написанное программное обеспечение, тем больше вероятность того, что оно будет кишеть ошибками.
Наглядный пример сказанному можно наблюдать во время пандемии. В первые дни Covid-19 предприятия массово закрывались. Уволенные работники кинулись в Интернет, чтобы подать заявление на получение пособия по безработице, а веб-сайты правительств многих штатов рухнули под нагрузкой. В Нью-Джерси губернатор заявил прессе, что их системы COBOL отчаянно нуждаются в помощи, чтобы справиться с новыми требованиями. «Буквально, у нас есть системы, которым более 40 лет», — отметил он.
Но технологи, работавшие за кулисами над устранением проблем, знали, что проблема не в COBOL, вычисляющем цифры. Это старое оборудование работало нормально. Нет, сбой произошел в более новых вещах — программах, обеспечивающих работу самого веб-сайта.
«То, что вышло из строя, было веб-приложением между мэйнфреймом и внешним миром. Именно оно и развалилось», — говорит Марианна Беллотти, программист и писательница, которая много лет работала с правительственными системами и наблюдала за работой системы Нью-Джерси. Но признать, что «о, наши веб-системы сломались», слишком стыдно, как отмечает историк Хикс.
Беллотти видела, как то же самое происходило с другими государственными учреждениями, например, с налоговой службой. Однажды ее позвали помочь с веб-приложением Налогового управления, которое не работало. Когда они провели расследование, то обнаружили, что, действительно, проблема была в более новых программах, «в этом куске плохо написанного кода на Java». Мейнфрейм, работающий на COBOL, напротив, мчался как Ferrari.
«Мейнфреймы, — говорит она, — реагировали в течение миллисекунд».
Однако «стабильность» и старость могут создать парадокс — проклятие успеха. Потому что, когда код работает хорошо и никому не нужно его проверять, в конце концов, люди уходят. Они перестают смотреть на него, перестают его проверять. А это значит, что они перестают понимать, как именно он работает.
Конечно, они знают, что код работает. Эй, он работает каждый день, обрабатывая миллионы транзакций в мгновение ока! Но никто не знает, почему и как. COBOL стал непостижимой загадкой, демоном, который послушно выполняет свои задачи, но так, что никто не может понять.
Это может стать большой проблемой, когда спустя годы вы действительно захотите что-то изменить или добавить новую функцию.
Дэйв Гуарино видел это воочию. Он разработчик программного обеспечения, много лет проработавший в Code For America, некоммерческой организации, которая берет талантливых программистов и помогает правительствам обновлять свои древние сервисы. Несколько лет назад он помогал писать новое веб-приложение, чтобы калифорнийцам было проще подавать заявки на получение талонов на питание. Веб-приложение, так сказать, плавало поверх старых программных систем Калифорнии; пользователи взаимодействовали с приложением, а оно передавало их запросы десятилетиями устаревшему коду, работающему на мэйнфреймах Калифорнии.
И вот тут-то и возникла проблема. В какой-то момент его команда захотела создать способ для получателей продовольственных талонов заказать встречу с государственным чиновником. В старых калифорнийских системах уже был раздел, который мог принять подобный запрос. Но в поле, где нужно было ввести «Когда вы можете встретиться?», старая система позволяла ввести только 40 символов — и она не позволяла использовать дефисы, поэтому нельзя было использовать краткую форму, например, «Пн-Ср», чтобы показать, что вы свободны с понедельника по среду.
Какая боль, подумал Гуарино. Поэтому он встретился с человеком, который управлял этой старой программной системой. «К сожалению, да, это реальные ограничения», — сказал ему тот. И это была проблема языка COBOL; он был написан несколько десятилетий назад. «Так что же вы можете сделать?
Можете ли вы сделать поле больше или что-то еще?» спросил Гуарино. «А он прямо так и сказал: „Нет! Мы ничего не можем сделать“. Тот код на COBOL никто и никогда не тронет. У государства не было достаточно денег, чтобы оплатить огромные затраты времени сотрудников, которые потребовались бы для погружения в эту кодовую базу.
Кроме того, они, скорее всего, боялись, что если попытаются изменить что-то критически важное, то сломают это. В этом заключается еще один парадокс успеха COBOL. Поскольку он быстр и стабилен, на протяжении многих лет и десятилетий правительства и банки все больше полагались на эти старые системы. Поэтому даже если вы хотите их изменить, пытаться это сделать слишком опасно. В банке, в котором работала Штерн, можно было потерять волосы от стресса, вызванного необходимостью возиться с действительно древним, критически важным кодом.
»Исправлять что-то было очень рискованно, потому что можно было повредить то, что уже работало", — говорит она мне. Поэтому чаще всего вместо того, чтобы интенсивно переписывать старый код, они просто добавляли небольшие новые кусочки кода, исправляя все по краям. «Люди продолжали добавлять маленькие кусочки и кусочки, и это стало выглядеть как маленький Франкенштейн», — смеется она. Что, конечно, только делало систему потенциально более непостижимой и запутанной для последующих поколений.
Очень, очень редко, однако, некоторые проектные решения, принятые десятилетия назад, оказываются настолько ужасными, что банкам и компаниям приходится — внезапно, в панике — погружаться в систему и реконструировать подлинно старый COBOL. Так случилось с печально известным «багом Y2K».
Ошибка Y2K возникла в результате старого проектного решения. Когда программисты первых версий COBOL записывали даты в свои программы, они использовали две цифры: 1971 год, например, был «71». Это было связано с тем, что машины 60-х и 70-х годов имели очень мало места в памяти.
Удаление двух знаков было большой проблемой. «Все программы очень бережно относились к памяти — каждый байт был дорог», — говорит мне Томас. Кроме того, программисты 60-х и 70-х годов и представить себе не могли, что их программы будут по-прежнему использоваться 30 лет спустя, когда наступит 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-х годах появились более дешевые настольные ПК, они стали новым захватывающим местом для выполнения кода. Любой мог иметь такой ПК на своем столе; изучение COBOL требовало доступа к огромному компьютеру-мейнфрейму, которые были в основном только в банках или крупных розничных сетях. «Когда малые и средние машины стали действительно популярны, [университеты] перевели все свое обучение на эти платформы, и мейнфреймы как бы отошли на второй план», — отмечает Цеппетелли. В наши дни смартфоны сделали COBOL еще менее актуальным для студентов: «Он просто не кажется таким же привлекательным, как некоторые другие платформы».
В связи с небольшим числом прибывающих специалистов многие банки, государственные учреждения и предприятия розничной торговли уже давно стали полагаться на стороннюю COBOL-работу. Они держат в штате небольшое ядро кодеров, знающих язык, а когда им нужно написать что-то новое, нанимают фирмы, имеющие в штате несколько кодеров COBOL, например «COBOL Cowboys» Билла Хиншоу, или фирмы в Индии.
Некоторые фирмы, опасаясь, что в ближайшие годы будет слишком трудно найти программистов на COBOL, пытаются переписать всю свою систему на современных языках. Это почти всегда адская задача: вы должны продумать каждую вещь, которую делает ваше сложное, десятилетиями создававшееся программное обеспечение, и воссоздать каждый крошечный шаг на новом языке. Три года назад New York Times переписала свою систему тиражирования газет на языке COBOL на Java; это было вполне успешно, но заняло больше времени, чем ожидалось, из-за «сложной» задачи — по словам кодеров — убедиться, что новая система делает то же самое, что и старая.
И это были счастливчики. Банк Содружества Австралии попытался переписать основную систему на новом языке; проект обошелся вдвое дороже, чем они ожидали, — 1 миллиард австралийских долларов. Лен Санталусия, давний эксперт по мэйнфреймам, однажды работал с финансовым учреждением DTCC, изучая возможность перевода их COBOL на Java.
«У них, вероятно, около семидесяти пяти миллионов строк кода COBOL, — рассказывает он мне, — и они выяснили, что это обойдется им так дорого, что на восстановление уйдет, возможно, пара жизней. Это было просто смешно. А у них денег больше, чем у Бога».
Так что банки пожимают плечами и думают: «К черту. Если ничего не сломалось, не надо чинить. Пусть работает старый COBOL. „Эти программы работали изо дня в день, из дня в день, 24 часа в сутки, 7 дней в неделю в течение 30 и 40 лет. Так зачем нам их менять?“ — говорит Томас.
А пока банки просто стараются поощрять как можно больше людей изучать COBOL. „У вас будет работа на всю жизнь“, — смеется Томас.
Проблема для банков, однако, заключается в том, что, хотя их COBOL может быть стабильным, ожидания их клиентов не стабильны. Как вы, наверное, понимаете, картина финансовой индустрии быстро меняется. Транзакции все чаще осуществляются через приложения типа Venmo, которые позволяют людям переводить деньги друзьям; сервисы вроде Coinbase позволяют людям покупать криптовалюту; появляются новые приложения для кредитования, такие как Tala и Upstart. Люди теперь ожидают все более простых способов управления своими деньгами с помощью программного обеспечения.
Именно здесь банкам, которые должны унаследовать преимущество в перемещении денег, приходится сложнее. Им трудно быстро внедрять новые интересные функции, потому что им приходится иметь дело со своими „технологическими наборами“ юрского периода, отмечает Денис Райан, бывший банкир, который сейчас является директором по развитию Showoff, ирландской фирмы, создающей финтех-приложения. Эти старые бэкенды, работающие на COBOL, хранят данные разрозненными кусками — »у них много барьеров", — отмечает он. И, конечно, опасно слишком много переписывать старый код: «У вас есть проблемы с ресурсами, технические проблемы, операционные проблемы, проблемы с рисками».
Но стартап может делать все, что захочет. Здесь нет старых систем. Они находятся в ситуации, которую программисты любовно называют «зеленым полем». Вместо того чтобы покупать мейнфреймы за сотни тысяч долларов для хранения и обработки данных, они просто арендуют место в «облачной» системе, как у Amazon. Они могут писать код на новых языках, поэтому они могут нанять практически любого молодого студента, желающего изучать компьютерные науки. И им даже не нужно создавать все самим: Когда Showoff разрабатывает новое финтех-приложение, он может использовать существующий сервис для решения сложной задачи — например, использовать Stripe для обработки платежей — вместо того, чтобы пытаться создать это программное обеспечение самостоятельно.
«Это снимает с команды довольно много трудностей, связанных с операционной деятельностью, так что они могут масштабироваться, — отмечает он, — и работать над продуктом, не беспокоясь об инфраструктуре». Другими словами, им не нужно беспокоиться о COBOL.
Проблема банков заключается в том, что, хотя их COBOL остается стабильным, ожидания их клиентов таковыми не являются.
COBOL, вероятно, никогда не умрет. Но это не помешало многим программистам снова и снова предсказывать, что его ждет гибель. Действительно, первое предупреждение о том, что COBOL мертв, прозвучало еще до того, как язык был выпущен.
В 1960 году комитет, разрабатывавший COBOL, работал всего один год, но один из его членов, руководитель RCA Говард Бромберг, беспокоился, что они продвигаются слишком медленно. По его мнению, если не выпустить COBOL быстрее, деловой мир пойдет дальше! Производители компьютеров выпустят свои собственные уникальные языки, и деловое программирование превратится в вавилонское смешение языков.
Поэтому Бромберг решил «в порыве гнева» послать сообщение главе комитета COBOL Чарли Филлипсу, который работал в Министерстве обороны. Бромберг купил надгробие, которое было увенчано гранитной иконой «жертвенного агнца», и на нем было высечено слово «COBOL». («Что это за имя?» — спросил его изготовитель надгробия).
Затем Бромберг положил надгробие в ящик и отправил его Филлипсу в Пентагон. «По всей отрасли ходили слухи, что COBOL умирает», — вспоминала позже Грейс Хоппер.
60 лет спустя надгробие стоит в Музее компьютерной истории в Маунтин-Вью, Калифорния, а 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 вдоль и поперек, ушли на пенсию. Они покинули стены банка, как и Томас. И мало кто из молодых программистов заинтересован в изучении пыльного компьютерного языка 50-летней давности. Они гораздо больше увлечены новыми оживленными областями, такими как бурно развивающаяся в Торонто индустрия искусственного интеллекта. Они изучают новые современные языки программирования.
Поэтому этот крупный банк по-прежнему зависит от таких людей, как Томас, которому 73 года, которые не только поддерживают работу, но и добавляют новые функции и улучшения.
Переживет ли его COBOL?
«Возможно».
COBOL демократизировал кодирование; компании могли бы брать обычных людей и обучать их быть полезными программистами COBOL за несколько месяцев.
Этот банк не единственный. Программы на COBOL — некоторые из них написаны так давно, что цветное телевидение еще не было в ходу — повсюду в нашей повседневной жизни.
Задумайтесь: Более 80% личных операций в финансовых учреждениях США проводятся с использованием COBOL. Полностью 95% времени, когда вы проводите по своей банковской карте, где-то на заднем плане работает COBOL. Bank of New York Mellon в 2012 году обнаружил, что у него 112500 отдельных программ COBOL, составляющих почти 350 миллионов строк; вероятно, это типично для большинства крупных финансовых учреждений. Когда ваш начальник выдает вам зарплату, есть вероятность, что она была рассчитана с помощью COBOL. Если вы инвестируете, ваши биржевые торги тоже проходят на нем. Так же как и здравоохранение: Страховые компании в США используют «механизмы вынесения решений» — программное обеспечение, которое определяет, сколько врач или фармацевтическая компания получит за услугу — которые были написаны на 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.) Хуже того, производители компьютеров часто придумывали свои собственные специальные языки для своих ЭВМ. Если вы написали отличный код для машины, он не мог работать на компьютере другой компании.
Грейс Хоппер и команда разработчиков COBOL.
Новое поколение амбициозных программистов считало это безумием. Одной из них была Грейс Хоппер, контр-адмирал военно-морского флота США, работавшая на раннем экспериментальном компьютере и обладавшая ярким характером. (Именно она популяризировала фразу: „Проще попросить прощения, чем спрашивать разрешения“). Хоппер считала, что языки программирования должны быть более похожи на английский, чтобы их было легче изучать и читать. В 1955 году она разработала язык под названием „FLOW-MATIC“, который был нацелен именно на это; чтобы переместить число из позиции A в позицию D, например, вы просто напишите „TRANSFER A TO D“.
В 1959 году программист по имени Мэри Хоуз решила, что ее отрасли необходимо разработать язык, который был бы так же прост в написании, как FLOW-MATIC, и который мог бы работать на любой машине. Она собрала группу экспертов — в том числе многих из зарождающейся индустрии бизнес-компьютеров — для создания языка, работая вместе с Министерством обороны. Цель заключалась в том, чтобы создать язык, который мог бы прочитать и понять средний менеджер компании, даже если он не был обучен программированию.
В результате этой десятилетней работы, в которую внесли большой вклад многие женщины-суперзвезды, такие как пионер компьютерных наук Джин Саммет, был создан язык, очень похожий на FLOW-MATIC, который был прост для восприятия. Например, чтобы сложить два числа, можно было написать „ADD Num1, Num2 GIVING Result“. Чтобы выполнить вычисление три раза, вы напишете „PERFORM 3 TIMES“.
»Трудно переоценить значение COBOL", — говорит Мар Хикс, доцент истории в Иллинойском технологическом институте и автор книги " Программируемое неравенство". «Он делал нечто совершенно исключительное в вычислительной технике. Он заполнял эту нишу, которая оставалась незаполненной в первые годы развития вычислительной техники. И это изменило способ, посредством которого вы могли бы подумать о написании программ».
Это изменило и тех, кто мог писать на нем. COBOL демократизировал кодирование; компании могли брать обычных людей и обучать их быть востребованными программистами COBOL за несколько месяцев, а за год или два они становились экспертами. Это было крайне важно, учитывая, что компаниям отчаянно требовалось больше теплых рук для написания программного обеспечения.
«Вы могли подбирать людей на улице», — говорит Джон Пайк, британский программист, изучавший COBOL в 1960-х годах, — «и в целом учить их, как это делается».
То, что старый код может быть не только хорошим, но и в решающих аспектах превосходить новый, противоречит многим мифам Кремниевой долины.
Другая особенность COBOL заключалась в том, что он был быстрым. Он был разработан специально для быстрого выполнения огромного количества «транзакций». Если вы работаете в розничной сети, вам нужно подсчитывать продажи и пересчитывать запасы каждый вечер. И у вас не так много времени на это — возможно, пара часов вечером, после окончания рабочего дня, пока ваш компьютерный персонал работает допоздна.
Так же и с банками: днем они лихорадочно принимают транзакции, запросы от клиентов на ввод и вывод денег со счетов. Ночью у них есть несколько часов, чтобы свести баланс всех этих операций. Если вы задавались вопросом, почему чек, который вы положили на депозит, не проходит некоторое время, то это отчасти потому, что оба банка должны выполнять свои огромные задания на COBOL после ухода дневного персонала. В Citibank код Теплицкого проходил через огромный комплекс с 248 мэйнфреймами.
«У вас есть шести-, восьмичасовое окно, когда вы должны сделать, извините за выражение, хренову тучу работы — вы должны провести все транзакции в определенном порядке», — говорит он мне. «Нужно большое, большое железо, чтобы прогнать миллиард транзакций через шестичасовое пакетное окно. Это просто ужас».
COBOL был оптимизирован именно для такой задачи: обработки гигантских транзакций. Компьютерные языки часто имеют своего рода когнитивный или творческий уклон; каждый из них был создан с учетом конкретного типа задач. Python отлично подходит для науки о данных и искусственного интеллекта; Fortran был создан для отображения математических формул в коде; JavaScript был создан, чтобы помочь программистам сделать веб-сайты функциональными.
COBOL? Он был создан для работы на мейнфреймах, которые сами по себе были созданы специально для обработки миллиардов транзакций, чтения и записи потоков данных в быстром темпе. Это было похоже на высокооктановое топливо, разработанное специально для спортивного автомобиля. С годами «компиляторы» COBOL — программное обеспечение, которое берет английский синтаксис компьютерного кода и преобразует его в единицы и нули, которые может выполнить компьютерный чип, — совершенствовались все больше и больше, так что «скомпилированный код» COBOL стал исключительно быстрым. Это означает, что отчасти COBOL лежит в основе многих жизненно важных вещей, которые мы делаем, потому что он действительно очень хорош в этом.
«У них было 50 лет, чтобы сделать это как следует», — замечает Билл Хиншоу, руководитель COBOL Cowboys, агентства, предоставляющего COBOL-программистов.
Возраст этих COBOL-систем, как ни странно, на самом деле работает в их пользу. Поскольку они старые, их неустанно отлаживали. Когда программа только написана, в ней неизбежно возникают проблемы. Иногда это опечатка, неправильная команда; в других случаях пользователь делает то, чего программист никак не ожидал, и все рушится. Когда вы получаете новое приложение, если оно глючное и склонное к сбоям, то вот почему: создатели отправили его в мир с множеством таких мелких недочетов. На выявление всех проблем могут уйти дни, недели или годы.
А программы на COBOL, которые управляют миром? У кодеров и пользователей были десятилетия, чтобы обнаружить все проблемы и устранить их.
Адриана Штерн (на этот раз не псевдоним!), еще один кодер, с которым я беседовал, работавшая в крупных канадских банках, начала свою карьеру в 80-х годах, когда в системах еще устранялись некоторые странные ошибки. Однажды она обнаружила, что определенный банковский терминал в Квебеке посылает системе буквы с акцентом — а первоначальный программист никак не ожидал, что такое произойдет.
«Поэтому, когда система пыталась их интерпретировать, она тормозила», — рассказывает она. В другом случае другая программа на языке COBOL постоянно падала, и в конце концов она поняла, что это происходит потому, что в имени нового клиента была одна кавычка, которую программа случайно приняла за инструкцию «конец набора данных», что привело к остановке кода.
Штерн проработала в банках 30 лет, и, по ее данным, 85% ее работы составляло не написание новых смелых функций для банка, а «техническое обслуживание». Считайте это своего рода цифровой сантехникой, устранением утечек, чтобы все работало постепенно все более и более гладко.
«Это была тяжелая работа — ты горишь свечой с двух концов», — сказала она мне.
Именно поэтому системы на языке COBOL сейчас так надежны. Их отлаживали больше, чем практически любой код на планете". Шикарное новое приложение в стиле TikTok может быть запущено и пользоваться огромной популярностью даже при наличии большого количества ошибок. Если количество отметок «нравится» на вашем последнем сообщении немного ошибочно, ничего страшного. В отличие от этого, если крупный розничный торговец неправильно подсчитает свои запасы или банк вдруг не сможет отправить деньги? Это вызывает финансовый хаос в масштабах страны.
«Весь ВВП мира находится в движении в [банковской] сети в любой момент времени», — как отмечает Теплицкий. «Каждый день банк переворачивает вдвое больше своих активов, выходя и входя. У клирингового банка, скажем, в Нью-Йорке, это может быть больше… Так что огромное количество денег находится в движении в сети и в больших внутренних системах, обеспечивающих ее работу. Они не могут выйти из строя! Если они выйдут из строя, миру придет конец. Мир закончится».
COBOL не просто быстрый; он также «стабильный, стабильный, стабильный», как сказал мне Томас. Один из процессов, который он разработал, каждый месяц берет файл с примерно 2,4 миллионами государственных пенсий и кладет нужные суммы на банковские счета людей. «Мы проверяем их и перечисляем за 11 минут. За 20 лет ни разу не было сбоя».
Эта идея — что старый код может быть не только хорошим, но и в решающих аспектах превосходить более новый — противоречит многим мифам Кремниевой долины. Стартапы, финансируемые венчурным капиталом, обычно рассказывают о блестящем и новом. Основатели не хвастаются тем, насколько старая у них кодовая база. Совсем наоборот: они хвастаются тем, что их код является передовым, написанным за всю ночь 21-летними гениями с горящими глазами. Но, как скажет вам почти каждый программист, чем новее и свежее написанное программное обеспечение, тем больше вероятность того, что оно будет кишеть ошибками.
Наглядный пример сказанному можно наблюдать во время пандемии. В первые дни Covid-19 предприятия массово закрывались. Уволенные работники кинулись в Интернет, чтобы подать заявление на получение пособия по безработице, а веб-сайты правительств многих штатов рухнули под нагрузкой. В Нью-Джерси губернатор заявил прессе, что их системы COBOL отчаянно нуждаются в помощи, чтобы справиться с новыми требованиями. «Буквально, у нас есть системы, которым более 40 лет», — отметил он.
Но технологи, работавшие за кулисами над устранением проблем, знали, что проблема не в COBOL, вычисляющем цифры. Это старое оборудование работало нормально. Нет, сбой произошел в более новых вещах — программах, обеспечивающих работу самого веб-сайта.
«То, что вышло из строя, было веб-приложением между мэйнфреймом и внешним миром. Именно оно и развалилось», — говорит Марианна Беллотти, программист и писательница, которая много лет работала с правительственными системами и наблюдала за работой системы Нью-Джерси. Но признать, что «о, наши веб-системы сломались», слишком стыдно, как отмечает историк Хикс.
Беллотти видела, как то же самое происходило с другими государственными учреждениями, например, с налоговой службой. Однажды ее позвали помочь с веб-приложением Налогового управления, которое не работало. Когда они провели расследование, то обнаружили, что, действительно, проблема была в более новых программах, «в этом куске плохо написанного кода на Java». Мейнфрейм, работающий на COBOL, напротив, мчался как Ferrari.
«Мейнфреймы, — говорит она, — реагировали в течение миллисекунд».
Однако «стабильность» и старость могут создать парадокс — проклятие успеха. Потому что, когда код работает хорошо и никому не нужно его проверять, в конце концов, люди уходят. Они перестают смотреть на него, перестают его проверять. А это значит, что они перестают понимать, как именно он работает.
Конечно, они знают, что код работает. Эй, он работает каждый день, обрабатывая миллионы транзакций в мгновение ока! Но никто не знает, почему и как. COBOL стал непостижимой загадкой, демоном, который послушно выполняет свои задачи, но так, что никто не может понять.
Это может стать большой проблемой, когда спустя годы вы действительно захотите что-то изменить или добавить новую функцию.
Дэйв Гуарино видел это воочию. Он разработчик программного обеспечения, много лет проработавший в Code For America, некоммерческой организации, которая берет талантливых программистов и помогает правительствам обновлять свои древние сервисы. Несколько лет назад он помогал писать новое веб-приложение, чтобы калифорнийцам было проще подавать заявки на получение талонов на питание. Веб-приложение, так сказать, плавало поверх старых программных систем Калифорнии; пользователи взаимодействовали с приложением, а оно передавало их запросы десятилетиями устаревшему коду, работающему на мэйнфреймах Калифорнии.
И вот тут-то и возникла проблема. В какой-то момент его команда захотела создать способ для получателей продовольственных талонов заказать встречу с государственным чиновником. В старых калифорнийских системах уже был раздел, который мог принять подобный запрос. Но в поле, где нужно было ввести «Когда вы можете встретиться?», старая система позволяла ввести только 40 символов — и она не позволяла использовать дефисы, поэтому нельзя было использовать краткую форму, например, «Пн-Ср», чтобы показать, что вы свободны с понедельника по среду.
Какая боль, подумал Гуарино. Поэтому он встретился с человеком, который управлял этой старой программной системой. «К сожалению, да, это реальные ограничения», — сказал ему тот. И это была проблема языка COBOL; он был написан несколько десятилетий назад. «Так что же вы можете сделать?
Можете ли вы сделать поле больше или что-то еще?» спросил Гуарино. «А он прямо так и сказал: „Нет! Мы ничего не можем сделать“. Тот код на COBOL никто и никогда не тронет. У государства не было достаточно денег, чтобы оплатить огромные затраты времени сотрудников, которые потребовались бы для погружения в эту кодовую базу.
Кроме того, они, скорее всего, боялись, что если попытаются изменить что-то критически важное, то сломают это. В этом заключается еще один парадокс успеха COBOL. Поскольку он быстр и стабилен, на протяжении многих лет и десятилетий правительства и банки все больше полагались на эти старые системы. Поэтому даже если вы хотите их изменить, пытаться это сделать слишком опасно. В банке, в котором работала Штерн, можно было потерять волосы от стресса, вызванного необходимостью возиться с действительно древним, критически важным кодом.
»Исправлять что-то было очень рискованно, потому что можно было повредить то, что уже работало", — говорит она мне. Поэтому чаще всего вместо того, чтобы интенсивно переписывать старый код, они просто добавляли небольшие новые кусочки кода, исправляя все по краям. «Люди продолжали добавлять маленькие кусочки и кусочки, и это стало выглядеть как маленький Франкенштейн», — смеется она. Что, конечно, только делало систему потенциально более непостижимой и запутанной для последующих поколений.
Очень, очень редко, однако, некоторые проектные решения, принятые десятилетия назад, оказываются настолько ужасными, что банкам и компаниям приходится — внезапно, в панике — погружаться в систему и реконструировать подлинно старый COBOL. Так случилось с печально известным «багом Y2K».
Ошибка Y2K возникла в результате старого проектного решения. Когда программисты первых версий COBOL записывали даты в свои программы, они использовали две цифры: 1971 год, например, был «71». Это было связано с тем, что машины 60-х и 70-х годов имели очень мало места в памяти.
Удаление двух знаков было большой проблемой. «Все программы очень бережно относились к памяти — каждый байт был дорог», — говорит мне Томас. Кроме того, программисты 60-х и 70-х годов и представить себе не могли, что их программы будут по-прежнему использоваться 30 лет спустя, когда наступит 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.
Нам постоянно звонят из компаний и спрашивают: „У вас есть кто-нибудь, кто умеет работать с COBOL?“. Они в отчаянии», — говорит Мэрилин Зеппетелли, бывший сотрудник IBM, работавший на их мэйнфреймах, а теперь преподающий в Marist College.
Marist — один из немногих университетов, где регулярно преподают COBOL. Многие программы по компьютерным наукам не преподают или, конечно, не рекламируют его. Действительно, академические круги давно отвергают COBOL. Когда в 70-х годах этот язык получил широкое распространение, элитные ученые-компьютерщики пренебрежительно отнеслись к нему, утверждая, что COBOL поощряет ужасные стили кодирования, которые выходят из моды. Одним из примеров был оператор «GOTO»: COBOL позволяет вам сказать программе внезапно перескочить с одной строки на другую, скажем, со строки 899 на строку 217. По правде говоря, компьютерщики были правы! Такой тип кодирования приводит к неорганизованным программам, которые трудно читать («спагетти-код», как они его называют), и языки, появившиеся после COBOL, в основном отказались от GOTO. В любом случае, клевета осталась. Для людей, серьезно настроенных на расширение границ вычислительной техники, COBOL был языком неудачников, каким-то захолустьем.
«Использование COBOL калечит мозг; поэтому его преподавание должно рассматриваться как уголовное преступление», — писал в 1975 году известный компьютерщик Эдсгер Дейкстра. COBOL был скорее языком рабочего класса, вторжением «синих воротничков» в священство кодирования. К тому же, когда в 80-х годах появились более дешевые настольные ПК, они стали новым захватывающим местом для выполнения кода. Любой мог иметь такой ПК на своем столе; изучение COBOL требовало доступа к огромному компьютеру-мейнфрейму, которые были в основном только в банках или крупных розничных сетях. «Когда малые и средние машины стали действительно популярны, [университеты] перевели все свое обучение на эти платформы, и мейнфреймы как бы отошли на второй план», — отмечает Цеппетелли. В наши дни смартфоны сделали COBOL еще менее актуальным для студентов: «Он просто не кажется таким же привлекательным, как некоторые другие платформы».
В связи с небольшим числом прибывающих специалистов многие банки, государственные учреждения и предприятия розничной торговли уже давно стали полагаться на стороннюю COBOL-работу. Они держат в штате небольшое ядро кодеров, знающих язык, а когда им нужно написать что-то новое, нанимают фирмы, имеющие в штате несколько кодеров COBOL, например «COBOL Cowboys» Билла Хиншоу, или фирмы в Индии.
Некоторые фирмы, опасаясь, что в ближайшие годы будет слишком трудно найти программистов на COBOL, пытаются переписать всю свою систему на современных языках. Это почти всегда адская задача: вы должны продумать каждую вещь, которую делает ваше сложное, десятилетиями создававшееся программное обеспечение, и воссоздать каждый крошечный шаг на новом языке. Три года назад New York Times переписала свою систему тиражирования газет на языке COBOL на Java; это было вполне успешно, но заняло больше времени, чем ожидалось, из-за «сложной» задачи — по словам кодеров — убедиться, что новая система делает то же самое, что и старая.
И это были счастливчики. Банк Содружества Австралии попытался переписать основную систему на новом языке; проект обошелся вдвое дороже, чем они ожидали, — 1 миллиард австралийских долларов. Лен Санталусия, давний эксперт по мэйнфреймам, однажды работал с финансовым учреждением DTCC, изучая возможность перевода их COBOL на Java.
«У них, вероятно, около семидесяти пяти миллионов строк кода COBOL, — рассказывает он мне, — и они выяснили, что это обойдется им так дорого, что на восстановление уйдет, возможно, пара жизней. Это было просто смешно. А у них денег больше, чем у Бога».
Так что банки пожимают плечами и думают: «К черту. Если ничего не сломалось, не надо чинить. Пусть работает старый COBOL. „Эти программы работали изо дня в день, из дня в день, 24 часа в сутки, 7 дней в неделю в течение 30 и 40 лет. Так зачем нам их менять?“ — говорит Томас.
А пока банки просто стараются поощрять как можно больше людей изучать COBOL. „У вас будет работа на всю жизнь“, — смеется Томас.
Проблема для банков, однако, заключается в том, что, хотя их COBOL может быть стабильным, ожидания их клиентов не стабильны. Как вы, наверное, понимаете, картина финансовой индустрии быстро меняется. Транзакции все чаще осуществляются через приложения типа Venmo, которые позволяют людям переводить деньги друзьям; сервисы вроде Coinbase позволяют людям покупать криптовалюту; появляются новые приложения для кредитования, такие как Tala и Upstart. Люди теперь ожидают все более простых способов управления своими деньгами с помощью программного обеспечения.
Именно здесь банкам, которые должны унаследовать преимущество в перемещении денег, приходится сложнее. Им трудно быстро внедрять новые интересные функции, потому что им приходится иметь дело со своими „технологическими наборами“ юрского периода, отмечает Денис Райан, бывший банкир, который сейчас является директором по развитию Showoff, ирландской фирмы, создающей финтех-приложения. Эти старые бэкенды, работающие на COBOL, хранят данные разрозненными кусками — »у них много барьеров", — отмечает он. И, конечно, опасно слишком много переписывать старый код: «У вас есть проблемы с ресурсами, технические проблемы, операционные проблемы, проблемы с рисками».
Но стартап может делать все, что захочет. Здесь нет старых систем. Они находятся в ситуации, которую программисты любовно называют «зеленым полем». Вместо того чтобы покупать мейнфреймы за сотни тысяч долларов для хранения и обработки данных, они просто арендуют место в «облачной» системе, как у Amazon. Они могут писать код на новых языках, поэтому они могут нанять практически любого молодого студента, желающего изучать компьютерные науки. И им даже не нужно создавать все самим: Когда Showoff разрабатывает новое финтех-приложение, он может использовать существующий сервис для решения сложной задачи — например, использовать Stripe для обработки платежей — вместо того, чтобы пытаться создать это программное обеспечение самостоятельно.
«Это снимает с команды довольно много трудностей, связанных с операционной деятельностью, так что они могут масштабироваться, — отмечает он, — и работать над продуктом, не беспокоясь об инфраструктуре». Другими словами, им не нужно беспокоиться о COBOL.
Проблема банков заключается в том, что, хотя их COBOL остается стабильным, ожидания их клиентов таковыми не являются.
COBOL, вероятно, никогда не умрет. Но это не помешало многим программистам снова и снова предсказывать, что его ждет гибель. Действительно, первое предупреждение о том, что COBOL мертв, прозвучало еще до того, как язык был выпущен.
В 1960 году комитет, разрабатывавший COBOL, работал всего один год, но один из его членов, руководитель RCA Говард Бромберг, беспокоился, что они продвигаются слишком медленно. По его мнению, если не выпустить COBOL быстрее, деловой мир пойдет дальше! Производители компьютеров выпустят свои собственные уникальные языки, и деловое программирование превратится в вавилонское смешение языков.
Поэтому Бромберг решил «в порыве гнева» послать сообщение главе комитета COBOL Чарли Филлипсу, который работал в Министерстве обороны. Бромберг купил надгробие, которое было увенчано гранитной иконой «жертвенного агнца», и на нем было высечено слово «COBOL». («Что это за имя?» — спросил его изготовитель надгробия).
Затем Бромберг положил надгробие в ящик и отправил его Филлипсу в Пентагон. «По всей отрасли ходили слухи, что COBOL умирает», — вспоминала позже Грейс Хоппер.
60 лет спустя надгробие стоит в Музее компьютерной истории в Маунтин-Вью, Калифорния, а COBOL по-прежнему управляет миром.
- Первая в России серийная система управления двухтопливным двигателем с функциональным разделением контроллеров
- В современном автомобиле строк кода больше чем…
- Бесплатные онлайн-курсы по Automotive, Aerospace, робототехнике и инженерии (50+)
- McKinsey: переосмысляем софт и архитектуру электроники в automotive
Вакансии
НПП ИТЭЛМА всегда рада молодым специалистам, выпускникам автомобильных, технических вузов, а также физико-математических факультетов любых других высших учебных заведений.
У вас будет возможность разрабатывать софт разного уровня, тестировать, запускать в производство и видеть в действии готовые автомобильные изделия, к созданию которых вы приложили руку.
В компании организован специальный испытательный центр, дающий возможность проводить исследования в области управления ДВС, в том числе и в составе автомобиля. Испытательная лаборатория включает моторные боксы, барабанные стенды, температурную и климатическую установки, вибрационный стенд, камеру соляного тумана, рентгеновскую установку и другое специализированное оборудование.
Если вам интересно попробовать свои силы в решении тех задач, которые у нас есть, пишите в личку.
У вас будет возможность разрабатывать софт разного уровня, тестировать, запускать в производство и видеть в действии готовые автомобильные изделия, к созданию которых вы приложили руку.
В компании организован специальный испытательный центр, дающий возможность проводить исследования в области управления ДВС, в том числе и в составе автомобиля. Испытательная лаборатория включает моторные боксы, барабанные стенды, температурную и климатическую установки, вибрационный стенд, камеру соляного тумана, рентгеновскую установку и другое специализированное оборудование.
Если вам интересно попробовать свои силы в решении тех задач, которые у нас есть, пишите в личку.
- Старший инженер программист
- Системный аналитик
- Руководитель группы калибровки
- Ведущий инженер-испытатель
- Инженер по требованиям
- Инженер по электромагнитной совместимости
- Системный аналитик
- Старший инженер-программист ДВС
О компании ИТЭЛМА
Мы большая компания-разработчик automotive компонентов. В компании трудится около 2500 сотрудников, в том числе 650 инженеров.
Мы, пожалуй, самый сильный в России центр компетенций по разработке автомобильной электроники. Сейчас активно растем и открыли много вакансий (порядка 30, в том числе в регионах), таких как инженер-программист, инженер-конструктор, ведущий инженер-разработчик (DSP-программист) и др.
У нас много интересных задач от автопроизводителей и концернов, двигающих индустрию. Если хотите расти, как специалист, и учиться у лучших, будем рады видеть вас в нашей команде. Также мы готовы делиться экспертизой, самым важным что происходит в automotive. Задавайте нам любые вопросы, ответим, пообсуждаем.
Мы, пожалуй, самый сильный в России центр компетенций по разработке автомобильной электроники. Сейчас активно растем и открыли много вакансий (порядка 30, в том числе в регионах), таких как инженер-программист, инженер-конструктор, ведущий инженер-разработчик (DSP-программист) и др.
У нас много интересных задач от автопроизводителей и концернов, двигающих индустрию. Если хотите расти, как специалист, и учиться у лучших, будем рады видеть вас в нашей команде. Также мы готовы делиться экспертизой, самым важным что происходит в automotive. Задавайте нам любые вопросы, ответим, пообсуждаем.
Список полезных публикаций на Хабре
- Бесплатные онлайн-курсы по Automotive, Aerospace, робототехнике и инженерии (50+)
- [Прогноз] Транспорт будущего (краткосрочный, среднесрочный, долгосрочный горизонты)
- Лучшие материалы по взлому автомобилей с DEF CON 2018-2019 года
- [Прогноз] Motornet — сеть обмена данными для роботизированного транспорта
- Компании потратили 16 миллиардов долларов на беспилотные автомобили, чтобы захватить рынок в 8 триллионов
- Камеры или лазеры
- Автономные автомобили на open source
- McKinsey: переосмысляем софт и архитектуру электроники в automotive
- Очередная война операционок уже идет под капотом автомобилей
- Программный код в автомобиле
- В современном автомобиле строк кода больше чем…
Only registered users can participate in poll. Log in, please.
Вы умеете программировать на COBOL?
2.02% Да, написал много программ10
4.03% Да, только учился20
91.94% нет456
2.02% прочее10
496 users voted. 50 users abstained.
