А зачем «это» делать в языке с типами

чтобы избежать ручного труда по описанию моделей и парсеров

все языки без типов не избегают требований описаний структур

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

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

Если говорить про СУБД, так там точно не меньше работы ормка точно так же требует схему описать

ущерб читаемости, и не в ботлнеке (сам таким иногда страдаю)

+

Да, сорри, я не убеждён что так надо делать, просто хотел понять что правильно донёс мысль. Со всеми пунктами согласен более менее

Т.е. в итоге тот же "бойлерплейт" кейсклассов супротив ручных конвертаций проверок, комментов это как фибоначчева куча против биномиальной.

Первая делает всё то же самое только скопом, и иногда, если действий много, т.е. начиная с какого-то размера их выгоднее делать скопом

Но если говорить про фронтовые браузерные языки, я пробовал только жс, тс, кложурскрипт, пурскрипт и скалу.
И мне больше всего понравился тс

Но жс не сильно уступает

еще из диких идей, в форе не хватает раздела обработки ошибок

for {} yield {} catch {}

Оборачиваешь все в айзер/валид

найс

Трансформируешь монады

Профит

Еее