Ggg_oldТеперь попробую описать какого рода объяснения мне не хватает.
...
Мне видится аналогия SQL-я тогдашнего и ФП сегодняшнего. Правда есть исключение, концепция ФП вторая по древности после фортрана, т.е. не является новой.
Какие объяснения нужны из аналогий непонятно.
ФП вобще понятие общее. haskell и ocaml построены на типизированом лямбда исчислении. Теория категорий играет для него примерно ту же роль что и теория множеств для реалиционной алгебры.

Ggg_old
Давайте сделаем экскурс в недавнее прошлое, лет на 10-15 назад. В ту славную эпоху мэйнстримом в строении учетных систем были клиент-сервреные комбайны типа dbase/clipper/foxpro/paradox.
Уже тогда мало кто напрямую писал код на си по открытию таблиц в своем формате, индексации итп. Программирование выглядело на встроенном интерпретирующем языке типа так:

USE таблица 1 с индексом 1
use таблица 2 синдексом 2
Установить фильтр на таблицу 1 по условию ......
открыли курсоры, побежали по ним, поделали операции.
закрыли индексы
закрыли таблицы

Такой подход ручного управления позволял программисту самому в каждом конкретном случае выбирать стратегию работы с объектами БД и достигать максимальной производительности. Потом во второй половине и конце 90-х на арену начали выходить SQL-сервера.
Декларативный SQL, оптимизаторы по нынешним дням не ахти вообще, дорогущие и малодоступные.
Из преимуществ явно видно только отказоустойчивость и возможность настроить безопасность на доступ.
Если поставить себя на место спорящих в то время, что лучше SQL или Fox pro, то фокспрошник мог легко запинать скл-щика, т.к. его прямое управление кодом соединений было более эффективно. Аргументы что разработка на скл проще и быстрее (после значительной перестройки и расширения сознания под концепцию обработки множеств а не записей), да и оптимизаторы станут лучше в будущем и возможно, что даже появится когда-нибудь автоматический параллелизм на те времена выглядели бы слабенько.
..
Мне видится аналогия SQL-я тогдашнего и ФП сегодняшнего. Правда есть исключение, концепция ФП вторая по древности после фортрана, т.е. не является новой.

Ggg_old
Давайте сделаем экскурс в недавнее прошлое, лет на 10-15 назад. В ту славную эпоху мэйнстримом в строении учетных систем были клиент-сервреные комбайны типа dbase/clipper/foxpro/paradox.
Уже тогда мало кто напрямую писал код на си по открытию таблиц в своем формате, индексации итп. Программирование выглядело на встроенном интерпретирующем языке типа так:

USE таблица 1 с индексом 1
use таблица 2 синдексом 2
Установить фильтр на таблицу 1 по условию ......
открыли курсоры, побежали по ним, поделали операции.
закрыли индексы
закрыли таблицы

Такой подход ручного управления позволял программисту самому в каждом конкретном случае выбирать стратегию работы с объектами БД и достигать максимальной производительности. Потом во второй половине и конце 90-х на арену начали выходить SQL-сервера.
Декларативный SQL, оптимизаторы по нынешним дням не ахти вообще, дорогущие и малодоступные.
Из преимуществ явно видно только отказоустойчивость и возможность настроить безопасность на доступ.
Если поставить себя на место спорящих в то время, что лучше SQL или Fox pro, то фокспрошник мог легко запинать скл-щика, т.к. его прямое управление кодом соединений было более эффективно. Аргументы что разработка на скл проще и быстрее (после значительной перестройки и расширения сознания под концепцию обработки множеств а не записей), да и оптимизаторы станут лучше в будущем и возможно, что даже появится когда-нибудь автоматический параллелизм на те времена выглядели бы слабенько.
..
Мне видится аналогия SQL-я тогдашнего и ФП сегодняшнего. Правда есть исключение, концепция ФП вторая по древности после фортрана, т.е. не является новой.
Про аналогии.
SQL ведь не просто язык запросов. Он опирается на модель данных конкретной БД, производной от реалиционной метамодели. Все операции замкнуты на эту БД, то есть мы можем получить часть БД или преобразовать эту самую БД и ничего больше. Таким образом sql является языком предметной области этой БД, а сама БД моноидом (если я прально помню теорию). Такую вот штуку можно обозвать декларативной если хочется, но декларативность здесь относительна.
Если продолжить такие рассуждения, то FOXPRO-шный файл записей это тоже модель данных построеная вокруг физической последовательности байт в файле записей. Но разные файлы разные модели хоть и объединеные общей метамоделью, поэтому для что бы их совместить требуется язык-посредник , хотя уровень этого языка выше С поскольку метаиодель у них с файлами записей общая. И абсолютно пофигу, какой это язык императивный или функциональный. Если связать эти модели (которые файлы записей) отношениями и определить на них операции замкнутые на ту совокупность, то у нас получится новая общая модель (не обязательная реалиционная) и язык запросов (не обязательно sql).
Я все это к чему. Если sql это модель из отношений для одиночных dbf-оф, то что ,в твоем понимании, обобщает ФП?

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