ТРИЗ, Haskell и функциональное мышление
При слове ТРИЗ, часто вспоминают тезис «идеальная система — та, которой нет (а ее функция при этом выполняется)». Как хороший админ, который не появляется в офисе, а все при этом исправно работает.
Функция и система — критически важные понятия в ТРИЗ, говорят даже о функциональном стиле мышления. Правда при этих словах лично у меня сразу возникает ассоциация с функциональными языками программирования.
Попробуем посмотреть, насколько органично идеи функционального мышления ТРИЗ отображаются на Haskell, одном чистых функциональных языков общего назначения.
Функция
Функция — модель изменения свойства объекта функции («изделия») носителем функции («инструментом»).
Инструмент — то, с помощью чего мы совершаем некую работу, т.е. что-то меняем. Как правило именно его требуется усовершенствовать или создать. Соответственно именно носитель функции обычно подразумевается под словом «система» во всех ТРИЗовских рассуждениях про оную.
Изделие — то, что мы изменяем (обрабатываем) при помощи инструмента.
Главная функция — потребительское свойство, ради удовлетворения которого создается техническая система.
Сама функция задается обычно простым глаголом, отражающим суть процесса (не специальным термином, чтобы не мешала инерция мышления), в формулировку включают носитель и объект функции.
Например: молоток перемещает гвоздь; метла перемещает мусор; кружка удерживает кофе; пылесос перемещает пыль; топливо перемещает ракету.
Рассмотрим, в частности, чашку с кофе.
Чашка удерживает кофе.
Носитель функции (инструмент) — чашка, объект функции — кофе, функция — удерживать.
-- Задаем типы входных данных и результата выполнения
-- Предположим, типы данных Чашки и Кофе уже где-то заданы
hold :: Cup -> Coffee -> Coffee
-- вызываем функцию hold - "удержать" с параметрами в виде конкретных чашки и кофе
cup `hold` coffee
Функция hold должна быть полиморфна, поскольку чашка может удерживать не только кофе и кофе можно налить не только в чашку:
-- На входе пара сущностей типа а и b, на выходе измененная сущность типа b
hold :: a -> b -> b
-- что будет, если налить кофе в термос
thermos `hold` coffee
-- что будет, если пролить кофе на рубашку
shirt `hold` coffee
Инструмент и изделие могут изменяться, а суть их взаимодействия, выраженная функцией, остается прежней. По статистике большинство парных функций между элементами технических систем можно описать тремя десятками глаголов (перемещать, удерживать, нагревать, поглощать, информировать и пр.). Каждый из них с точки зрения Haskell-реализации представляет собой полиморфную функцию. Как, впрочем, и остальные глаголы естественного языка.
Обратная функция
В реальном мире всегда есть и обратная функция — действие изделия на инструмент (третий закон Ньютона никто не отменял).
Например, обрабатываемый металл затупляет сверло, нерадивый ученик утомляет преподавателя, файл уменьшает свободное место на диске.
В примере с кофе оно нагревает и пачкает чашку.
Как правило обратная функция нам вредит (износ инструмента, доп.затраты), однако в иных ситуациях мы можем извлечь из нее пользу. Например, погреть руки о теплую чашку, будучи в прохладном помещении.
hold:: a -> b -> b
warm :: a -> b -> b
cup `hold` coffee
coffee `warm` cup
Цепочки функций
В случае, когда число элементов системы больше двух (т.е., фактически, всегда) их рассматривают попарно, получая цепочки функций.
Например, на рисунке ниже рука несет (перемещает) поднос с чашкой, поднос удерживает чашку, чашка удерживает кофе.
((arm `move` wrist) `hold` cup) `hold` coffee
Избавимся от скобок, задав левую ассоциативность
infixl 9 hold
arm `move` wrist `hold` cup `hold` coffee
Запись на Haskell очень близка к записи на естественном языке.
И цепочка в обратную сторону: кофе нагревает чашку, чашка нагревает блюдце, блюдце нагружает руку.
infixl 9 warm, weight
coffee `warm` cup `warm` wrist `weight` arm
Понимание главной функции и взаимодействий между элементами позволяет оптимально выбрать границы системы, включить лишь то, что нужно для выполнения целевой задачи (ничего не упустив) и не усложнять модель сверх необходимого.
Система, которой нет …
Нам нужна функция, точнее результат ее применения, а инструмент сам по себе не нужен. Это расходный материал, привлекаемый лишь в силу необходимости.
Удерживать кофе может джезва, чайник, термос, блюдце и стол и рубашка (если кофе неосторожно пролили).
Мы даже были бы не против, если кофе САМО себя удерживало. Как это происходит, например, с водой в невесомости на космической станции.
Однако на зацикленных формулировках вроде «кофе удерживает кофе» в ТРИЗ останавливаться не принято, поскольку она бесполезна с практической точки зрения — не дает информации об элементах, за счет которых достигается результат.
С точки зрения программирования такая рекурсивная формулировка плоха тем, что здесь нет условия окончания рекурсии.
Нужно уйти в глубину и указать какие именно части (подсистемы) обеспечивают выполнение функции.
Жидкость принимает в невесомости компактную форму за счет сил поверхностного натяжения. Т.о. более подходящим описанием ситуации будет: поверхностный слой удерживает внутренний объем кофе.
Можно представить весь объем кофе как матрешку слоев, каждый из которых удерживает друг друга. При этом основную работу делает внешний слой.
-- Пусть первый слой - поверхностный, пятый - самый глубокий
let coffee = [layer1, layer2, layer3, layer4, layer5]
head coffee `hold` tail coffee
Впрочем, если нам важно влияние слоев друг на друга (например, в плане поглощения света),
можно изобрести велосипед и описать последовательные взаимодействия явно.
Рекурсивная природа явления сохраниться, но за счет понимания взаимосвязей подсистем мы сможем задать условия выхода из рекурсии и обратить ее себе на службу.
-- Функция "удерживать", которая выводит свою полную формулировку
hold :: String -> String -> String
hold tool "" = tool
hold tool workpiece = tool ++ " -> holds -> " ++ workpiece
-- Функция "удерживать себя".
-- Принимает на вход нарезанный слоями объект и
-- последовательно вызывает обычную функцию "удержать"
-- для каждого слоя и оствшегося объема
selfHold :: [String] -> String
selfHold [] = ""
selfHold (x:xs) = x `hold` selfHold xs
-- запускаем самоудержание трехслойного объекта
selfHold ["Layer1","Layer2","Layer3"]
в итоге получим
Layer1 → holds → Layer2 → holds → Layer3
Рекурсивность реализации никуда не исчезла, но стала конструктивной, а не бессмысленно зацикленной.
Тоже самое можно записать и короче, через свертку списка:
foldl1 hold ["Layer1","Layer2","Layer3"]
Заключение
Видение технической системы как ткани из функций, связывающих ее во едино и определяющих суть и предназначение, чрезвычайно роднит ТРИЗ с функциональными языками программирования, в которых функция — основная управляющая конструкция.
Рассмотренный подход служит хорошим подспорьем в плане декомпозиции задачи и управления сложностью модели.
