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