Разбираемся с идеологическим противником

Регулярно слежу за несколькими десятками гуру computer science, и вот один из них — профессор Gregor Kiczales из университета Британской Колумбии, легендарный автор аспектно-ориентированного программирования (готовлю курс, скоро выйдет, в котором разбираем три десятка стилей programming in small, и в частности АОП) и учебника "The Art of the Metaobject Protocol". Так вот, на его университетской страничке самой первой избранной работой указана вот эта: "Effectiveness Sans Formality"

https://www.cs.ubc.ca/~gregor/papers/kiczales-oopsla-07-for-printing.pdf

Доклад был представлен на авторитетной научной конференции ACM по объектно-ориентированным системам OOPSLA'07.

Его выступление тогда вызвало биполярную реакцию аудитории: одни говорили, что это самое глубокое, что они слышали за последние сто лет, а другие заявляли, что не поняли ни слова. Меня лично, несмотря на наши принципиальные расхождения (Kiczales — за анти-формализм в разработке), впечатляет его решимость докопаться до истинной природы программирования, несмотря ни на какие препятствия, чем и я пытаюсь заниматься, поэтому испытываю глубочайшее уважение к его намерениям. Тем более, что он (как и я — 3-й уровень логического мышления над кодом разбираем в СильныхИдеях) учит тому, как создавать программы, которые максимально "похожи" на их дизайн, что здорово снижает сложность системы.

Я считаю, что Грегор поднимает центральную проблему программирования. Под формализмом, который я пропагандирую, подразумеваю веру в то, что в идеале мы должны относиться к программированию как к математической теореме, которую нужно доказать (хотя на 98% эти теоремы получаются очень скучные :), или как к машине, которую нужно спроектировать. Пожалуй, больше всего ассоциируется с этой идеей Эдсгер Дейкстра. Грегор же утверждает, что, конечно, каждая программа содержит теоремы и может рассматриваться как машина, однако воспринимать их как таковые в повседневной разработке — значит упустить их наиболее существенные особенности.

Грегор замечает, что "на самом верху всё неформально" — в том смысле, что для большинства программ нету, да и не может быть, чётких формальных требований. Большинство программ живёт в социальном контексте, где нету формализованных правил (и в целом всё печально :). Формалистский же подход предполагает полную, точную, непротиворечивую спецификацию требований. Но люди, организации, и пользовательские требования к системе не формализуются. Каковы формальные требования к текстовому процессору? Как можно вывести таблицы стилей символов и абзацев из самой природы набора текста в редакторе? Труднейшая часть процесса создания ПО заключается не в реализации требований, а в их разработке, и ожидать формального подхода от заказчика-неайтишника просто нереально.

=

Грегор также говорит, что "вещи неформальны в самой своей сути". Не будем скатываться в философию, кому интересно, порекомендую "Структуру реальности" Дойча. Конечно, и я считаю, что на самом деле всё ещё хуже :) Разработка не просто субъективна, она буквально хаотична.

В ответ на крошечные колебания требований дизайн системы вполне может измениться резко и глобально. Например, я встречал просьбы менеджеров в духе "Нам надо срочно 2-й этаж 22-этажного здания расширить на 1 сантиметр. Это же всего 1 сантиметр, уверен, что есть такая команда во фреймворке, которая сделает это легко и просто, без затрагивания всех остальных этажей". Ну и конечно понимание самим программистом дизайна системы практически всегда очень слабенькое, и его решения-приляпки только расшатывают общую схему. Даже неплохие программисты, например, весьма посредственно проходят мой курс по объектно-ориентированному анализу и проектированию — самый неформальный из всех.

Постоянно говорю про такой важнейший факт, что систему в целом надо воспринимать прежде всего в контексте её развития — это всегда будет незавершённая работа, она никогда не заканчивается. Идеалы математики и инженерии заключаются в том, чтобы оптимизировать проектный дизайн по измерениям простоты и надёжности, но когда требования к системе турбулентны и постоянно хаотично меняются, в такой оптимизации конечно нету смысла.

=

Антиформализм на самом деле имеет весьма долгую и большую историю в интеллектуальной среде: всякий раз, когда возникает движение за сведение некоторой сложной области к "просто" формальной системе, сразу возникает и движение против этого, что особенно выражено в ИТ. Проблема в том, что все антиформализмы лучше объясняют то, чем "это" не является, нежели предлагают конструктивную альтернативу (потому что по своей природе "это" неформально :). Получается много метафор, хайпа и размахивания руками, граничащих с мистикой — всяческое "системное мышление".

Однако системы строят не метафоры, не мистики и не системные мыслители (только тут чётко надо разграничивать подобное хипстерство и взрослую системную инженерию). Именно эту проблему Грегор обозначил в своём названии: "Эффективность без формализма". Эффективность означает наличие какого-то способа заставить вещи работать, даже если мы отвергаем формализм как объяснение того, как они должны работать. Я бы перефразировал это как поиск конструктивного способа построения неформальных систем. Это действительно центральная проблема мэйнстрима, которую пытаются решать в основном на организационном уровне, с помощью всяческих аджайлов.

Да, но зачем нам изобретать заумные методы для создания неформальных систем? Они же уже находятся прямо перед нашим носом — в нашей повседневной практике!

=

Неформальные системы - это просто "сломанные" формальные системы.

=

Идеология формализма даёт ценнейшие способы рассуждать о системном дизайне, ориентируясь на такие вещи, как простота, надёжность, эффективность, "анализируемость". Эти свойства могут быть доведены до оптимальных значений, тогда мы получаем зафиксированный окончательный дизайн. Но, действительно, когда мы рассматриваем проекты в длительном процессе разработки, эти свойства на самом деле весьма далеки от оптимальных. Когда вы оптимизируете гибкость и адаптивность, вы также хотите, чтобы на первый план вышли и другие свойства. Вы хотите беспроблемно поддерживать наполовину готовые, наполовину работающие системы.

=

Если вам интересны подсказки для построения неформальных систем, достаточно понаблюдать, где практика программирования расходится с его идеологией. Хороший пример — копипаста с StackOverflow. Мы все считаем, что копипаста — это аморально и чуть ли не незаконно. И все же все мы делаем это. Постоянно. Этот факт о чем-то нам говорит. Он говорит о том, что хотя в идеале можно зарефакториь любую копипасту в некую форму параметрической абстракции, это будет далеко не всегда практично.

И вот сегодня тут случился настоящий прорыв с явлением ChatGPT и всевозможных AI-ассистантов, уже активно встраиваемых в IDE. Копипаста фактически официально декриминализирована, и AI стал наверное самой сильной и яркой формой антиформализма из всех в программировании. Мы не имеем ни малейшего представления, как AI генерирует код, но современный антиформализм развивается прежде всего в этом направлении. ChatGPT и промпт-инженерия стали новым знаменем антиформалистов.

=

Есть конечно тут и немало конформистов, предлагающих рассматривать эту тему как вопрос, относящийся к конкретной области задач. Исходя из того, что вы пытаетесь сделать, вам либо нужна строгость и прежде всего сильная система типов, чтобы гарантировать, что система делает именно то, что должна делать, либо вам не нужна строгость, а само решение желательно выпустить побыстрее, не особо заморачиваясь. Ну, вот если бы это ещё и работало :) Да, быстренько запилить достаточно объёмный проэкт на коленке на троечку с минусом, конечно, под силу и многим студентам, но я всё время подчёркиваю, что проектирование — это не про "сделать более-менее качественно под ключ", это прежде всего про то, что наш проект будет развиваться вдолгую, многие годы, а то и десятки лет, и крайне важны и его лёгкая понимаемость новыми разработчиками, и лёгкая расширяемость и сопровождаемость, а это без качественного проектирования будет требовать экспоненциально растущих расходов.

P.S. Кстати, после 2007-го Gregor Kiczales больше ничего по теме антиформализма не предложил, а формальные методы развиваются очень здорово.

Источник: www.cs.ubc.ca

Комментарии: