Вопрос: каким должно быть программное обеспечение виртуальной реальности? По форме оно должно кардинально отличаться от всех остальных программ. И вот почему.
Почти все программы проходят две стадии существования, как гусеница и бабочка. Первая стадия – написание программы или ее отладка, а вторая – запуск. Программисты гоняют код туда-сюда, отлаживают и снова запускают. Двухфазная природа программ практически универсальна. В данный момент программист либо пишет код какой-либо программы, либо наблюдает ее работу.
(Правда, что существуют «строительные игры», такие как Minecraft, в которых можно многое изменить, при этом не выпадая из игрового процесса, но обычно существует и предел изменений, которые можно внести подобным образом, поскольку для внесения изменений на более глубоком уровне необходимо переключиться в режим гусеницы.)
Но этот вариант абсолютно не подходит для виртуальной реальности. Виртуальная реальность работает не в каком-то внешнем ящике вроде смартфона. Вы находитесь внутри нее. Это вы сами.
Рассмотрим физический мир, скажем, вашу кухню. Когда вы сначала что-то готовите, а потом едите, правила реальности не обязаны меняться между этими действиями. Вы не находитесь в анабиозе, во время которого техники переконструируют ваши руки для того, чтобы они работали с ножом и вилкой, а не со сковородой и лопаткой, или, по крайней мере, у нас есть основания полагать, что этого не происходит. Вы просто сначала выполняете одно действие, а за ним другое внутри одного и того же мира и в одной и той же последовательности. Имеет ли смысл программному обеспечению виртуальной реальности быть таким же? Без модификаций?
[145]
Это было очевидно с самого начала. Так что мне и моим соотечественникам придется переосмыслить архитектуру наших программ, начиная с самых базовых основополагающих принципов.
Грейс
Главная роль в изобретении метода переключения режимов с одного на другой – между разработкой кода и запуском программы – принадлежит Грейс Хоппер, контр-адмиралу и специалисту в области информатики. Это она «кодифицировала» основные принципы создания компьютерных программ в современном мире.
«Исходный код» – это артефакт, который мы изменяем в режиме гусеницы, в процессе создания и исправления компьютерной программы. Этот код обычно состоит из английских слов и других символов и обычно читается как история о том, что должен сделать компьютер. Но это впечатление обманчиво. На самом деле код больше похож на правовой документ, в котором определяется точный план действий компьютера, которому он должен следовать, чтобы работать без сбоев.
Сбивающая с толку стилистика часто смущает студентов, пишущих свою первую программу. Несмотря на то, что исходный код похож на текст, дружественный человеку, он будет работать, только если писать его с безупречной точностью, присущей скорее роботам. Чтобы запрограммировать робота, надо самому стать роботом.
Совершенство идеи исходного кода было по большей части результатом огромной работы, проделанной Хоппер и ее женской командой математиков военного флота, которые изобрели или усовершенствовали языки программирования, компиляторы и другие технологии, необходимые для работы исходного кода «высокого уровня»
[146].
Самые знаменитые мужчины-математики съехались в Лос-Аламос, штат Нью-Мексико, чтобы найти способ сконструировать атомную бомбу, так что продолжение исследований в области информатики осталось за женщинами. Команда Хоппер проделала впечатляющую работу, даже создавая оптимизирующий компилятор, сильно опередив то время, когда он стал одним из главных вопросов в информатике.
Текстовый код требует того, чтобы одна конкретная абстракция стала ведущей, поскольку именно на ней будет основан лексикон. Таким образом, подход Хоппер оказался эффективным, абстракции фундаментальны, и их вряд ли удастся избежать.
Изобрази это
Большинство первых компьютеров, таких как те, которые работали в подвальной лаборатории Джона фон Неймана при Институте перспективных исследований в Принстоне, обладали примитивным дисплеем: подсветка каждого бита, так что можно было наблюдать, как они переключаются в тот или иной момент
[147]. Можно было наблюдать, как работает программа
[148]. Я люблю думать о программировании именно так – как о конкретном процессе, подразумевающем изменение состояния материалов; как о переключающихся битах.
Понятно, что если бы инженеры решили попытаться получить больше пользы от этой подсветки, то могли бы появиться и другие способы компьютерного программирования. Только представьте: невнятная примитивная визуальная последовательность переключающихся битов может становиться с каждым разом все лучше до того момента, когда вы сможете рисовать и перерисовывать биты на экране, так что программу можно переделать, даже когда она запущена.
Как это сработает? Как узнать смысл или подтекст нарисованного? Как узнать, какой бит что делает?
Как не дать компьютеру выйти из строя? Как добиться достаточно совершенного нарисованного изображения? Напомню, даже из-за самой незначительной ошибки компьютер может выйти из строя.
Биты не могут появляться в виде ничего не значащей путаницы. Их нужно организовать в виде осмысленных изображений. Этот метод рисования получится выдающимся (простите за каламбур) и крайне ограниченным.
Прошу вас, оставьте на минуту сомнения насчет того, будет ли это практично, целесообразно или хотя бы возможно.
Думаю, что если бы программирование развивалось по этому сценарию, то современное общество было бы совершенно другим. Основную причину сперва будет сложновато понять, но я к ней еще вернусь: когда вы можете видеть биты и управлять ими, вы воспринимаете компьютеры на более физическом и приземленном уровне.
