Прикладная математика эпохи Ренессанса

Изучаю историю математики по книге Виктора Катца. Наткнулся на очень интересную вещь: это схема из предисловия английского математика и мистика XVI-XVII веков Джона Ди к переводу 1570 года "Элементов" Евклида на английский язык. Сам перевод сделал Генри Биллингсли и выполнил его очень качественно, в книге было около 1000 страниц, в ней также были раскладные (как в детских книжках) схемы для демонстрации в трех измерениях тел и операций над ними. Однако предисловие Ди и, в особенности, упомянутая схема сами по себе представляют не меньший интерес.

На схеме Джон Ди попытался отразить структуру математики (математических наук, искусств и связей между ними) в соответствии с представлениями того времени, в частности, по характеру актуальных задач. Естественно, мистика туда тоже примешалась, хотя, как ни странно, она там не вызывает негативных эмоций.

Таким образом, древний английский рисунок, фактически, дает нам "карту" прикладной математики того времени. Я как специалист в данной области (и человек, который свою специальность считает самой лучшей на свете) мимо пройти не мог и по различным цифровым копиям, фрагментам таковых, по тексту Катца и другим, по словарям староанглийского языка и т. д. (та еще была работенка) постарался восстановить и перевести текст Ди. На 100% у меня это не получилось - даже на английском мне качественные копии или, что было бы еще лучше, перерисованные схемы, не встретились, но я надеюсь, что читателям будет интересно.

Жизненный путь: Pilgrim5

Не могу не рассказать. Pilgrim5 - это не язык программирования, это система имитационного моделирования, с которой я работал очень долго и очень много. Разработана она была еще где-то в начале 90-х годов моим научным руководителем Емельяновым А. А. (в то время, конечно, он еще моим руководителем не был, потому что еще нечем было научно руководить). Система имитационного моделирования - это такая штука, которая позволяет настраивать "узлы", "транзакты", "генераторы" и "пути", то есть модели процессов, запускать их и получать всякую статистику. Все, что можно представить в виде системы массового обслуживания, можно представить в виде модели на Pilgrim и обсчитать.

Система имитационного моделирования в данном случае представляет собой просто статическую библиотеку pilgrim.lib, которая ликнуется к проекту, и еще пару заголовочных файлов, которые с помощью инструкций препроцессора до неузнаваемости меняют текст основного исходника проекта. То есть сами не меняют - просто программист должен из-за этих макроопределений набивать в файл такое, что ни капли не похоже на C-шный текст. Вот примерчик:

Такая модель создания хм... моделей оригинальна и, когда начинаешь работать в этой области (а я начал в 1998 или 1999-ом в рамках институтского курса), весьма удобна. Этот мизерный по объему и по сравнению с его же функциональность код, сам создает и окно, и несложные инструменты для анализа процесса, и даже графики строит кое-какие. Конечно, когда требуется модель более сложная, с более богатой визуализацией, с дополнительными расчетами, с подключением к БД, со всякими трюками, наподобие придуманного мною в свое время "парного забега" (долго объяснять) или чем-то подобным, возникают проблемы, которые таким вот нестандартным вынужденным синтаксисом только усугубляются. Но речь сейчас не об этом.

Любопытно то, что даже по сравнению с OpenGL, Pilgrim5, наверное, еще более глубоко и профессионально изученная мною технология. С этой системой я работал долгие годы, создав много крупных и мелких моделей разной степени сложности для разных целей. Вот самые памятные проекты:

• модель издательства, с учетом работы отделов сбыта, производства, букинистики и т. д. и т. п. с визуализацией, в которой все вертелось, бегало, уменьшалось и увеличивалось, динамически отображая состояние процесса по многим показателям (заказная);
• модель родного деканата Института компьютерных технологий МЭСИ;
• модель системы дистанционного обучения и взаимодействия с ней обучаемых с учетом индивидуальных учебных планов, курсов, дисциплин, промежуточного и итогового контроля и прочего, и прочего - для этой модели впервые пришлось подключать БД, из которой программа дергала данные, в БД же была вынесена и большая часть интерфейса для ввода данных, и все проверки этих данных на корректность и целостность, а сама модель стала ядром моей кандидатской диссертации;
• три больших модели "Структурированной системы мониторинга инженерных систем" (СМИС) - тут тоже понадобилась БД, но не потому что данные были сложные, как в предыдущем случае (там были курсы, темы внутри курсов, индивидуальные планы), а потому что данных было очень много, а само моделирование производилось помиллисекундно (заказная).

Помимо этого я разработал на базе Visio конструктор для имитационных моделей, который позволяет перевести одним щелчком это:

в текст на C, который гарантированно компилируется.

Интересно, что когда ты создаешь модели в Pilgrim-е, ты пишешь на C и не на C одновременно. То есть в тех аспектах, которые выходят за рамки терминологии Pilgrim-a ты должен соблюдать синтаксис и логику C, но большую часть времени ты мыслишь категориями теории массового обслуживания и имитационного моделирования. Программируя внутри Visual Studio, выполняя те же операции и шаги, что и обычно, ты при этом работаешь в основном не с языком программирования, а с чем-то созданным поверх этого языка. Любопытное ощущение.

В общем, работ было много, интереса тоже, хотя в этом году я принял решение больше Pilgrim-овских моделей не разрабатывать - надо в жизни что-то менять иногда. Думаю, может стоит разработать свою систему моделирования? Позаимствовать все лучшее, добавить своих идей, сменить концепцию... и не трогать препроцессор!

Математика и... клиенты, "которые не знают, чего хотят"

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

В целом рекомендуется работать и формулировать требования к модели на самом высоком приемлемом уровне абстракции. Здесь можно столкнуться с традиционными сложностями: хорошо известный среди программистов тезис о том, что «заказчик не знает, чего хочет», в общем случае неверен, поскольку заказчик точно знает, что он хочет получать, но на одном из высоких уровней абстракции (бизнес-продукт, бизнес-цель). Специалистам же по информационным технологиям свойственно, напротив, мыслить и работать на нижних уровнях абстракции (исходный код, переменные, библиотеки, окна). В этом ключе система Pilgrim 5 интересна тем, что во многих случаях ее собственная терминология (узлы, транзакты, семейства и так далее) может стать неким общим знаменателем между заказчиками и исполнителями, поскольку позволяет описывать объекты и процессы вне зависимости с одной стороны от их природы, а с другой – от низкоуровневых деталей их представления в компьютере.

Собственно, это верно везде. Например, в случае с копирайтингом: заказчик объясняет, чего он хочет, ты выполняешь работу, она нравится заказчику, но в этот момент благодаря тому, что сам текст - это инструмент сближения уровней абстракции, клиент понимает, точнее, оказывается способен более четко объяснить задачу (которую приходится выполнять за те же деньги). Это может и неприятно, но не трагично и даже логично (с позиции описанной выше).

Математика и... ООП

Коллеги недавно задали тему для обсуждения, приведя следующий фрагмент:

...известный специалист по программированию - Александр Степанов, который работая в Bell Labs участвовал в создании C++ вместе c Бьерном Страуструпом, а впоследствии, уже по приглашению в HP Labs, написал Standard Template Library (STL). Александр Александрович полностью разочаровался в парадигме ООП, в частности он пишет: "Я уверен, что ООП методологически неверна. Она начинает с построения классов. Это как если бы математики начинали бы с аксиом. Но реально никто не начинает с аксиом, все начинают с доказательств. Только когда найден набор подходящих доказательств, лишь тогда на этой основе выводится аксиома. Т.е. в математике вы заканчиваете аксиомой. Тоже самое и с программированием: сначала вы должны начинать развивать алгоритмы, и только в конце этой работы приходите к тому, что вы в состоянии сформулировать четкие и непротиворечивые интерфейсы. Именно из-за этой неразберихи в ООП так популярен рефакторинг - из-за ущербности парадигмы вы просто обречены на переписывание программы, уже в тот самый момент, когда только задумали её спроектировать в ООП-стиле".

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

Как и во многих других случаях точка зрения автора имеет право на существование, но не является единственно верной. В ней можно усмотреть явную ошибку с позиционированием, скажем так, "классов относительно математики" - приравнивание классов к аксиомам. Не совсем понятно на чем вообще базируется аналогия - это сравнение, на мой взгляд, достойно "астронавта от архитектуры" как их называет Спольски (Спольски Дж. "Джоэл о программировании..." - СПб.: Символ-плюс, 2008). Прибытие к неприятным выводам происходит при поддержке весьма неоднозначного сравнения.

Если уж на то пошло, то классы в ООП разумнее сравнить в математике с множествами простых, вещественных, положительных и прочих чисел, применимых к этим числам операций и так далее (это я как математик говорю), а не с аксиомами.

Заявление по поводу начала в математике с доказательств странно само по себе - начинается в математике с фактов, продолжается абстракциями, то есть с выбора того, как мы что обозначаем и какие действия можем выполнять над теми или иными (внимание!) объектами... ООП проще и логичнее сравнить со всей формальной системой записи математических задач и выражений.

По поводу ущербности ООП в принципе не могу согласиться тоже. В частности, я занимаюсь имитационными (симуляционным) компьютерным моделированием в системе Pilgrim 5, где существует набор узлов типа "Очередь", "Сервер", "Склад" и т.д. (один уровень абстракции), на которые при составлении каждой конкретной модели ты смотришь как на "Менеджера", "Датчик", "Стопку бумаг", "Склад книг" и так далее (второй уровень абстракции) - как тут без ООП не могу себе даже представить и, честно говоря, альтернативы кажутся мне ужасными и темными.

Рефакторинг действительно популярен в ООП, тут спору нет (более или менее, чем в структурном программировании, - не могу сказать, но интуиция подсказывает, что дело здесь вообще не в парадигме, а в качестве изначального кода), но это не следствие неправильности или сложности парадигмы, а следствие сложности ее применения/воплощения. Понять, что такое классы и объекты не сложно, сложно подобрать подходящие для каждого конкретного случая абстракции, иерархии и определить "правильные" способы взаимодействия между элементами, то есть интерфейс - это процесс уж очень творческий. Кстати, ссылка на рефакторинг в связке с тезисом об изменчивости интерфейса вообще неуместна, поскольку согласно Фаулеру (Фаулер М. "Рефакторинг: улучшение существующего кода" - СПб.: Символ-Плюс, 2008):

Рефакторинг (англ. refactoring) — процесс изменения внутренней структуры программы, не затрагивающий её внешнего поведения (то есть именно интерфейса - прим. мое) и имеющий целью облегчить понимание её работы.

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

Вот в ИТ-образовании я, действительно, специалист значительно повыше среднего, поэтому знаю, что говорю. Обучение ООП зачастую начинается с его трех китов-постулатов, а не с того, что есть классы и объекты, удачные классы и объекты, а также удачное ПО, созданное на их основе. Прибегая вновь к сравнению с математикой - это то же самое, что в 1-ом классе, не рассказывая про цифры и +/-, начинать обучение со слов "Создавая свою формальную знаковую систему, нужно иметь в виду..."

Еще пример из собственного опыта: когда мы изучали Turbo Vision (TV) на втором курсе (1996 год), мы изучали его не в рамках ООП, а в качестве некоего "средства, облегчающего построение интерфейсов", где "интерфейс уже как бы есть, и нужно только указать, чем твой будет отличаться от стандартного". Логичнее было бы начинать изучение с тезиса: "Смотрите, какую штуку из классов и объектов сварганили, как много она может вам дать, и как с ней удобно работать - вы можете научиться строить такие же удачные (или неудачные - в TV было множество проблем) иерархии и библиотеки из классов и объектов предметной области".

Если взять человека, который пришел к ООП "правильным" путем, я думаю, что для него приведенный вначале фрагмент с проблемами будет не то что спорен, непонятен он будет в силу надуманности и смехотворности проблем.