JS тоже был идеален для тех задач, под которые он создавался. А когда писали Java, проблемы боксинга не существовало.

синтаксис дело привычки, хоть дырками на перфокартах

два мега скобочек этому перфокарту!

ну нет

Почему вы так категоричны?)
Я лишь хочу сказать, что прогресс не стоит на месте. Вот мы писали MVC всегда и было всё прекрасно. Потом наш UI становится всё сложнее и взглядом MVC становится недостаточно.
Потом появляется React. Я думаю никто не станет спорить, что он изменил подход к разработке пользовательских интерфейсов.

Не думаю что будет очень плохо подумать над решениями существующих проблем)

"ну нетЪ я привык к такому , а остальное гавно"?

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

Как раз с хаскелем вроде все понятно.
Авторы всегда позиционировали его, как это исследовательский язык,
который расширяется одной строчкой {-# LANGUAGE ...

Хорошо исследовать возможности стат. типизации, но никогда не будет общепринятого сабсета и поддержки тулинга.

Клиентские приложения (в отличие от больших, распределенных систем) довольно самодостаточны, и проблемы там примерно одинаковые. Так что «архитектуры» там работают. Точнее выполняют свою роль)

Ну так надо тогда сразу говорить, что речь идет исключительно о тонких клиентах

позвольте не согласиться про  одинаковые проблемы в клиентских приложениях

Можно поспорить насчет ваших "сложных систем", которые все таки институцко-исследовательские.

Все таки сложные системы разрабатываются годами десятками людей одновременно.
Это как раз то чем занимаются люди на продакшене в больших компания с тем же react.

Кстати, реляционная алгебра довольно хорошо показала себя в моделировании данных.
Думаю её точно также можно и применить к моделированию состояния (то есть тех же данных, только которые в памяти).
Собственно что я сейчас и «исследую»)

Я просто не верю, что для среднего клиентского приложения надо писать 100kloc, где 60% кода - управление зависимостями.
Вы, конечно, сказажете, что нафига так делать, просто так не делайте, но это не работает)

Это как с тем же реактом. Он замечателен для создания простых визуализаций - условных экранов. Как только речь идет о толстой логике, все, до свиданья

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

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

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

Да сделаем, вот и изучаем всё подряд))

Может и любят, но пока все серьёзные проекты где я работал - SQL. Есть ещё и редиски всякие и остальное, но оно лишь как дополнение

Ну так опять же, вы берете тонкие клиенты. С довольно простой структурой данных.