Но точно так же может быть, что это напускная тупость, которая так популярна среди троллей. Это не напускная тупость, это удивление перед бесконечным разнообразием жизни.
Меня давно интересует парадокс - как в общем неглупые люди могут заниматься какой-то странной херней. То вроде нормальные ребята разведут такой оопизм, в котором сами начинают отчаянно путаться, то вот функциональщики - последние, к счастью, все еще остаются в массовом сознании чучелами. Неужели не видят, что изобретают?
В том то и дело, что это не странная херня. Теории, на которых построена разного рода функциональщина, для вычислений являются примерно тем же, чем реляционная модель является для баз данных.
Да это все замечательно; но вот какой с этого прок крокодилам? Я лет шесть назад, сознаюсь, не от большого ума полистал книжку по, кажется, хаскелю и, к своей чести, довольно быстро ее выкинул. Почему? Потому что ни одной моей проблемы это не решало.
Мои решило. Правда, не хаскель (который я изучил, но на практике почти не использую), а F# и Clojure. Первое генерит код, второе считает бухгалтерские отчеты. В первом случае, кроме функциональщины вообще слабо что пригодно, во втором - она используется как "более мощный sql, чем сам sql" :)
Представление AST кода наиболее естественным образом выглядит в двух случаях - или это лиспообразные языки, где код от данных и AST не отличается, или же нужны развесистые деревья с разнообразными структурами данных, которые проще всего на функциональных языках описываются.
Еще можно было бы генерить код без AST, а как любой текст - из текстовых шаблонов, но даже для этого входные данные проще описывать на функциональных языках.
Я пытался сделать кодогенератор сначала на C# - получился откровенный неподдерживаемый бред. Ну по аналогии - как SQL запросы руками на обычных языках имитировать, над курсорами :) На F# то же самое получилось гораздо понятнее и лаконичнее.
Ничто не умеет, хинты я руками ставлю, там где они нужны. При генерации запросов из LINQ я как-то не обращал внимания, ставит ли оно хинты, потому что в большинстве случаев оптимизатор отрабатывает корректно.
Ну "большие объемы", как ты их не хинти, уткнутся в i/o. У меня есть одна задача, где это придется решать дурным методом (запоминать результаты запросов, условно говоря "по всей БД" и далее анализировать, какие из запросов нужно пересчитывать при изменении данных). Вроде бы в мощных субд есть materialized views для такого, но я их руками не трогал и СУБД оные у меня не используются :)
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
no subject
Это не напускная тупость, это удивление перед бесконечным разнообразием жизни.
Меня давно интересует парадокс - как в общем неглупые люди могут заниматься какой-то странной херней. То вроде нормальные ребята разведут такой оопизм, в котором сами начинают отчаянно путаться, то вот функциональщики - последние, к счастью, все еще остаются в массовом сознании чучелами. Неужели не видят, что изобретают?
no subject
no subject
no subject
no subject
no subject
Первое генерит код, второе считает бухгалтерские отчеты.
В первом случае, кроме функциональщины вообще слабо что пригодно, во втором - она используется как "более мощный sql, чем сам sql" :)
no subject
no subject
Еще можно было бы генерить код без AST, а как любой текст - из текстовых шаблонов, но даже для этого входные данные проще описывать на функциональных языках.
Я пытался сделать кодогенератор сначала на C# - получился откровенный неподдерживаемый бред. Ну по аналогии - как SQL запросы руками на обычных языках имитировать, над курсорами :)
На F# то же самое получилось гораздо понятнее и лаконичнее.
no subject
no subject
При генерации запросов из LINQ я как-то не обращал внимания, ставит ли оно хинты, потому что в большинстве случаев оптимизатор отрабатывает корректно.
no subject
no subject
У меня есть одна задача, где это придется решать дурным методом (запоминать результаты запросов, условно говоря "по всей БД" и далее анализировать, какие из запросов нужно пересчитывать при изменении данных). Вроде бы в мощных субд есть materialized views для такого, но я их руками не трогал и СУБД оные у меня не используются :)
no subject
no subject