Доброго часа!

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

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

Аналогичная ситуация с методологиями разработки. Замечательная идея сразу спроектировать систему, а потом её реализовывать в виде кода раз за разом разбивается о суровую реальность, где системный инженер просто не в состоянии предусмотреть всех нюансов, которые могут возникнуть при реализации архитектуры, заложенной им. Нет, я не говорю, что примеров успешного проектирования нет. Но соотношение успехов к провалам в данном вопросе ИМХО заставляет задуматься. Под провалами я тут понимаю в т.ч. и успешно реализованный проект, где код в конечном счёте значитеьно расходится с моделью, или модель допиливалась уже походу кодирования. Из-за того, что нет внятных механизмов анализа систем приходится выполнять массу работы, направленной на тестирование программ. При этом объём таких работ иногда может превышать трудозатраты на написание системы.

Даже в тех областях, где есть вполне применимый математический аппарат, он просто не используется. Для примера, РБД опираются на подобный аппарат. Но многие ли программисты применяют его при проектировании БД и написании запросов?

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

Что вы думаете по этому поводу? Может быть уже есть какие-то языки, подходы, методики разработки, платформы, фрэймворки, позволяющие поставить огромный багаж математических знаний, накопленных человечеством за столетия, на службу программисту?

P.S.: прошу прощения, если мои мысли показались кому-то слишком пространными, а их изложение - слишком объёмным.

УнрегистередА нахрен сдалось мыться? Энто вредно.

Ты в школе минимум четыре года долбил тригонометрию в самых извращенных формах и решал системы линейных уравнений. А в ВУЗе - решал дифуры аналитическим методом.

И? Пять лет - коту под хвост - ты ни разу эти знания так и не применил на практике.

Культура говоришь?

При том, бьюсь об заклад, такие слова как inversion of control и dependency injection - тебя до сих пор ставят в тупик.

Так что надо было в школе изучать? Еще один метод определения точки пересечения медианы с
биссектрисой или азы формальной логики?