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