IT-redneck

Самоочевидно ли то, что с помощью filter/map/fold можно реализовать бухгалтерскую отчетность более простым и очевидным образом, чем с помощью select .. where .. group by?

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

Смотрю .NET Reflector на внутренности программы на F# и всячески торчу.
50 строк на F# разворачивается в четыре автосгенеренных класса-замыкания, автоматически управляющих десятком объектов для доступа к базе данных и все это в итоге представляет собой функцию "коннект к Firebird -> хитрозаколдованная структура с данными".

А я еще собираюсь и сам код на F# сгенерить из результатов парсинга запросов в БД, чтобы вообще руками ничего не писать, кроме SQL запросов. Т.е. "чтобы было все и мне за это ничего не было".

Т.е. идея примерно такая:
1)есть структура реляционной БД - мне в ее категориях проще проектировать и думать.
2)есть запросы к ней и связи между ними - которые мне тоже проще придумать, чем делать маппинги в ORM или писать запросы на LINQToSQL, который вообще не факт что поддерживается для Firebird.

Я описываю запросы на SQL, кодогенератором автоматически конвертирую их в функции F# вида ("коннект к БД" -> "параметр запроса 1" -> "параметр запроса 2" -> ... -> "ленивая последовательность записей с результатами").
Затем полученные функции я собираю в законченную структуру, описывая связи между ними уже на F# и получаю на выходе что-то вроде "Запись, поля которой представляют собой ленивые последовательности с результами запросов, причем внутри эти результатов могут быть такие же поля - ленивые последовательности с результатами вложенных запросов".

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