Здравствуйте, Shmj, Вы писали:

S>Почему все верят, что декларативный подход рулит и на порядок упрощает работу?

разработка софта в отличие от, например, строительства еще очень молода.
Люди ищут оптимальные подходы. Какое-то время казалось, что отделить разработку форм от обработки данных хорошая идея.
Скорее всего причина только в этом. Есть разные идеи и у каждой есть сторонники.
Но лично мое мнение, что победит "код как данные", посмотрите на успех elm, кложури и кложескрипта, https://github.com/fsprojects/Fabulous
websharp, fsbolero и т.п.
Любой UI это иерархия элементов(связанный список), если у нас в ЯП есть "list comprehension"(удобный для понимания человеком способ представления списков),
то проще и эффективней описать UI именно так. Отображение данных при этом на порядок отображается, так же как и DRY и прочие вещи.

Здравствуйте, Shmj, Вы писали:

S>Почему все верят, что декларативный подход рулит и на порядок упрощает работу?

разработка софта в отличие от, например, строительства еще очень молода.
Люди ищут оптимальные подходы. Какое-то время казалось, что отделить разработку форм от обработки данных хорошая идея.
Скорее всего причина только в этом. Есть разные идеи и у каждой есть сторонники.
Но лично мое мнение, что победит "код как данные", посмотрите на успех elm, кложури и кложескрипта, https://github.com/fsprojects/Fabulous
websharper, fsbolero и т.п.
Любой UI это иерархия элементов(связанный список), если у нас в ЯП есть "list comprehension"(удобный для понимания человеком способ представления списков),
то проще и эффективней описать UI именно так. Отображение данных при этом на порядок упрощается, так же как и DRY и прочие вещи.
UPDATE. еще очевидный плюс — один яп вместо местного диалекта (XAML и т.п.) или привязка к дизайнеру(который еще и чувствителен к изменениям).