Смерть кода. Каким будет программирование будущего?

В одной из многочисленных частей фильма «Крепкий орешек» случается цифровой апокалипсис. Хакеры получают доступ ко всему, чем государство управляет с помощью компьютеров, – светофорам, системам видеонаблюдения и снабжения электроэнергией, счетам социального обеспечения и так далее; начинается хаос, который приводит к многочисленным жертвам. Этот сценарий не так далек от реальности: 28 сентября «технический сбой» вызвал задержки рейсов одновременно в аэропортах по всему миру – в Австралии, Японии, Европе, США. Причиной стали неполадки в работе электронной системы, которой пользуются авиакомпании и аэропорты для регистрации пассажиров и багажа. К счастью, сбой быстро устранили, но его последствия могли бы быть трагическими.

Ночью с 10 на 11 апреля 2014 года весь штат Вашингтон на северо-западе США остался без экстренной службы спасения 911 на шесть часов. Все, кто звонил, слышали короткие гудки в трубке. Одна женщина, пытавшаяся вызвать полицию, потому что в ее дом забрался грабитель, набрала номер службы 37 раз и, так и не получив ответа, схватилась за нож, чтобы защищаться; злоумышленник бежал. Как выяснилось позднее, cбой случился потому, что один из серверов, через который проходили звонки, был запрограммирован на прием не более нескольких миллионов вызовов. Когда лимит был превышен, звонки просто перестали приниматься. Только утром программисты поняли, в чем была проблема и что для ее устранения требовалось всего лишь поменять одну цифру.

До недавнего времени критически важные системы контролировались механически или с участием человека и постоянно проходили проверки для выявления неполадок. Теперь они зависят от компьютера, а тот – от написанной для конкретных целей программы. И если описание электромеханического устройства занимало несколько страниц, то с программами все иначе: код может занимать десятки и сотни миллионов строк. Внесение изменений в программу стоит недорого, и потому она меняется постоянно – добавляются новые строчки, новые функции, новые возможности. Эта гибкость – не только чудо, но и проклятье, пишет журналист и программист Джеймс Сомерс в статье на Atlantic. По мнению некоторых специалистов, нам необходимо изменить программирование – и сделать это как можно скорее, пока не грянула катастрофа.

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

Программный код чересчур сложен, чтобы его представить, слишком «чужероден» для человеческого восприятия. Раньше мы могли видеть, как меняется мир вокруг нас – как дороги покрываются асфальтом, как растут этажи домов. Теперь, когда что-то меняется, мы этого не замечаем, – изменения происходят благодаря добавлению строчек в код. Мы давим на педаль газа в автомобиле и тот ускоряется, но между этими двумя событиями нет прямой механической связи – все происходит посредством компьютера, который решает, сколько воздуха дать двигателю. И вот это может быть по-настоящему опасно.

В сентябре 2007 года американка Джен Букаут вела свою Toyota Camry по шоссе, когда педали газа и тормоза перестали реагировать на ее действия. На скорости 80 км/ч женщина попыталась задействовать ручной тормоз, но это не помогло, и, проехав несколько десятков метров, автомобиль врезался в насыпь на обочине дороги. Пассажир погиб, а сама Букаут месяц пролежала без сознания. 10-месячное расследование ИТ-специалистов из NASA не смогло обнаружить причину неполадок и только спустя еще полтора года другая команда экспертов отыскали в компьютере машины спагетти-код, который был настолько запутан, что мельчайший сбой в памяти мог сделать автомобиль неуправляемым. Через 6 лет после аварии Toyota была признана виновной, суд обязал корпорацию выплатить пострадавшей женщине млн. Впоследствии автопроизводитель был вынужден отозвать 9 млн машин.

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

Работа программистов мало изменилась с 1980-х годов: чтобы создать или внести изменения в программу, нужно писать текст. Сегодня многие говорят о том, что такой статус-кво больше не отвечает реалиям. Мощность компьютеров растет в геометрической прогрессии вот уже 40 лет. Почему программирование должно оставаться прежним?

Один из тех, кто пытается придумать способ «вылечить» программирование – исследователь в сфере ИТ Брет Виктор. В 2007–2011 годах он был разработчиком интерфейса в Apple, а сейчас возглавляет лабораторию, исследующую будущее программирования в орагнизации Human Advancement Research Community (HARC). Виктор стал широко известным в узких кругах в 2012 году после своего выступления перед студентами-разработчиками в одном из отелей Монреаля. В той в лекции он рассказал о принципе, к которому пришел в ходе карьеры: «тот, кто что-то создает, должен иметь непосредственную связь с тем, что он создает». Программирование явно нарушало этот принцип, объявил Виктор – разработчик программы, уткнувшийся в строчки кода, оторван от реального результата своей работы. Тот, кто, к примеру, создает разные стили для текстового редактора не увидит, что он сделал, пока не распечатает текст на принтере. Не имея возможности предсказать, каким будет результат, программисту приходится представлять, как его код будет воспринят компьютером, то есть самому мысленно быть компьютером.

Подход к созданию программ больше не отвечает реалиям

Чтобы решить эту проблему, были созданы технологии WYSIWYG (от англ. What You See Is What You Get – «что видишь, то и получишь»), которые в режиме реального времени показывают программисту, как будет выглядеть плод его усилий в конечном итоге. Благодаря им стало возможным бросить один взгляд и понять, если где-то допущена ошибка – и сделать это мог любой. По мнению Виктора, все программирование должно работать схожим образом: люди, создающие автомобильный круиз-контроль или программу для изучения болезней, не должны видеть перед собой лишь бесконечные строчки текста.

В январе 2012-го Виктор обратился к собратьям по оружию. Он сделал несколько демо-версий того, насколько примитивными способами разные задачи (поиск ошибок в алгоритмах, компьютерная анимация) решаются сейчас и как еще они могли бы решаться. В числе прочего он сделал визуализацию всем известной игры Mario, где на одной стороне экрана была картинка из игры, а на другой редактор с кодом. К обычным переменным игры, которые может менять программист (скорость движения Марио, высота его прыжка, движение других персонажей), Виктор добавил шкалу времени. Благодаря ей в любой момент можно было посмотреть, каким будет движение Марио при заданных параметрах: если он подпрыгнет на такую-то высоту, где он окажется через секунду, две, три. Обычно, чтобы увидеть, что станет с персонажем после изменения тех или иных параметров, программист должен запустить игру; если требовались коррективы, процесс повторялся: меняешь переменные в коде, запускаешь, смотришь, что получилось, меняешь, запускаешь, смотришь. Теперь результат правок можно было увидеть в режиме реального времени. Несмотря на кажущуюся очевидность такого решения, аудитория ахнула.

Подход Виктора вдохновил его коллег, пишет Atlantic. Подобную визуализацию – на одной части экрана код, на другой – как выглядит конечный результат – начали разрабатывать для своих целей отдельные программисты. Один из таких проектов под названием Light Table в апреле 2012 года собрал на краудфандинговой платформе Kickstarter свыше 0 тысяч и стал сенсацией в кругах инженеров. Идея «видеть результат в режиме реального времени» начала распространяться, и вскоре нашла применение в продуктах Apple и Google.

Однако сам Виктор постепенно все более разочаровывался: его поняли не так. Разработчики программ получили инструменты для упрощения работы с кодом, но никто не заговорил о том, что, возможно, код вообще не должен существовать. В действительности, по мнению Виктора, его отрасли следовало до минимума сократить использование кода для решения тех задач, которые она решает сейчас. Сегодня, когда никто не строит, к примеру, автомобили собственными руками, программирование продолжает оставаться, в сущности, ручным трудом. Это не слишком большая проблема там, где код состоит из 10 тысяч строк, но когда их становится 30 млн, как в продуктах Airbus, или 100 млн, как в Tesla, дело сильно осложняется.

Французская компания Esterel Technologies (принадлежит американскому разработчику ANSYS) – один из пионеров нового подхода к программированию. Esterel еще в 1980-х работала с энергетической и авиакосмической сферами, которые обнаружили, что в разросшемся до невероятных размеров коде все сложнее отыскать ошибки, которых, в свою очередь, становилось все больше. Постепенно в компании пришли к пониманию, что традиционные языки программирования хороши для описания простых предсказуемых процедур (допустим, печать кассового чека), но в системах, предусматривающих ответ на большое количество событий, непременно возникнет путаница. А в энергетике и авиации (как и множестве других областей) путаница опасна для жизни.

У новых подходов к программированию проблема с имиджем

Подход Esterel, развитие которого заняло больше 10 лет, основывается на так называемом модельно-ориентированном дизайне (model-based design). В нем нет непосредственного написания кода – вместо этого разработчик создает «модель», которая описывает правила поведения будущей программы, а генерацией кода в соответствии с этими правилами занимается компьютер. Такая модель качественно отличается от традиционного программирования. В последнем ваша задача – взять сложные правила и перевести их в код; большинство энергии при этом уходит именно на перевод, а не на размышления о самих правилах. В модельно-ориентированном дизайне правила – это все, что у вас есть, поясняет Atlantic, поэтому вам ничего не остается, кроме как думать о них. Благодаря этому автор программы больше фокусируется на проблеме, которую ему надо решить. Сегодня программные продукты, построенные на этом принципе, используются для генерации кодов в авиакосмической и военной индустрии, в тяжелой промышленности, атомных электростанциях, медицине и других отраслях, где высока цена ошибки.

Еще один язык программирования, по духу схожий с модельным подходом – TLA⁺. Он также подразумевает, что система получает «требования» – спецификации – которые объясняют, что она должна делать, но не объясняют, каким образом. Прелесть TLA⁺ в том, что он позволяет провести исчерпывающее тестирование и обнаружить все ошибки, которые могут закрасться в традиционный код. Эта возможность TLA⁺-систем используется Microsoft, Intel, ESA (Европейское космическое агентство) и другими организациями, которые работают с очень сложными программными продуктами.

Несмотря на преимущества этих подходов, большая часть программных продуктов в мире использует прежние методы, констатирует Сомерс: инженеры описывают программистам свои требования к продукту, программисты пишут коды, чтобы система выполняла эти требования. И модельно-ориентированное проектирование, и TLA⁺ все еще встречаются относительно редко – как отмечает Виктор, отчасти из-за того, что большинству программистов нравится старый-добрый код – они привыкли к нему, они его понимают. В результате возникает парадоксальная ситуация, указывают сторонники модельного подхода: мы знаем, что по мере усложнения кода в нем появляется много ошибок, и знаем, как сделать сложные программы надежными. Но по какой-то причине мы решаем ничего не менять. Почему?

По мнению Лэмпорта, сложность с его TLA⁺ в том, что большинство программистов (и преподавателей программирования) не слишком хорошо владеют разделами математики, нужными для работы с ним, – математической логикой и теорией множеств. «Они думают, что все, что нужно, – это уметь писать код, – говорит ученый. – Идея, что над кодом существует какой-то более высокий уровень, который требует точности в мышлении и который возможен благодаря математике, оказывается полностью чуждой. Они никогда не учились этому». «В XV веке, – продолжает Лэмпорт, – люди строили соборы, не зная исчисления. Сегодня не думаю, что вы бы позволили кому-нибудь что-то строить без таких знаний. Я надеюсь, что через какое-то время тем, что не понимает этих простых вещей, не будет разрешаться писать программы».

Есть и другая точка зрения – что программисты попусту не знают, что математика способна помочь им справиться с запутанностью кода. Они не изучают TLA⁺, потому что думают, что это будет потерей времени и не видят, как он поможет им в решении каждодневных задач. Другими словами, как пишет Atlantic, у новых подходов к программированию есть этакая проблема с имиджем; на то, чтобы решить ее, вероятно, уйдет время.

В 2015 году двое специалистов в области безопасности продемонстрировали миру уязвимость компьютерной системы автомобиля самым наглядным из возможных способов: дистанционно взяли в свои руки контроль над Jeep Cherokee, несшимся по действующей автотрассе с водителем, который не мог ни повернуть руль, ни затормозить. По словам одного из хакеров, Криса Валасека, этот эпизод доказывает, что нам пора по-новому воспринимать код. Современные компьютерные системы стали слишком сложными, чтобы их разработчики могли проверить и исключить все, что может пойти не так.

Хотя многие из систем того же автомобиля были придуманы, чтобы сделать его безопаснее, они делают возможными такие ошибки, которые люди просто не могли вообразить и просчитать заранее. Возможно, то, о чем говорит Брет Виктор, – зримая связь между кодом программы и результатом – могло бы помочь в этой ситуации. «Программирование невидимо, это его фундаментальное свойство, – говорит Жерар Берри, специалист из французского института исследований в информатике INRIA. – Если у вас спустит покрышка, вы можете посмотреть на нее и увидеть, что она спустила. Когда у вас проблема в программе, вы смотрите на программу и не видите ничего».

Опубліковано на сайті: 2017-10-29