Среди редакторов мы особо выделяли полюбившиеся нам своим видом, то есть определенной визуальной подачей кода, и часто придерживались потокового принципа. Поток данных обычно выглядит как провода, соединяющие между собой модули. Но этот принцип не был основополагающим. Мы могли пользоваться текстовыми редакторами по образцу созданных Грейс Хоппер или другими редакторами.
Опыт программирования быстро стал более ориентированным на импровизацию и больше походил на попытку сыграть джаз на трубе и чертить математические диаграммы.
Пятьдесят второе определение VR: способ использования компьютеров, который предполагает отказ от самой идеи кода.
К сожалению, впоследствии нам пришлось просить покупателей продуктов виртуальной реальности вести разработку на обычном экране, а не внутри виртуального мира. Основная причина этого заключалась в том, что обычные мониторы стоили дешевле, чем шлемы виртуальной реальности. Больше людей могло работать одновременно, находясь при этом в разных местах.
Мне до сих пор больно думать об этом! Еще больнее наблюдать, как при возрождении виртуальной реальности ее разработка до сих пор ведется с использованием традиционных языков программирования на традиционных экранах. Это напоминает попытку выучить иностранный язык по книге, никогда не говоря с его носителями.
Наши редакторы на традиционных мониторах по внешнему виду немного напоминают MAX, средство визуального программирования, которое используется в наши дни для создания экспериментальной компьютерной музыки и анимации[151].
По крайней мере, мы заглянули в альтернативное будущее, которое, надеюсь, изучат более тщательно в последующие годы.
Масштаб
Масштабирование – основной импульс информатики. Это означает надежду специалистов в области информатики на то, что наша работа приобретет неограниченный простор и сложность.
Как получить все более и более масштабные фенотропные структуры? Фенотропный редактор преобразует машинные биты в пользовательский интерфейс таким образом, чтобы человек мог изменять биты. Но может ли один редактор вносить изменения в другой редактор? Можно ли получить целые башни редакторов, изменяющих редакторы, целые паутины из них, гигантские грибницы?
Разумеется, можно. Но в этом случае нужно ли придерживаться неких абстрактных принципов, которые обязан соблюдать каждый редактор, чтобы в него было возможно внести изменения с помощью других редакторов? Не помешает ли это достижению цели избежать обязательного использования тех или иных абстракций?
Невероятно, но нет! Фенотропному редактору не обязательно использовать одни и те же абстракции, чтобы им можно было управлять при помощи других редакторов.
Причина заключается в том, что каждый редактор – это пользовательский интерфейс, пригодный к использованию человеком. Таким образом, редакторы могут имитировать человека, чтобы вносить изменения в другие редакторы. Редактор может интерпретировать пользовательский интерфейс и использовать его на условиях этого интерфейса.
Например, редактор для низкоуровневого доступа к библиотеке математической обработки данных мог выглядеть как калькулятор. Можно было пользоваться им напрямую или через другой редактор, имитирующий взаимодействие системы с пользователем.
Программа-календарь, которой необходимо производить арифметические действия для расчета даты будущей встречи, имитировала нажатие кнопок на имитации калькулятора.
И для этого совершенно не нужна общая абстракция, которая бы диктовала, как одной программе нужно обращаться к другой. Вместо этого каждый редактор отвечает за то, как найти способ использования человекоориентированных пользовательских интерфейсов в других редакторах[152].
Может показаться, что это сомнительный и крайне неэффективный способ заставить одну часть программы взаимодействовать с другой ее частью, и это правда! Но только в отношении небольших программ.
В основе фенотропной гипотезы лежит утверждение, что при работе с крупномасштабными системами, программы которых огромны, фенотропный принцип становится намного эффективнее традиционного, который обязывает к оперированию абстракциями.
Можно представлять фенотропную систему как множество редакторов, в которых имитации людей выглядывают из-за каждого редактора. В паре наших старых проектов можно было заглянуть за фасад большой программы и увидеть все редакторы, на основе которых она работает, парящие в информационном пространстве, как защитные экраны в космической войне.
151
MAX выглядит как россыпь маленьких ячеек и паутина линий, которая их соединяет. Он приблизительно повторяет программирование старых синтезаторов вроде тех, которые разрабатывали Боб Муг и Дон Бакла. (Они работали за счет множества кабелей, подключаемых штепселями к разъемам металлических ящиков, помещенных в рамки.)
Свое название программа получила в честь Макса Мэтьюса, который изобрел компьютерную музыку, работая в Лабораториях Белла. При жизни Макса мы часто завтракали вместе в Беркли, и к нам присоединялись Дон Бакла, Том Оберхейм, Роджер Линн, Кит Макмиллен, Дэвид Вессель и многие другие первооткрыватели продуктов электронной музыки. В эту команду входил и Боб Муг, с которого я брал пример, открывая индустрию виртуальной реальности. –
152
Проектирование напоминает попытки создания программ, которые могут исследовать и использовать устройства без предварительных инструкций. Пример такой похожей работы находится здесь: https://cacm. acm.org/ magazines/2017/2/212445-model-learning/fulltext –