Неиспользование статической типизации

[metaclass]

Столкнулся с тем, что наиболее внятно задача, которую я решаю, укладывается в Clojure и не укладывается (без частичного выкидывания статической типизации) в скалы-хаскели-C#-F#.
Вернее даже не выкидывание, а просто получается имитация типичного для Clojure типа данных Map[Symbol,Any] и использование его во все поля.

Можно, конечно, было бы убрать вообще всю логику, вплоть до SQL-запросов, из БД и писать запросы для ORM типа slick, но это в данном случае натягивание совы на глобус, более чем бессмысленное, т.к. статически типизированный результат запроса в ORM нужно будет превратить обратно в нихрена не типизированнный датасет типа Seq[Map[Symbol,Any]] и сериализовать его в json для клиента.
Или прикрутить shapeless (https://github.com/milessabin/shapeless) и навернуть extensible records поверх HList на предмет того, чтобы типовыводилка генерила еще и метаданные, но в итоге получится что-то совсем печальное и малопонятное.

Comments

[metaclass.livejournal.com]

Да тупо какая-то сегрегация классов задач.
Некоторые ну влет укладываются на статическую типизацию, какие-то статические маппинги, ОРМ и прочее.

А вот тупо "взять из базы результат запроса и показать пользователю" тут даже никакое ООП нахрен не нужно, ибо каждого из действующих классов экземпляр строго один, наследование только где-то во внутренностях используемых библиотек, разве что реализация доступа к БД сделана через фабрики коннектов :)
И FP тут только если сильно повезет и результат запроса нужно будет как-то нетривиально обработать.

[jakobz.livejournal.com]

Зависит от объема задачи и количества внешних нетипизированных концов. Если у тебя с одной стороны - SQL-база, для которой надо жесть писать чтобы типы прилепить, с другой стороны - JSON-сервис, а посередине совсем децл логики - типизировать такое на порядок геморойнее чем написать без типов.

С этой точки зрения мне очень симпатичен подход typescript-а - хочешь смотри на ворнинги, хочешь забей и смотри как оно реально в рантайме падает.