Молоток, лопата и порождающее проектирование

В июле на isicad.ru было заметно слово «молоток». Сначала в статье BIM – единорог для проектировщика на примере домашнего применения молотка излагались критерии разумного применения BIM, затем, в публикации СтройКонтроль + BIM: интеграция с Revit, представленное решение было названо простым как молоток. (Невольно вспомнилась яркая и заслуженно нашумевшая статья годичной давности Как я делал модель штыковой лопаты в КОМПАС-3D и SOLIDWORKS).

Несколько слов о простоте и сложности. Есть простота примитивности, неспособная породить нечто эффективное, долгосрочное, массовое, адаптируемое и т.д. А есть простота как результат обобщения многих этапов сложного развития и многих частных решений, иногда завершающихся радикальным или даже гениальным прорывом упрощающего обобщения.

А причём здесь порождающее проектирование (generative design, GD)? На мой взгляд, распространённая трактовка и соответствующий ей стиль нынешних описаний этого модного направления инженерного ПО хорошо отражает промежуточность состояния развития перспективной методологии и технологии. Обладая значительной содержательностью и некоторыми примерами промышленного использования, GD сегодня описывается как нечто эклектичное, сложное, сочетающее в себе неясно чем объединенные методы, иллюстрируемое причудливыми очень частными примерами и нуждающееся в значительном подкреплении пафосными рекламными лозунгами. К тому же, всё это наводит на мысль об известной притче, которую isicad.ru иллюстрировал на примере PLM своей обложкой N150 . Недавняя статья Порождающее проектирование порождает новую эру высокоэффективных продуктов, хотя она и вынужденно не лишена вышеуказанных свойств, всё же сообщает читателю кое-какую полезную информацию о GD.

Возможно, когда-нибудь GD будет очень просто характеризоваться как сочетание (1) универсального механизма, который по математической непроцедурной модели порождает пространство всех объектов (решений) интересующего нас класса (молотков, лопат, стульев, утюгов,...), и (2) построенного как приложение решателя, автоматически или полуавтоматически (лучше, если — тоже на основе непроцедурно заданных уточняющих ограничений) выбирающего из полученного пространства объекты по заданным критериям.

Мне нравится думать, что GD существенно ассоциируется с вполне классическим подходом программирования в ограничениях (constraint programming) или – что точнее и предпочтительнее для меня – с методом недоопределенных вычислений, разработанным в академическом коллективе, из которого когда-то вышла команда ЛЕДАСа.