зные редакторы должны указывать на одну и ту же комбинацию битов, одну и ту же программу, и разными способами представлять ее программисту.
Поскольку фенотропное программирование основано на преобразовании между уровнем человеческого ощущения и уровнем битов, программисты меньше привязаны к тем или иным абстракциям. Один редактор может преобразовать несколько битов, которые работают в качестве запущенной программы, таким образом, что они выглядят как лабиринт, а другой редактор может преобразовать эти же самые биты так, чтобы они выглядели как генеалогическое древо.
Каждый традиционный язык программирования на основе исходного кода жестко привязан к своим абстракциям, таким как функции Фортрана, списки LISP или объекты Smalltalk. Все эти примеры относятся к тому времени, когда я сам учился программированию. Вам не обязательно знать, что это были за языки. Смысл в том, что все это концепции, которые позволяли построить мост между намерением человека и переключающимися битами внутри компьютера, и каждый из них блистал в одних обстоятельствах и крайне бледно выглядел в других.
Фенотропное программирование – это подход, поддерживающий разные концепции подобного толка в разное время, но в пределах одного устройства. Абстракции можно смешивать и совмещать, чтобы они удовлетворяли потребностям, возникшим в тот или иной момент.
Вариативность
Это не значит, что абстракции морально устареют.
Представьте себе, что вы живете в будущем, где к программированию виртуальной реальности используется тот подход, который я и мои друзья изучали много лет назад, то есть фенотропный. В этом случае станет возможно выполнить различные действия, вследствие чего биты, которыми эти действия управляют, изменятся, и виртуальный мир, в котором вы находитесь, начнет функционировать иначе.
Какого рода действия это будут? Будете ли вы отдавать команды с имитации командного пульта, похожего на пульт звездолета Enterprise? А может, тянуть за цепи, как в средневековом подземелье, или танцевать как падающий лист? А может, редактировать текст, который выглядит как исходный код, изобретенный Грейс Хоппер, и который в наше время используют все? Редактор может принимать абсолютно любой внешний вид.
Но внешний вид необходим. Не придерживаясь определенной точки зрения и определенного образа мышления, вы ничего не добьетесь. Но на фундаментальном уровне нет никаких ограничений на использование любого внешнего вида в тот или иной момент.
Во вселенной Грейс, где царит нефенотропный исходный код, каждый язык программирования предполагает, что некоторые абстрактные объекты не просто реальны, но еще и обязательны, вечны и неизбежны при использовании этого языка. Я уже упоминал классические функции Фортрана и объекты Smalltalk, но могу так же легко добавить сюда и ботов облачного программного обеспечения, модных на момент написания этой книги.
Каждый из этих объектов хорош и полезен в определенное время, но ни один из них не обязан становиться неизбежным. Они не реальны, если «реальность» означает то, что нельзя отбросить. Мне причиняет беспокойство то, что они кажутся реальными.
Разными абстракциями можно заменять любые привычные, не считая причуд истории. (Вопрос, возможно ли когда-нибудь пересмотреть широко используемые абстракции программного обеспечения, остается открытым. В книге «Вы не гаджет» («You Are Not a Gadget») я рассматриваю способы и идеи, которые выражаются в том, чтобы программное обеспечение смогло стать «закрытым» из-за различных вредоносных «сетевых эффектов», но относительно этой книги я полагаю, что у нас есть время для изменений и надежда на них.)
Единственное, что остается фундаментальным и нерушимым, по-настоящему реальным, пока вы используете компьютер, – это вы и комбинации битов, запущенные и работающие внутри компьютера. Абстракции, связывающие два этих реальных явления, нереальны.
Можно ли вообразить, что архитектура компьютера может выражать эту философию? Что, если существует способ загружать и скачивать разные редакторы с разным внешним видом, чтобы представить вам разные комбинации битов так, чтобы вы могли их понять и изменять их в разное время разными способами?
Фенотропный пробный запуск
В начале 1980-х я и мои друзья создали несколько поколений фенотропных экспериментов. Самый первый носил название Mandala, за ним последовал Grasp, а затем Embrace. (Предполагалось, что Grasp будет перчаткой, а Embrace – костюмом, который, как в прямом, так и в переносном смысле, охватывает все тело.) Прототипы некоторых важнейших категорий приложений для виртуальной реальности были созданы при помощи бескодового программного обеспечения от VPL.
«Бескодовое» отнюдь не метафора; мы в буквальном смысле не использовали код. То есть мы использовали традиционный код и средства разработки, чтобы система работала в принципе, но виртуальные миры функционировали не за счет кода, а лишь за счет комбинаций битов, которые, повторюсь, можно было изменять при помощи редакторов, которые были с ними связаны.
Редакторы на фундаментальном уровне отличаются от обычных инструментов, используемых для разработки программного обеспечения, таких как компиляторы и интерпретаторы.
Компиляторы – это стадия куколки в схеме превращений традиционного программного обеспечения на основе кода: вы редактируете текстовый файл, исходный код, а затем, лишь пройдя этап компиляции, можете увидеть, что делает код после того, как в него внесли изменения. А затем вы переключаетесь туда и обратно, отлаживая его[149].
Фенотропная альтернатива может показаться совершенно экзотической идеей молодому поколению специалистов в области информатики, выросших в тени Хоппер. Идея кода практически повсеместно стала синонимичной программированию, но это совершенно не обязательно.
Может ли фенотропный редактор имитировать традиционный код? Иными словами, могли ли мы редактировать комбинации битов, преобразуя их в изображения на экране, которые выглядели как привычный высокоуровневый текстовый язык? Во многих случаях могли, что означало имитацию кода. Фенотропный редактор мог располагаться так, чтобы выглядеть как текст, даже несмотря на то, что его действие определялось более общей графической конструкцией. Такой редактор мог делать то же, что и компилятор, но в виде живой визуальной отладки[150].
Среди редакторов мы особо выделяли полюбившиеся нам своим видом, то есть определенной визуальной подачей кода, и часто придерживались потокового принципа. Поток данных обычно выглядит как провода, соединяющие между собой модули. Но этот принцип не был основополагающим. Мы могли пользоваться текстовыми редакторами по образцу созданных Грейс Хоппер или другими редакторами.
Опыт программирования быстро стал более ориентированным на импровизацию и больше походил на попытку сыграть джаз на трубе и чертить математические диаграммы.
Пятьдесят второе определение VR: способ использования компьютеров, который предполагает отказ от самой идеи кода.
К сожалению, впоследствии нам пришлось просить покупателей продуктов виртуальной реальности вести разработку на обычном экране, а не внутри виртуального мира. Основная причина этого заключалась в том, что обычные мониторы стоили дешевле, чем шлемы виртуальной реальности. Больше людей могло работать одновременно, находясь при этом в разных местах.
Мне до сих пор больно думать об этом! Еще больнее наблюдать, как при возрождении виртуальной реальности ее разработка до сих пор ведется с использованием традиционных языков программирования на традиционных экранах. Это напоминает попытку выучить иностранный язык по книге, никогда не говоря с его носителями.
Наши редакторы на традиционных мониторах по внешнему виду немного напоминают MAX, средство визуального программирования, которое используется в наши дни для создания экспериментальной компьютерной музыки и анимации[151].
По крайней мере, мы заглянули в альтернативное будущее, которое, надеюсь, изучат более тщательно в последующие годы.
Масштаб
Масштабирование – основной импульс информатики. Это означает надежду специалистов в области информатики на то, что наша работа приобретет неограниченный простор и сложность.
Как получить все более и более масштабные фенотропные структуры? Фенотропный редактор преобразует машинные биты в пользовательский интерфейс таким образом, чтобы человек мог изменять биты. Но может ли один редактор вносить изменения в другой редактор? Можно ли получить целые башни редакторов, изменяющих редакторы, целые паутины из них, гигантские грибницы?
Разумеется, можно. Но в этом случае нужно ли придерживаться неких абстрактных принципов, которые обязан соблюдать каждый редактор, чтобы в него было возможно внести изменения с помощью других редакторов? Не помешает ли это достижению цели избежать обязательного использования тех или иных абстракций?
Невероятно, но нет! Фенотропному редактору не обязательно использовать одни и те же абстракции, чтобы им можно было управлять при помощи других редакторов.
Причина заключается в том, что каждый редактор – это пользовательский интерфейс, пригодный к использованию человеком. Таким образом, редакторы могут имитировать человека, чтобы вносить изменения в другие редакторы. Редактор может интерпретировать пользовательский интерфейс и использовать его на условиях этого интерфейса.
Например, редактор для низкоуровневого доступа к библиотеке математической обработки данных мог выглядеть как калькулятор. Можно было пользоваться им напрямую или через другой редактор, имитирующий взаимодействие системы с пользователем.
Программа-календарь, которой необходимо производить арифметические действия для расчета даты будущей встречи, имитировала нажатие кнопок на имитации калькулятора.