Продолжение статьи Лекса Кравецкого о творчестве. Начало читайте по ссылке: https://22century.ru/popular-science-publications/creativity.
Элементы творчества
Для начала отмечу, что, хотя разные виды творчества кажутся буквально разными — совсем, все они содержат множество сильно похожих составных элементов. Причём, что ещё интереснее, аналогичные элементы есть также в инженерной и — отчасти — в научной деятельности.
Пример того — «итеративное наращивание» — уже фигурировал в предыдущем разделе, однако таких примеров столь много, что можно было бы сказать: «практически нет примеров иного» — то есть ни в каком творчестве нет таких методов, которых не было бы в других.
Прямо вообще про все области я, конечно, всё расписать не могу, поскольку это будет запредельно долго, да и всё-таки не во всех из них я разбираюсь, поэтому остановимся на нескольких: писательство художественной литературы, сочинение и исполнение музыки, рисование, программирование и инженерное проектирование девайсов. Между делом — к слову — будут упоминаться и другие области, но это уже опционально.
Легко видеть, что перечисленное, как многим кажется, настолько разное, что «как вообще можно тут найти что-то общее, кроме гениальности корифеев?!»
Но нет, оно-таки можно. И хотя в одних областях надо что-то делать руками, а в других можно вообще отрываться от разглядывания содержимого собственной головы, только чтобы надиктовать секретарше следующую главу, составные элементы удивительным образом совпадают, хотя и выражаются в совершенно разных формах.
И, сразу скажу, названия у этих элементов будут весьма условными — в ряде случаев этими словами называется что-то другое, поскольку теория творческой деятельности человечеством на данный момент ещё не очень чётко продумана.
Канва
Если мы будем иметь дело с романом, то его «канва» — это основная задумка. Не просто даже сюжет, а нечто ещё более абстрактное и размытое. Что-то типа «а про что это будет вообще». Ну там, «это будет книжка как кучка знакомых друг с другом дворян тусит и страдает в самый разгар вторжения Наполеона в Россию».
Однако, хотя в других областях этот термин употребляют редко, там оно тоже есть.
Очевидным образом художник тоже понимает заранее, о чём в целом будет картина, музыкант — про что будет песня, весёлая она или грустная, быстрая или медленная, программист знает, какую программу он будет писать, а инженер — что должен делать тот девайс, который он будет проектировать.
Если мы возьмём другие области, то и там — от скульптора до режиссёра — тоже все знают, про что примерно будет то, чем они собираются заняться.
Но тут надо понимать: это они знают именно «примерно», а не во всех деталях.
Художник может решить, что назрел момент для зарисовки ближайшей речки в окружении деревьев с пожелтевшей листвой, но он в лучшем случае знает географическое расположение того места, которое ему представляется подходящим, но где там стоит каждое из деревьев, какой формы будет каждое облако и сколько именно птичек будут улетать на юг в левом верхнем углу картины, он на этом этапе ещё не в курсе.
Аналогично, музыкант ещё не знает точную длину песни, количество строф в ней и даже основные её аккорды. Просто в голове какой-то мотивчик нарисовался и, похоже, он про то, как клёво быть морским разбойником.
Программист, естественно, тоже ещё не знает, какая в точности архитектура будет у кода и какие в точности библиотеки будут использоваться, не говоря уже про текст каждой функции. У него есть предположения по поводу этого, но весьма неустойчивые.
А инженер, возможно, не знает даже основных составляющих девайса — лишь предполагает некоторые из них.
Однако решение заниматься этим они к настоящему моменту уже приняли.
Это к вопросу о «мастер всё знает заранее». О нет, мастер сначала ловит некую зацепку. Причём независимо от того, заказали ему это произведение или самому захотелось — всё одно: сначала мастер ищет канву, потом анализирует её на интересность и состоятельность, а потом принимает решение реализовать это дело.
Подчеркну: принимает решение реализовать, ещё не зная даже самых крупных деталей результата, а, в лучшем случае, только предполагая их самые общие черты.
Тут почти каждый воскликнет: «Но ведь и я в жизни так же делаю, а я ведь не мастер!» И, таки да, и ты тоже так делаешь. И мастер так делает. И все так делают. А отличие разве что в том, что мастер лучше угадывает, какая канва покатит, а какая нет. Но иного способа просто не существует.
«Внутренний голос» и озарение
Кстати, а почему мастер лучше угадывает? Потому что лучше умеет думать? Ну, и это тоже: постоянные занятия какой-то областью с неизбежностью развивают умение думать в этой области.
Однако, что гораздо важнее, у мастера долгой практикой в некоторой области натренирована нейронная сеть. Натренирована на эту область. Поэтому, зачастую, мастер получает ответ «клёво» или «не клёво» ещё до начала глубокого обдумывания.
Ещё это иногда называют «чутьём». Но оно не богоданное, а результат длительной практики в некоторой области. Человек много раз пробовал, скажем, рисовать картины, а потому имеет большой опыт по поводу того, что именно лично ему будет приятно рисовать, а что — нет. Результат чего ему понравиться, а результат чего будет отвратителен. Что потом будут вспоминать десятилетиями, а что — тоже десятилетиями, но с присказкой «никогда больше».
Ум это или не ум? Ну, определённо это что-то в мозге и как-то связано с его деятельностью. Однако оно даже не всегда сознательное, а больше похоже на то, что «внутренний голос» просто сообщает задумку, а потом сам же добавляет: «смотри, чо придумал — бери, не пожалеешь». Или, наоборот, «ну и хренотню же мы с тобой только что придумали!».
Разумеется, внутренний голос иногда нехило привирает — особенно под воздействием алкоголя, — а потому слепо следовать его советам мастеру не пристало. Для верности можно и что-то логически прикинуть — не самообман ли, не путь ли в пропасть, но, как правило, основные доводы по данному элементу творчества принадлежат внутреннему голосу, а сам мастер, разве что, потом логически додумывается, что пусть лучше дворяне тусят и страдают во время вторжения татаромонголов, а то про Наполеона уже у Льва Толстого было (да-да, и канва тоже в ряде случаев, если не сознательный плагиат, то бессознательное заимствование).
Конечно, к этому всему ещё примешивается стечение обстоятельств — например, автор может посмотреть или услышать что-то, про что подумает «а тут есть хороший ход — я мог бы на этой основе сделать клёвое произведение», может состояться беседа с кем-то, наведшая его на мысли, можно случайно увидеть что-то, что подскажет идею картины, и, если бы всего этого не было, то, возможно, произведение вообще бы не придумалось.
Однако практически в любом случае подсказку «о, клёво, сделай на этой основе что-то» почти всегда даёт внутренний голос автора. За теми исключениями, когда оное подсказывает чужой внутренний голос устами своего носителя, а внутренний голос автора решает, «о, клёво, отличная подсказка!».
И, ещё раз подчеркну: оный голос — не божественный дар, а строго результат опыта в данной деятельности. Хотя и правда проявляется обычно в виде «только что ничего не было — и тут пред глазами встал общий вид таблицы химических элементов, в голове заиграла мелодия и одновременно приятный баритон надиктовал несколько демофрагментов будущей поэмы».
С существенной оговоркой: оно никогда не бывает «само». Внутренний голос надо долго стимулировать, чтобы он высказался по теме. И не «врождённым талантом», а многократным штурмом данной вершины.
Упавшее яблоко или ночной сон, увы, не даруют открытия в физике и химии, если перед этим очень долго не думать о вопросах физики и химии.
Но вот если думать, то картинка со временем начинает складываться.
Поначалу почти с неизбежностью будет логический полный перебор вариантов — разве что, с некоторыми оптимизациями (то есть с отбрасыванием заведомо провальных веток). Но потом промеж них начнут возникать «мини-озарения» или, если угодно, «мини-инсайты»: какие-то фрагменты решения будут подсказываться внутренним голосом сильно быстрее, чем до них дошло бы дело при полном переборе.
Их, естественно, надо вплетать в логику рассуждений и продолжать думать. И тогда, через какое-то время, внутренний голос может подсказать полное решение или основную его идею.
Этот «макроинсайт», конечно, надо тщательно проверить логикой, и если всё Ok, то задача решена.
То есть логика очень даже в деле — без размышлений не будет и инсайтов, однако без опыта и внутреннего голоса дело тоже не пойдёт. Поскольку никто пока что не знает, каким образом быстро придумывать что-то новое при помощи логики.
Вот генератором случайных чисел — это да. Ещё можно при помощи ламантинов, перекладывающих шарики со словами, — хотя и это очень похоже на генератор случайных чисел.
И при помощи полного перебора — тоже да. Только очень и очень долго. Люди столько не живут.
Ну и ещё можно всем натрындеть, что лично ты или твой гуру уже изобрели способ делать это логикой. И назвали его «теория быстрого закономерного пошагового решения всего на свете».
Но, увы, только натрындеть — неоднократно уже проверяли, не работают все эти способы. Возможно, потом когда-то появится работающий, но пока что работающих нет. Тем более, надёжно. Существуют только методы, которые слегонца позволяют сократить процесс поиска, путём упорядочивания известной информации и уже пришедшего в голову.
Однако не следует ли из всего этого, что «внутренний голос» — всё-таки «дар свыше». Или хотя бы что-то непознаваемое, а то и вообще потустороннее? Быть может, предположение Платона о «мире идей», куда отдельные люди умеют подконнечиваться и забирать оттуда какую-то с самого начала там лежащую идею, всё-таки было верным?
Увы, видимо, нет. Понятно, что Платон наверно имел опыт общения с внутренним голосом, а потому мог сравнить его с пользующимся большой популярностью у особо продвинутых древних греков логическим методом рассуждений, убедиться в том, что «совершенно ведь не похоже», и от того задаться вопросом «но как же тогда оно работает?». И ввиду того, что в те времена даже идеи нейронных сетей, не говоря уже об исследованиях оных, ещё не существовало, один из вариантов объяснения был вот таким: оно где-то в потустороннем месте заранее всё сложено, а у некоторых людей есть туда доступ.
Однако сейчас на дворе всё-таки не Древняя Греция, а потому известны алгоритмы распознавания, сильно отличающиеся от последовательных «ветвящихся» логических рассуждений вида:
Нейронные сети вместо этого обрабатывают всю поступившую информацию не последовательно — шаг за шагом, а параллельно — все факторы одновременно, по сути, приписывая каждому фактору «вес», а потом, вычисляя сумму всех «взвешенных» факторов данного конкретного случая, чтобы по ней получить приблизительный, но близкий к правде результат. В момент же своей тренировки они, грубо говоря, получают на вход значения факторов, а на выход — заранее заданный ответ, и пытаются модифицировать «веса» факторов так, чтобы генерируемый в её текущем состоянии по набору тех же значений факторов ответ стал поближе к заданному.
Чтобы подробно описать весь алгоритм и все его разновидности, увы, потребуется довольно много времени, поэтому здесь остановимся на этом крайне приблизительном описании. Ибо сейчас важен практический смысл оного: уже известно, что существуют алгоритмы, дающие ответ без построения логического дерева. И одновременно с тем известно, что устройство мозга реализует частный случай одного из таких алгоритмов (устройство мозга ещё далеко не целиком понятно, но уже ясно, что его общие алгоритмы — именно из этого множества).
Иными словами, «озарение» действительно не является результатом логических рассуждений. Напротив, это возможность логических рассуждений является результатом того, что устройство мозга — определённый набор нейронных сетей — позволяет реализовать, в том числе, и логические рассуждения тоже.
Однако мозгу логические рассуждения нужны в основном для проверки «озарений» — готовых ответов, выдаваемых натренированной нейронной сетью. Ибо, мало ли, вдруг мы не на тех данных тренировались или ещё какой-то сбой произошёл.
Например, вполне понятно, что в момент узнавания своего друга в лицо вы никаких логических рассуждений не ведёте, а сразу получаете готовый ответ в стиле: «это точно он» или «это почти наверняка он» и т. п. Однако потом, логикой, вы можете это дело проверить. Ну там, «постойте, мой друг же ростом повыше, наверно этот чел просто на него похож».
Аналогично, когда внутренний голос говорит про что-то «о, клёво» или даже «подсказывает» нужную фразу для романа, то это, хоть и не логическое рассуждение, но и не «подключение к миру идей», а результат работы натренированной нейронной сети, очень похожий по своему устройству на распознавание чьего-то лица. И то, и другое — результат достаточно долгой тренировки нейронной сети. Которое потом можно проверить логикой, но вот как сгенерировать «чистой логикой» что-то новое пока что неясно.
Как неясно, возможно ли это вообще. Даже единственный известный способ — полный перебор с оптимизациями — всё равно подразумевает, что каждый перебираемый вариант будет каким-то образом оцениваться на «клёвость», а это, в свою очередь, завязано на этот самый «внутренний голос», взвешивающий параметры. А потому, даже если Вася распишет весь алгоритм взвешивания, которым будет чисто механически пользоваться Петя, то это всего лишь будет означать, что Петя пользуется не своим внутренним голосом, а Васиным — пусть даже опосредовано.
Снова канва
Это может показаться странным, но даже в инженерных задачах все существующие «методы изобретения канвы» не работают — опять же, они как максимум позволяют слегка сократить время на поиск. Типовую задачу, да, можно решить, просто вспомнив или подсмотрев шаблон решения, но вне учебного процесса типовые задачи бывают только у инженеров, которые следят за работоспособностью предприятия или жилфонда, а в случае проектирования чего-либо нового, обратно же, если никак не приходит озарение (оно же «инсайт», оно же «внутренний голос»), то, увы, надежда только на полный перебор всех известных вариантов. Даже загуглить не получится, поскольку без уже сложившейся канвы ты даже не знаешь, как оно называется. Можно, разве что, понадеяться, что по поводу той проблемы, которую тебе надо решить, уже у кого-то был инсайт, и он где-то уже успел написать хотя бы о канве решения.
Тут надо понимать, что канва решения и практические требования — разные вещи. Практическое требование у нас, например, — вскрыть немецкие шифры. А канва решения: «Мы забабахаем какую-то хитрую машину, которая будет перебором пытаться их вскрыть». И в момент появления необходимости вскрывать шифры ещё далеко не очевидно, что их надо вскрывать именно при помощи хитрой машины, а не хитрого лингвиста, например.
Более того, если ты про машины ни сном ни духом, то такая канва тебе с очень малой вероятностью придёт в голову.
Поэтому, таки да, знания и опыт — очень важная штука. Именно по их мотивам внутренний голос сообщит мастеру про хитромашинную канву.
В общем, этот лейтмотив — внутренний голос — ещё много раз по ходу повествования встретится.
И, кстати…
Лейтмотив
Здесь, увы, придётся использовать термин уже не из литературы, а из музыки, поскольку для литературы мне подходящий термин что-то не вспомнился.
«Лейтмотив» — это некий повторяющийся элемент произведения.
Но тут не всё так просто, ибо повторяться может много чего — солнце, вон, каждый день восходит и заходит, но лейтмотивом это мало в каких произведениях является.
Тут имеется в виду, что оное — некий ключевой элемент, на котором практически всё произведение держится, и, благодаря которому оно помнится. Ибо, три блатных аккорда есть в каждой дворовой песне, но что-то мы эти песни не особо друг от друга отличаем.
В общем, «лейтмотив» — это что-то типа главной фишки произведения или проекта. Ну, одной из — бывает ведь, что таких штук заметно больше одной.
Причём, как правило, эта главная фишка действительно повторяется много раз, поскольку уж очень хорошо цепляет, хорошо подходит для раскрытия идеи или для решения целой кучи подзадач в рамках основной задачи.
Однако в этом ключевом повторяющемся элементе есть ключевой нюанс, который я несколько раз повторю: очень часто лейтмотив повторяется не точности.
Будет скучно, если герой романа раз за разом делает в точности одно и то же. Будет скучно, если вся картина будет состоять из одной и той же маленькой картинки. Будет скучно, если один и тот же музыкальный ход множество раз исполняется без малейших изменений (хотя, как вы знаете, так тоже делают — обычно, когда халтурят).
В программе может много раз использоваться один и тот же подход, однако копипаста одного и того же фрагмента кода на данный момент считается моветоном, и оного стараются избегать. Тем не менее, с некоторыми модификациями использование одного и того же подхода вполне допустимо — например, использование в разных местах одних и тех же логических связок между объектами.
Опять же, в инженерном проекте многоэтажного здания этажи могут повторяться, но это всё ещё не лейтмотив, а та же «копипаста», вызванная чисто техническими причинами: по сути-то, не нужно, чтобы каждый этаж был «своим собственным» — планировка помещений вполне может быть идентичной. Но вот если, например, архитектор много раз использовал определённую форму (например, треугольник) при оформлении самых разных элементов здания — от козырька над подъездами до вида всего здания сверху — то вот это уже лейтмотив: тот самый повторяющийся элемент именно этого здания, который будет отличать его от других и делать узнаваемым.
Схожим образом, художник на картине может многократно использовать похожие формы для разных объектов, чтобы они «графически рифмовались», а писатель сделать так, чтобы его персонаж совершал в чём-то схожие поступки в разных ситуациях, потому что, например, по замыслу этот герой — жадный, и вот так проявляется его жадность.
В музыке же лейтмотив наиболее очевиден: это та самая «мини-мелодия» или их набор, которые хорошо запоминаются и именно их хочется напевать. Но опять же, не обязательно в точности повторённая — её можно играть в разных местах разными инструментами, можно играть в разных местах в разных тональностях (то есть как бы «сдвинув» каждую ноту мелодии на равное количество клавиш фортепьяно или даже на неравное, но всё-таки закономерное), можно замедлять или ускорять и так далее.
Тут особенно интересно то, что все эти модификации лейтмотива сохраняют его узнаваемость. Причём удивительно, что ключевым в лейтмотиве является не особо-то большое количество нот: вообще говоря, в ряде случаев чуть ли не 4/5 нот можно выкинуть, и оно всё равно будет узнаваться, как «та же мелодия».
Эта важная закономерность, кстати, ещё проявит себя в дальнейшем — опять же в контексте вопроса «каждый чих продуман».
Однако пока что зададимся вопросом, а можно ли из «лейтмотивов» в немузыкальных жанрах тоже что-то выкинуть, сохранив узнаваемость?
Конечно, можно.
Именно на этом и основаны вариации: что-то выкинули, а что-то вставили, но сходство всё равно очевидно. Мозг вообще хорошо заточен под узнавание: ведь уже упомянутое лицо друга мы можем опознать при разных освещениях, с разных ракурсов и даже по отдельным фрагментам. Попиксельно картинки вроде бы вообще совсем разные, но нейронная сеть всё равно способна понять, что это — один и тот же объект.
Поэтому, хотя контекст совсем другой, мы зачастую отлично понимаем, что поступок персонажа — по смыслу тот же, что в прошлый раз. И, видимо, вызван теми же психологическими чертами этого персонажа.
И на картине, даже если мы понимаем, что вот это — дерево, а вон то — скала, мы способны уловить эту «графическую рифму» в тех кривых, которыми художник обозначил их контур.
Что же касается программ, то там программист с достаточным опытом способен распознать один и тот же манёвр, даже если не совпадает вообще ни одной буквы. Текстуально в разных фрагментах программы написано совсем разное, но логически оно имеет одни и те же «структурные связи», то есть в этих фрагментах использован тот же поход.
Аналогичное наблюдается и в конструкторских решениях: некий удачный ход может встречаться в конструкции повсеместно.
Хотя, конечно, в программировании и инженерии обычно не стоит задача сделать своей проект совершенно уникальным не только по внешнему виду и функциональности, но и по каждому элементу внутреннего устройства, а потому лейтмотивы кочуют из программы в программу и из проекта в проект гораздо более свободно — в том смысле, что это не так стараются скрыть, как в художественном творчестве.
Однако и в художественном творчестве оно тоже так: если полное копирование мелодии сразу же распознаётся, как плагиат, то вот похожий ритм — уже как бы нет. А уж нарисовать батальную сцену, как уже двадцать ранее нарисованных (причём не все тобой) — вообще обычное дело. И интриги копировать из романа в роман или из фильма в фильм — тоже. Не, ну а что? Работает же. Прикольно же. Да и не так уж много возможных вариантов в мире существует.
Иными словами, лейтмотив, конечно, делает произведение узнаваемым, но при этом он не так, чтобы совсем уникален. Он хорошо воспринимается и запоминается именно в этом произведении и в той форме, в которой в нём преподнесён, но вполне возможно, что некие фрагменты откуда-то скопированы или хотя бы чем-то вдохновлены, а то и вообще он — почти точная копия чужого лейтмотива, которую хорошо загримировали.
Однако чтобы что-то по цепочке копировать, кто-то должен был придумать это первый раз. Как он это сделал? Вычислил?
А вот нет. Какие-то связующие элементы, быть может, и вычислил постфактум, но саму «основу» ровно так же услышал от внутреннего голоса. Как уже почти готовый ответ, который надо потом дошлифовать и доправить, но всё-таки как уже почти готовый.
И в инженерии с программированием оно аналогично: можно подсмотреть лейтмотив, восхититься, осознать и начать повсеместно использовать, но когда оно изобретается первый раз, то почти целиком строго через озарение. В коем потом исправляются логические и конструктивные недочёты — уже при помощи «вычисления», но даже многие дополнительные детали при этом тоже приходят через мини-инсайты.
Стиль
Вообще, понятие «стиль» определить довольно тяжело, и все попытки определения будут состоять из таких же расплывчатых и слабо формализуемых слов типа «атмосфера» или «совокупность характе́рных признаков».
Последнее более—менее походит на определение, но всегда ведь можно спросить, а что такое «характерные»? Как их отличить от «нехарактерных»? Или от «не признаков»?
А всё потому, что и «стиль» тоже завязан не на формализацию, а на способность нейронных сетей распознавать образы. Логическим рассуждением это крайне тяжело передать, однако мозг при этом «интуитивно» (то есть чисто «нейросетевым распознаванием») видит, что элементы произведения как бы похожи друг на друга. Не обязательно формой, а вообще хоть чем-то.
На картине, например, это может быть определённый подбор цветов. В музыке — определённый набор ритмических решений или мелодических ходов. В литературном произведении — определённый способ построения фраз (ну, например, то, как фразы строит Йода — это как раз очень наглядный пример).
За этим, кстати, кроется очень действенный способ создания стиля и, по совместительству, чуть ли не единственная вменяемая рекомендация по его созданию: стиль создаётся не столько через добавление чего-то, а через запрет чего-то.
Грубо говоря, Йода может строить фразы только так. И вот из этого запрета на другие способы построения как раз и проистекает его стиль.
Аналогично, в живописи самый простой способ задания стиля — запретить себе использовать определённые оттенки цветов (ну там, не использовать оранжевый и жёлтый, например). Или определённую насыщенность цветов. Или определённые формы. Или рисовать чёткие детали на заднем плане. Или добавлять иное количество воды в краску.
Художник мог бы рисовать контуры любой толщины, любым цветом и любым средством, но он рисует их только коричневой тушью и только в миллиметр толщиной.
Писатель, например, ограничивает количество прилагательных и длину предложений. И вводит для речи каждого персонажа свои собственные аналогичные ограничения.
Музыкант… О. Сама теория музыки вообще строится на ограничениях — там это прописано прямым текстом: тональность — это определённая выборка нот из всего их возможного набора, которые только-то и будут использоваться в произведении или, по крайней мере, в его относительно продолжительном фрагменте (ну, на самом деле, могут использоваться и другие, но очень эпизодически). А ещё там будет только вот такой-то ритм. И только такие-то инструменты — это, правда, уже не прописано в теории музыки, но по факту делается именно так.
В программировании «стиль» чаще называется «парадигмой», но оно тоже по сути «набор ограничений». Язык вроде бы позволяет довольно большое количество вариантов, однако, как правило, в программе будет использован только определённый их набор. И это временами даже прописывается в «гайдлайне»: «да, язык позволяет, но мы вот так-то в этой программе делать никогда не будем».
У этого есть и экспериментальная составляющая: язык позволяет, но опыт показывает, что так очень легко всё поломать, — однако кроме неё есть ещё и, скажем так, эстетико-практическая сторона вопроса. Код выглядит лучше, если он имеет стиль (имеется в виду не только форматирование текста, но ещё и набор подходов плюс используемых сущностей и конструкций). Его проще понять, если он написан в одном стиле. Его проще чинить или модифицировать, если что.
Но ещё, что немаловажно, так становится гораздо проще думать.
Это — очень действенный способ стимуляции мыслей: радикально сузить область поиска. Вроде бы свобода это зашибись — можно мыслить о каждом объекте вселенной любым из миллиарда способов, — но на практике даже простейшие вещи при таком просторе для мыслей придумать не получается. Если же сказать себе «сейчас я не думаю обо всей вселенной во всех её деталях, а только о котах, почтальонах и роликовых коньках» — при весьма небольшой тренировке идея для рассказа появляется почти мгновенно. Именно по этой причине множество литературных упражнений строится на искусственном введении ограничений: коллега придумывает пять слов — напиши рассказ с этими словами так, чтобы они были сюжетообразующими элементами; задан набор рифм — напиши с ними стихотворение; напиши эссе без местоимений… или без глаголов.
Кажется, что это тяжело, поэтому так и упражняются — для преодоления себя. Но нет, напротив, так гораздо проще. И так упражняются, поскольку так гораздо легче упражняться, а потому можно наупражнять себе гораздо больше.
Внезапно, в программировании аналогично: стоит сказать себе, что в этот раз я все задачи буду решать при помощи ссылок на функции с одним аргументом, как архитектура приложения почти мгновенно начинает надиктовываться внутренним голосом. Хотя ещё пять минут назад вообще было неясно, с чего начать.
Инженерия в этом смысле тоже весьма похожа на программирование. Причём стиль там тоже относится не только к визуальному дизайну конструкции, но и к способу её разработки. Инструментов — море, и они весьма гибкие, но если себя ограничить, то становится существенно проще рассуждать и вычислять.
Есть у нас, положим, проектируемый музыкальный центр. Мы как хотим, чтобы им управляли? Три кнопки, а до остального он сам «додумывается», или же «стопицот» кнопок, чтобы пользователь мог каждый параметр лично настроить? Ведь можно и так, и так, однако если в одних местах сделать так, а в других — вот эдак, и пользоваться будет неудобно, и проектировать сложнее.
Ну или, если мы, например, с самого начала решили, что у нас везде будут скруглённые углы, то форму корпуса тут же становится гораздо проще придумывать. Этот выбор уже как бы диктует нам следующие шаги, позволяя мысленно перебирать гораздо меньше вариантов, чем если бы мы каждый раз считали, что углы могут быть какими угодно.
Точно так же, например, художнику придётся перебирать меньше цветов для каждого из объектов, если он с самого начала наложил ограничение на палитру. А если через теорию цвета наложить ещё и глобальные (то есть подходящие для всех картин в мире) ограничения на сочетания цветов, то перебирать придётся совсем мало. Так быстрее, проще и одновременно с тем результат выглядит красивее.
То есть заранее заданное ограничение одновременно и упрощает процесс создания, и делает результат более привлекательным.
И теперь снова вопрос, откуда стиль берётся?
Понятно, что его можно подсмотреть, но наверно хватит уже это повторять. Откуда он берётся первый раз?
Ну ладно, не первый раз в мире, а первый раз вот у этого творца/инженера? Почему он выбирает именно вот этот стиль?
Существует романтический миф о том, что «настоящий профессионал» выбирает стиль под задачу. Ну там, «каждый программист выбирает язык под ту программу, которую надо написать».
Но нет, многие наниматели, конечно, мечтают, чтобы нанимаемый ими «настоящий профессиональный водитель» умел в совершенстве управлять любым транспортным средством — от трёхколёсного велосипеда до реактивного самолёта, и от запряжённой волами телеги до атомной подводной лодки, — но на практике таких «мастеров» не бывает. Ибо, пока ты тренируешься делать что-то одно, ты не тренируешься делать что-то другое.
Программист с опытом, конечно, рано или поздно разберётся с любым языком (как за большее время разберётся и кто угодно вообще без опыта), однако на том самом любимом его языке, который он постоянно практикует, он сможет слёту что-то написать, а про другие он будет месяцами читать мануалы, прежде чем достигнет хотя бы уровня «ничего так» — в сравнении с его уровнем на любимом.
Разумеется, то, что человек много раз пробовал и обдумывал, он делает лучше. Поэтому напрячься и скопировать непривычный стиль кое-как можно, но в своём «родном» стиле—двух оно идёт на три порядка круче.
И ровно так же дело обстоит у творцов. Хороший комиксист вовсе не обязательно способен писать пейзажи акварелью, а пейзажист при этом может оказаться весьма слаб в комиксах. Классический композитор с большим трудом сумеет изобразить лишь жалкую пародию на дэт-металлическую песню, а блестящий дэт-металлический гитарист вовсе не обязательно блестяще же исполнит Лунную сонату. Автор детективов может быть плохим поэтом, а гениальный поэт быть не в состоянии написать захватывающий детектив.
Причём «может быть» тут везде надо читать как «почти наверняка». «Если у него не было сопоставимой практики в другом жанре/стиле».
В восьмидесятые годы многие группы прогрессивного рока вдруг решили, что времена рока прошли и сейчас надо исполнять поп-музыку. И попытались. Почти у всех получилось очень плохо. Хотя прогрессивный рок они играли отлично, в поп-музыке они не дотягивали не то, что до Майкла Джексона, а даже до групп-однодневок, игравших на школьных дискотеках.
В общем, стиль — это не только заданные мастером ограничения, но и ограничения, глобально наложенные на мастера. Просто потому, что он долго практиковался именно с такими ограничениями, а с другими не практиковался. Может ли он научиться другому набору? Может. И даже частенько обучается. И кто угодно может — не только мастер. Но на это нужно время и немало. А если сразу, ну да, у мастера будет чуть лучше, чем у первого попавшегося человека с улицы, и учиться придётся чуть меньше времени, однако, нет, пересесть с велосипеда на реактивный самолёт или наоборот — мероприятие не на один день.
То есть никто не «подбирает стиль под задачу». В лучшем случае, подбирают себе задачи под отработанный стиль. А в худшем делают в том стиле, в котором умеют, ту задачу, которую навязали, или же эту навязанную задачу решают в навязанном непривычном стиле, отчего всё выходит кривым, косым и очень долгим в разработке.
И вот он — ответ на вопрос «как был выбран любимый стиль в первый раз?». Примерно вот так: стечением обстоятельств. Понравились задачи и понравился способ их решения. Понравился набор ограничений: именно про него интуитивно показалось, что в нём будет особенно комфортно, и что набор связанных с ним задач будет особенно интересен лично вот этому человеку.
Кое-что, конечно, вычислялось — логикой и анализом результатов экспериментов. Но тут как со скруглёнными углами. У иллюминаторов в самолёте они скруглены потому, что в ином случае на углах получается экстремальное механическое напряжение, с которым как раз и борются скруглением, но практически во всех остальных случаях их выбрали просто потому, что дизайнеру или конструктору показалось, что именно вот так — прикольно. Ну а потом все коллеги как-то уже втянулись и привыкли, а принципиально несогласные ушли в другие проекты.
Ведь оно так даже в инженерии: наилучшие результаты у разработчика получаются, когда разработчику кажется прикольным то, что он делает. А уж в творчестве оно так вообще почти всегда.
Собственно, фейл прог-роковых групп в восьмидесятых проистекал именно из этого: они были обеспокоены потерей популярности, а потому решили сменить стиль, но этот стиль не казался им прикольным. Они не умели в нём сочинять и при этом были слабо мотивированы этому учиться — просто «отрабатывали гонорары». Оттуда и результат: и музыка получилось проходной, и с гонорарами не сложилось.
В результате, выбранный стиль тоже оказывается вовсе не результатом некого «логического анализа», а в основном результатом личных эстетических интуитивных предпочтений, вызванных неясными и непредсказуемыми случайными факторами.
А уже потом по результатам этого почти случайного выбора человек может осознанно попасть в тот или иной проект: в нём делают то, что его привлекает, и он это делать умеет, а потому будет в нём полезен.
Тут я ещё раз уточню: условное название «любимый стиль» вовсе не означает, что этот стиль у каждого единственный. У кого-то их может быть несколько, и они даже могут заметно отличаться.
И вместе с тем «когда-то выбрал по стечению обстоятельств» не означает, что теперь уже всё, это на века. Нет, потом точно так же по стечению обстоятельств может понравиться другой стиль, и после тренировки он добавится к предыдущим или даже вытеснит какие-то из них.
Кроме того, стиль может развиться или даже поэтапно трансформироваться во что-то, довольно сильно отличающееся от исходного варианта. Или даже во что-то, что никому в мире до сего момента было незнакомо.
Но в любом случае, количество стилей, к которым у этого творца/инженера лежит душа и которыми он прекрасно владеет, составляет ничтожную долю от имеющихся вариантов — даже от уже известных имеющихся, а не потенциально возможных. И что он ни делай, а стать мастером мирового уровня во всех стилях даже по чисто техническим причинам не получится, не говоря уже о причинах мотивационных.
При этом снова повторюсь, мастер скорее будет выбирать задачу под любимый стиль, а не стиль под задачу. Причём не только инженер, но и творец. Наверно творец даже в большей степени.
То есть любимые стили мастера определяют набор задач, которые могут быть выбраны этим мастером, а не наоборот.
Но как же он вычисляет, что задачу надо решать именно в этом стиле из числа всех им любимых? Да снова никак не вычисляет: ему просто сразу это понятно, поскольку так сразу сказал внутренний голос.
Фабула и сюжет
Итак, канва — это общая идея произведения, лейтмотивы — его главные зацепки, которые, возможно, много раз повторяются в разной форме, а стиль — это наложенные на всё это произведение (да и на всё творчество мастера) ограничения.
Однако, как легко догадаться, считать эти три, безусловно, крайне важных вещи произведением столь осмысленно, сколь осмысленно было бы считать зданием — его общий замысел, причудливый дизайн крыши и заранее выбранные краски для стен.
Кроме базовых основ, нужна ещё связная реализация всего в целом, и вот её почти целиком вбирают в себя фабула и сюжет.
Что это такое, проще всего понять на примере литературных произведений, к которым эти термины в первую очередь и относятся.
В книге происходят какие-то события и разговоры, а между ними, возможно, есть размышления автора. Перечень всего это — как раз и есть фабула. Обычно этот перечень упорядочивают хронологически, но можно хоть даже по алфавиту или тэгам: идея термина в том, что это именно всё множество смысловых содержаний эпизодов, составляющих книгу. Всё множество происходящих там, в кадре и за кадром, событий, включая рассуждения автора и героев.
В отличие от этого, «сюжет» — это то, как все эти эпизоды преподносятся читателю. С целью вызывать определённые эмоции, поддержать интерес и сохранить интригу.
Например, как правило, преступление происходит ближе к началу хронологической линии детектива, и его совершают конкретные персонажи. Это — фабула: фактическая сторона. Однако обычно, если сразу раскрыть читателю, кто именно совершил преступление, то интригующей истории не получится, поэтому в сюжете об этой части фактической стороны умалчивают до самого конца произведения и лишь там её излагают напрямую.
А бывает какую-то часть фабулы даже не излагают, поскольку фабула вполне может быть обширнее сюжета и, например, помогать автору этот сюжет разрабатывать. Поэтому по поводу определённых частей фабулы в самом произведении могут быть только намёки, по которым читатель может сделать предположения о произошедшем, или даже не быть намёков, поскольку автор, например, счёл эту часть чисто технической — полезной только ему, но не читателю.
В общем, вспомните, например, фильм «Криминальное чтиво» — вот это типичный пример того, как события представляются зрителю совсем не в том порядке, в котором произошли.
Тут, казалось бы, ну ладно, в литературе, театре и кино, понятно, а в других областях-то это всё где?
Ну, в музыке (если отвлечься от того, что в песне ещё и стихотворный текст есть) это выражается в том, что на практике оная состоит из фрагментов, которые на этапе сочинения произведения появляются именно что в этой фрагментарной форме: отдельных мелодий, каких-то гармонических фрагментов и т. п., — которые уже потом «монтируются» друг к другу в определённом порядке. Сами эти фрагменты по смыслу аналогичны фабуле: вообще говоря, вариантов их последовательного расположения и даже пересечения сильно больше одного (чем в ряде жанров, в частности, обширно пользуются на концертах). То же, как они были расположены, например, в альбомной версии данного произведения или в его изданных нотах — аналог сюжета.
В живописи это прослеживается с бо́льшими натяжками и меньшей аналогичностью: аналогом фабулы являются необходимые для картины объекты, а аналогом сюжета — их композиционное расположение, детализация и т. п.
То есть «фабула» — это то, что показано на картине, а «сюжет» — как оно на ней показано.
Данный тезис, впрочем, довольно хорошо подходит практически к любой разновидности творчества, хотя и, видимо, является слишком общим, чтобы его можно было понять в отрыве от остальных рассуждений и примеров.
Теперь, ну ладно, с творчеством стало понятно, но в инженерии-то? Где сюжет и фабула в программировании и конструировании?
Надо отметить, что я и раньше негласно писал не столько про взгляд на программу со стороны пользователя — то есть на то, как выглядит запущенное приложение — сколько про взгляд на неё со стороны программиста: разработку кода этой программы.
В этом же контексте сие выражается особенно ярко.
Программы, хотя это непричастным может быть не очень очевидно, состоят из фрагментов. Причём считается, что чем сильнее эти фрагменты отделены друг от друга, тем лучше.
Этими фрагментами в современных парадигмах программирования являются в первую очередь функции, которые в ряде случаев упакованы в более крупные структуры — объекты, которые, в свою очередь, упакованы в «пакеты», которые упакованы в «библиотеки».
Перечень функций и их предназначений (часто приписанных к функциям в виде комментариев, или выраженных в названиях этих функций) — это аналог фабулы. То есть полный перечень того, что нужно, чтобы программа вообще работала.
Вообще говоря, любую программу можно реализовать через одни только функции (а можно даже сплошным текстом, чего там), однако её в этом случае будет крайне тяжело развивать и отлаживать.
По этой причине появляется аналог «сюжета»: логическое и «порядковое» структурирование этой программы, которое делается не столько для её работоспособности и реализации функционала (повторюсь, можно было бы и без этого), сколько для программистов же — для тех, кто будет её потом чинить, дополнять, усовершенствовать и т. п.
Поэтому где-то так уже с уровня объектов (и уж точно с уровня пакетов) начинается «сюжет» — представление этой программы тому программисту, который потенциально будет её изучать.
В некотором смысле, объекты можно было бы счесть «фабулой», поскольку они могут быть составной частью реализации или даже «лейтмотивом», а функции, в свою очередь, можно отнести к «сюжету», поскольку само их существование обусловлено тем, что надо как-то упростить разработку, отладку и прочтение, но, несмотря на эту «область неопределённости», общий смысл остаётся тем же: есть «фактическая часть» программы, а есть способ её представления.
Причём, хотя это делают редко, руководство к коду (которое существует отдельно от руководства пользователя и предназначено для программистов) тоже может существовать в двух формах: как «фабула» — просто перечень функций и объектов, и как «сюжет» — такая последовательность преподнесения элементов программы, которая позволяет быстрее понять, что тут вообще делается.
Примерно этим же отличаются справочник и учебник: первый нацелен на быстрый поиск информации о какой-то детали, а второй — на понимание устройства этой области в целом.
В инженерии имеет место примерно то же самое: конечно, каждая деталь должна быть целиком описана на всей совокупности чертежей. Однако при правильном подходе эти чертежи построены и расположены в определённом порядке, упрощающим понимание коллег—конструкторов и тех, кто потом это всё будет изготавливать: вот чертёж — общий вид изделия, вот чертёж, иллюстрирующий связь деталей, вот чертёж детали, а вот чертёж некого фрагмента детали, который плохо видно на других чертежах.
Сейчас за всем этим на самом деле может лежать одна трёхмерная модель, внутреннее структурирование которой сильно отличается от чертежей, но описанная тут их последовательность — «сюжет» — тем не менее, важен для быстрейшего понимания всех нюансов коллегами, исполнителями и, зачастую, самим конструктором.
Что ещё интереснее, отдельный «сюжет» существует и у самого процесса разработки. С точки зрения «фабулы» набор фрагментов кода как бы почти что предопределён: можно разбить программу на фрагменты и иным образом, но требуемую функциональность всё равно ведь надо реализовать, а написать все фрагменты одновременно никак не получится. Даже если прыгать с одного на другой, в каждый момент времени пишется только один из них. И вот та последовательность, в которой всё это написано (с учётом того, что ранее написанное может модифицироваться, дописываться или, наоборот, сокращаться или даже выбрасываться), — что-то типа «сюжета разработки».
Некоторые фрагменты (в частности, лейтмотив или тесно с ним связанное) программисту заранее понятны лучше, чем какие-то побочные, поэтому, скорее всего, первыми появятся именно они. Остальные же будут «достраиваться» на их основе.
Поэтому, вообще говоря, фабула и сюжет — это те элементы, в которых роль логики, пожалуй, наибольшая.
Причём так дело обстоит и в творчестве тоже, поскольку что книги, что музыкальные композиции зачастую тоже сочиняются не в том порядке, в котором их потом воспринимает потребитель.
Конечно, тут уже возможны варианты, поскольку писатель, например, имеет возможность не продумывать всю книгу целиком, а просто начать её писать, надеясь, что потом озарение и логика помогут ему придумывать каждый следующий фрагмент.
Однако есть и вариант, при котором сначала по канве и лейтмотивам почти целиком сочиняется фабула, часть коей — результат мини-озарений, а другая часть — логическое вычисление (обычно связующих моментов, но с некоторой вероятностью такие могут превратиться даже в лейтмотивы). Потом же уже почти целиком сочинённая фабула трансформируется в сюжет — тот порядок, в котором она будет преподнесена читателю. Но вот писаться главы книги при этом могут в ином порядке или же фрагменты могут быть переставлены местами сильно позже своего написания — по озарению или по «вычислению».
Музыка сочиняется и зачастую даже записывается аналогичным способом: отдельными фрагментами, которые потом могут быть переставлены. Причём сочинены оные могут быть в одном порядке, записаны в другом, а смонтированы в песню вообще в третьем.
Правда, для художников тут есть некоторое отличие, поскольку картины редко когда рисуются по отдельным объектам, а гораздо чаще по слоям — с нарастающей детализацией у всех объектов сразу.
Однако и в этом случае тот порядок, в котором на каждом из слоёв художник переходит от объекта к объекту, диктуется, с одной стороны, «внутренним ощущением» художника (воспринимающимся как чувство «очень тянет сейчас перейти вот к этой части картины»), и, с другой стороны, аналогичной другим областям творчества возможностью «построить» одни объекты с опорой на другие.
При этом, в отличие от песни, картина показывается зрителю сразу вся, и художник имеет возможность лишь «управлять взглядом» зрителя, выделив объекты, на которые в первую очередь должен упасть его взгляд, а потом «прочертив» от них «дорожку» к следующей порции объектов, потом к следующей и так далее. Увы, но хотя это более—менее работает, гарантий, конечно, гораздо меньше, чем в книге или в песне: те, конечно, тоже можно перемотать на произвольное место, но их всё-таки обычно слушают в заданном порядке, на то же, что взгляд зрителя пойдёт по запланированному художником маршруту, можно только надеяться.
Однако, несмотря на эти отличия, аналог фабулы сохраняется, как и довольно близкий аналог «сюжета разработки». И даже «зрительский сюжет» в определённой степени присутствует.
В плане «тщательного продумывания», оного в сюжете и фабуле гораздо больше, чем во всех остальных местах (скорее всего, даже вместе взятых), однако и тут, во-первых, в изрядной степени играет роль озарение, а во-вторых, заранее неизвестно, что будет в конечном результате. В том числе, даже во время написания кода или текста книги, изготовления модели девайса и чертежей, а также во время записи музыки.
Кроме того, в-третьих, даже после выхода произведения в жизнь и его широкого признания благодарной публикой нет никакой гарантии, что все противоречия, ошибки и шероховатости оттуда вычищены.
С шероховатостями понятно — идеал недостижим, поэтому как бы всегда можно было сделать лучше, чем было сделано, и зачастую сам автор постфактум придумывает более интересный с его точки зрения вариант отдельных фрагментов фабулы или даже её ключевых частей. Временами это выливается в то, что в продолжении произведения события предыдущей части подгоняются под новую версию, а то и просто всё написано так, будто бы первая часть не такая, какая она есть.
Аналогично, музыканты иногда выпускают новые версии песен: дополненные и исправленные. Художники рисуют ещё раз ту же картину, а программисты ещё раз пишут программу с тем же функционалом, что и раньше, но с новым, более хорошим кодом, а потому лучше поддающуюся дальнейшему расширению.
С инженерами это ещё более очевидно: «новый» девайс делает почти то же, но чуть лучше. Ну там, канва «оно будет кипятить воду, запитываясь от розетки» не поменялась, фабула — внешний вид и устройство чайника — практически тоже, однако теперь он потребляет на 20% меньше энергии на единицу объёма, поскольку в прошлый раз мы допустили некую неоптимальность.
Но это, понятно, усовершенствование — было хорошо, а стало ещё лучше. Однако как «настоящий мастер» мог допустить какое-то «плохо»? Неужели в его произведении есть не просто места для улучшения, а ошибки?
Каждый честный программист вам ответит: «да». В уже выпущенной в продакшн программе почти наверняка есть ошибки, если она больше сотни строк. Причём даже с пятьюдесятью строками можно поручиться, что ошибки там есть с очень маленькой вероятностью, но не что их там нет.
Просто по той причине, что с ростом длины кода количество взаимосвязей растёт нелинейно. А потому лавинообразно растёт и количество способов ошибиться. Поскольку же программа обычно нужна не через миллион лет, а хотя бы через три, несмотря на изрядно продвинувшиеся способы программирования, радикально снижающие вероятность ошибок, и способы отладки, всё равно каждое место программы во всех возможных условиях не проверишь и не продумаешь. Где-то будут белые пятна и где-то там, скорее всего, в определённых условиях всё сработает не так, как должно было бы по замыслу. И чем больше таких мест, тем больше потенциальных ошибок.
И творцы по той же причине тоже не застрахованы. На картинах мастеров до сих пор находятся и анахронизмы, и неверные трактовки библейских текстов, и чисто технические ошибки — в перспективе, распространении света, анатомии, биологии и т. п.
Кроме того, вспомним, что сейчас существует множество видеороликов, где, кроме багов производства (ну там, съёмочная группа отразилась в дверце шкафа или микрофон слегка попал в кадр), научных и исторических ошибок, разбираются ещё и ошибки чисто сюжетные. И даже в отличных, по мнению широких масс, фильмах всё это вполне себе находится. Да-да, мастер—сценарист не только налажал в физике, но ещё и допустил внутренние противоречия в сюжете. И идиотское поведение персонажей — это вообще обычное дело.
Для книг таких разборов заметно меньше, но тоже весьма много. Причём разборов меньше не потому, что писатели больше мастера, чем сценаристы, а потому, что кадры из книги хуже смотрятся в роликах. А так-то ошибок тоже тьма—тьмущая.
Но, тем не менее, ничего страшного. Люди любят и фильмы, и книги, и музыку, и картины. Они пользуются программами с ошибками и неоптимальными девайсами. Поскольку соотношение польза и/или удовольствие к вреду и/или раздражению из-за ошибок оказывается сильно в пользу некоторых творцов или инженеров и их творений, а потому им прощают все эти ошибки.
Однако это не значит, что у «настоящего мастера» всегда идеально продуманные «фабулы» и «сюжеты». Тем более, заранее.
