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