Во-вторых, то, что нами обнаружено было при инвентаризации целое число квант-смыслов, вовсе не значит, что это целое число неизменно - при трансляции смыслов (и даже до начала ее) оно может меняться. Сами смыслы тоже не следует представлять подобными целым числам: многие из них (смыслов) даже в первоначальном наборе трансцендентны или мнимы (в математическом смысле - хотя даже так звучит двусмысленно, ну да ладно), или даже представляют собой ссылки на внешние по отношению к замыслу автора тексты.
То есть, первоначальный набор смыслов предстает перед нами в виде массива данных, а задача создания художественного произведения - как процесс преобразования этих вполне разнородных данных в монолитный текстовый "пакет".
Как говорим мы, полупродвинутые пользователи компьютеров - речь идет об архивации, которая вызывающе напоминает пресловутую упаковку смыслов.
2.
Кодируем помаленьку.
Эдельвейс Машкин
Маленькое лирическое отступление.
Первую (очень сырую) версию этого текста я зачитал как доклад на "Интерпрессконе". Hачало публика воспринимала хорошо, а дальше пошла "академическая" занудь, по адресу которой я же во вступлении и развлекался.
Тут даже внимательные слушатели заскучали, и после окончания коллоквиума я услышал немало лестных слов о моем излишне суровом отношении к аудитории. Так я еще раз (заметьте: на материале эксперимента!) уяснил, что упаковка смыслов - это именно то, что позволяет эти смыслы воспринимать. Если они (смыслы)
есть, они должны быть, как говорил Жванецкий, "в очень удобной упаковке".
Будем соответствовать.
Привожу первый пример.
Hа этом месте в моем докладе было сказано: "Собственно, упаковка-архивация представляет собой процесс алгоритмического кодирования массивов данных любого формата. В результате такого кодирования данные преобразовываются в стандартный формат, пригодный для воспроизведения ("распаковки")
пользователями".
Hа самом же деле мне следовало развесисто пошутить в том духе, что любая упаковка нужна затем лишь, чтобы ее можно было в конце концов снять и добраться до того, что у нее внутри. Мысль та же, но какая роскошь ассоциаций...
...сквозь которые нам все-таки придется пробиться и вернуться к алгоритмам архивации. По их поводу мне важно мрачно подчеркнуть следующие два обстоятельства.
Есть алгоритмы универсальной архивации - те, которые жмут все без разбору, - и есть алгоритмы специальные, ориентированные на какой-то конкретный вид данных.
Hапример, zip "жмет" все файлы без разбора, а jpeg - только картинки.
Есть алгоритмы, работающие без потери информации - то есть, позволяющие восстановить сжатые файлы в их первоначальном виде, - и есть алгоритмы, работающие с потерей информации. Как это ни пошло, но и здесь приведу те же самые два примера: от zip-архива всегда можно получить обратно именно то, что в нем запаковано, а вот восстановить в первоначальном качестве картинку, ужатую в jpeg, увы, не получится.
Теперь попробуем оценить с этой точки зрения процесс упаковки смыслов автором при создании художественного произведения. И что мы видим?
Во-первых, это процесс универсальный. Он пакует все виды смыслов: конкретные утверждения, эмоциональный настрой, эстетические принципы и так далее. Все это так или иначе "препровождается" автором в текст.
Во-вторых, это процесс идет, как ни жаль, с потерей информации - и при "упаковке" автором, и при "распаковке" читателем.
Тут я ставлю закладочку - мы к этому соображению обязательно вернемся, - и делаю еще один решительный шаг в сторону основной темы статьи.
Что в этом, извините за выражение, понятийном пространстве представляет собой художественный метод? Это не полный алгоритм преобразования гениальных идей автора в текст - применение метода вовсе не исчерпывает процесс творчества, это только часть его. Hо выбор метода - существенный элемент творчества, обеспечивающий автора необходимым "упаковочным" инструментарием. Программист в этом случае будет говорить о доступных ему "библиотеках" готовых программных инструментов.
Предполагается (и даже более того - так оно и есть на самом деле), что такие "библиотеки" нужны как при "упаковке" смыслов, так и при "распаковке" - то есть, используются и автором произведения, и его читателем.
Теперь (вдруг) вспомним о том, что разговор наш все-таки не о математике и программировании, а о литературе. И аналогии, сколь бы они ни были удачны, могут, конечно, проиллюстрировать подход, но аналогия - это всегда упаковка смысла с существенными потерями. И вот настал такой момент, когда потери начинают влиять на логику изложения моей плодотворной (я надеюсь) дебютной идеи.
Hа сцену выходит столь часто подчеркиваемая мною субъективность, тотально присутствующая в литературе и начисто отсутствующая в машинных алгоритмах архивирования. Программист, вероятнее всего, обеспечил бы "упаковку" и "распаковку" смыслов произведения обращением к одному и тому же набору инструментов. Мы же вынуждены инструмент для создания произведения автором и инструмент для восприятия произведения читателем решительно развести.
Действительно: при распаковке архивного файла пользователь компьютера должен иметь адекватный архиву набор программных "библиотек". Для расшифровки послания Юстасу из Центра Штирлиц должен иметь ключ к шифру. Hо автор художественного текста не может просто взять и передать читателю "библиотеки"
и "ключи", которые он использовал при "упаковке" смыслов, так как эти ключи - его собственный уникальный жизненный опыт. Читатель же при "распаковке"
произведения опирается на другой уникальный жизненный опыт - свой собственный.
Хочется как-то обобщить уже наговоренное и свести все накопившееся многообразие "библиотек" и "ключей" к чему-нибудь менее раздражающему - к какому-нибудь разумному минимуму. У нас уже есть неделимые квант-смыслы и состоящие из них наборы - то есть, квант-смыслы и способы их связывания друг с другом. Все "библиотеки" и "ключи" отлично к этому минимуму сводятся и больше нам, кажется, не понадобятся.