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

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

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

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

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

Программирование явно этот принцип нарушало, сказал Виктор: уткнувшийся в строчки кода разработчик программы от реального результата своей работы оторван. Тот, кто, например, создает для текстового редактора разные стили, не сможет увидеть, что он сделал, пока текст не распечатает на принтере. Не имея возможности предсказать, каким результат будет, программист вынужден представлять, как его код воспримет компьютером, то есть мысленно самому быть компьютером.

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

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

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

Такой подход Виктора вдохновил его коллег, пишет Atlantic. Такую визуализацию – на одной части экрана код, на другой – как выглядит конечный результат – стали разрабатывать для своих целей отдельные программисты. Один из таких проектов под названием LightTable в апреле 2012 года собрал на краудфандинговой платформе Kickstarter свыше $200 тысяч и стал сенсацией в кругах инженеров. Идея «видеть результат в режиме реального времени» начала распространяться и вскоре нашла применение в продуктах Apple и Google.
Однако сам Виктор постепенно все более разочаровывался: его поняли не так. Разработчики программ получили инструменты для упрощения работы с кодом, но никто не заговорил о том, что, возможно, код вообще не должен существовать. В действительности, по мнению Виктора, его отрасли следовало до минимума сократить использование кода для решения тех задач, которые она решает сейчас. Сегодня, когда никто не строит, к примеру, автомобили собственными руками, программирование продолжает оставаться, в сущности, ручным трудом. Это не слишком большая проблема там, где код состоит из 10 тысяч строк, но когда их становится 30 млн, как в продуктах Airbus, или 100 млн, как в Tesla, дело сильно осложняется.
Французская компания EsterelTechnologies (принадлежит американскому разработчику ANSYS) – один из пионеров нового подхода к программированию. Esterel еще в 1980-х работала с энергетической и авиакосмической сферами, которые обнаружили, что в разросшемся до невероятных размеров коде все сложнее отыскать ошибки, которых, в свою очередь, становилось все больше. Постепенно в компании пришли к пониманию, что традиционные языки программирования хороши для описания простых предсказуемых процедур (допустим, печать кассового чека), но в системах, предусматривающих ответ на большое количество событий, непременно возникнет путаница. А в энергетике и авиации (как и множестве других областей) путаница опасна для жизни.

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

Подход Esterel, развитие которого заняло больше 10 лет, основывается на так называемом модельно-ориентированном дизайне (model-baseddesign). В нем нет непосредственного написания кода – вместо этого разработчик создает «модель», которая описывает правила поведения будущей программы, а генерацией кода в соответствии с этими правилами занимается компьютер. Такая модель качественно отличается от традиционного программирования. В последнем ваша задача – взять сложные правила и перевести их в код; большинство энергии при этом уходит именно на перевод, а не на размышления о самих правилах. В модельно-ориентированном дизайне правила – это все, что у вас есть, поясняет Atlantic, поэтому вам ничего не остается, кроме как думать о них. Благодаря этому автор программы больше фокусируется на проблеме, которую ему надо решить. Сегодня программные продукты, построенные на этом принципе, используются для генерации кодов в авиакосмической и военной индустрии, в тяжелой промышленности, атомных электростанциях, медицине и других отраслях, где высока цена ошибки.
Еще один язык программирования, по духу схожий с модельным подходом, – TLA+. Он также подразумевает, что система получает «требования» – спецификации, – которые объясняют, что она должна делать, но не объясняют, каким образом. Прелесть TLA+ в том, что он позволяет провести исчерпывающее тестирование и обнаружить все ошибки, которые могут закрасться в традиционный код. Эта возможность TLA+-систем используется Microsoft, Intel, ESA (Европейское космическое агентство) и другими организациями, которые работают с очень сложными программными продуктами.
Несмотря на преимущества этих подходов, большая часть программных продуктов в мире использует прежние методы, констатирует Сомерс: инженеры описывают программистам свои требования к продукту, программисты пишут коды, чтобы система выполняла эти требования. И модельно-ориентированное проектирование, и TLA+ все еще встречаются относительно редко – как отмечает Виктор, отчасти из-за того, что большинству программистов нравится старый добрый код – они привыкли к нему, они его понимают. В результате возникает парадоксальная ситуация, указывают сторонники модельного подхода: мы знаем, что по мере усложнения кода в нем появляется много ошибок, и знаем, как сделать сложные программы надежными. Но по какой-то причине мы решаем ничего не менять. Почему?

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

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

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