функциональные языки + субд

Или пример из похожей бочки: веб-сервер. Это ведь просто машина состояний. Есть коннект, есть реквест, есть логин, есть то се.

В императивном стиле это выглядело бы так (скажем однотрэдовый для примера):

class WebServer
....State state
....methods_acting_on_state...

И следом скажем

some_actions()
some_more_actions()
even_more_actions()

В функциональном стиле это будет выглядеть так:

even_more_actions(some_other_actions(some_actions(state)))

Неудобно.

PS Не флейма ради, а действительно хочется использовать функциональное программирование в каком-нибудь достаточно объемном упражнении, чтобы увидеть плюсы. Но уже даже не начиная видны сами минусы в тех упражнениях которые под рукой.

В соседнем топике я писал про комбинаторную модель данных. Другого ничего в ФП не найдешь. Все есть выражение.

>even_more_actions(some_other_actions(some_actions(state)))

В ФП это будет выглядеть вот так (a ->> b ->> c ->> ... z) state, где "->>" какой-то комбинатор. В скобки выражения взяты умышленно, чтобы показать что результат их исполнения - функция.

> Не флейма ради, а действительно хочется использовать функциональное программирование в каком-нибудь достаточно объемном упражнении, чтобы увидеть плюсы.

ИМХО, примеры, связанные со вводом/выводом - не лучшие для ФП.

А как же монады в haskell? Если осилишь, то всё остальное уже не страшно. А в СУДБ есть тот же парсер запросов, который лучше делать на языке ФП. А уже низкоуровневые вещи делать на С.

>ИМХО, примеры, связанные со вводом/выводом - не лучшие для ФП.

Не лучшие для объяснения что такое ФП. Слишком много всего сразу наваливается.

> А как же монады в haskell? Если осилишь, то всё остальное уже не страшно.

Есть старый принцип "от простого к сложному". Монады не зря даются в _конце_ учебников начального уровня.

> А как же монады в haskell?
А монады позволяют "скакать по файлам туда сюда, читать то, записать се" на лету? Я когда-то что-то "краем глаза" читал и там было про монады и "последовательности", но то второе совсем не позволяло скакать по файлам, это был просто способ делать вещи одна за одной, например выдать приглашение на консоль и только потом ожидать от пользователя ввода, делалось это таким образом что функции передавалась другая функция в которую нужно войти после выполнения первой.

Это не совсем то вроде.

Это был стёб:) Конечно, монады - это красивая концепция, только ползоваться этим... ну можно:) Скакать по файлам должен код на С, он должен быть простым и тупым, а управлять им должен умный haskell, который делает разбор сложных запросов.

А как устраивать interoperability? Просто сейчас модны всякие soap'ы. corb'ы и прочие com'ы. Как поступать в этом случае? Есть какой-то механизм вроде JNI (да, я испорчен виндой и "высокими технологиями")?

А если даже и делать так, то какая тогда выгода от использования функциональных языков в таком упражнений? Парсинг SQL'а можно вероятнее всего реализовать с помощью какой-нибудь либы в том что сейчас модно (Java, .NET там). При этом можно еще и хитрую либу взять с каким-нибудь Query Builder'ом будет вообще супермодно.

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

То есть как раз та ситуация о которой говорят опоненты "А вот я могу написать в C++/Java/.NET а не могу в Хаскеле".

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

> как устраивать interoperability? Просто сейчас модны всякие soap'ы. corb'ы и прочие com'ы. Как поступать в этом случае?

В этом случае не использовать Хаскел (который на роль "клея" не подходит).

> какая тогда выгода от использования функциональных языков в таком упражнений?

А какая выгода тебе нужна? ИМХО, главная выгода от освоения ФП - это то, что ты научишься смотреть на программирование под сильно другим углом. _И всё_ - использование чистого ФП в широкой практике я в обозримом будущем не вижу.

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

Похоже, ты выбрал не тот предмет. Попробуй использовать Хаскел для "Алгоритмы и структуры данных" (если у вас есть такой).

> Попробуй использовать Хаскел для "Алгоритмы и структуры данных"
Уже был давно.

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

Причем что самое обидное, что этот инстик то скоро закончится, на работе сплошной C++, ДатНэт и немного Питона, то есть практически шансы попробовать функциональное программирование равны нулю.

Более того с работой, в которой используется ФП в моем городе (Вроцлав, Польша) тоже сложновато.

То есть выходит как круто, надо поиграться, а песочницы нету или формат песочницы не тот.

> практически шансы попробовать функциональное программирование равны нулю.

ФП != языкам ФП

> То есть выходит как круто, надо поиграться, а песочницы нету или формат песочницы не тот.

Играться? Надо понять. Дальше - на всём, тобой упомянутом, можно писать в функциональном стиле.

Кстати, СУБД состоит не только из I/O engine. Есть еще процессор SQL (или еще чего-то), оптимизатор запросов. Это должно отлично лечь на ФП. Собственно, общение между SQL-компонентом и I/O engine - через план выполнения запроса, одно на ЯФП, другое - на Си++. Нормальная архитектура, ИМХО.

И меня не покидает чувство, что большую чать I/O engine можно сделать на ЯФП тоже :)

Вообще как оказалось парсер SQL надо ручками писать, на том предмет собственно и основан. :)

Пока что думаю про Ocaml и всякие ocamlyacc. Т.е. парсер функционально в Ocaml, структуры с I/O императивно в том же Ocaml.

А оптимизатор да, это мысль.

PS А что такое "план выполнения запроса"?

смысл курса БД заключается в том, чтобы написать парсер sql?? зашибись
а вобще, правильно сказали: в функциональном стиле можно писать на чем угодно. главное - принцип

> PS А что такое "план выполнения запроса"?

Это вам должны были объяснить на лекциях :) Упрощенно говоря, это последовательность операций системы управления данными (есть такой уровень в СУБД - занимается всякими там страницами, индексами, кортежами, буферами), сформированная оптимизатором запросов с учетом кучи критериев (структура запроса, объем таблиц, наличие индексов, текущее состояние буферов и т;д;).

Почитай о System R - она старая, но о ней много написано. Ну и о Postgres - это самая продвинутая из открытых, и к тому же версионник.

>Это не совсем то вроде.

Это как раз именно то. Как я понял, тебе нужно посмотреть монады State и Reader/Writer. Еще раз повторюсь, в _чисто_ функциональных языках все построено на комбинаторике.

> А как устраивать interoperability? Просто сейчас модны всякие soap'ы. corb'ы и прочие com'ы. Как поступать в этом случае? Есть какой-то механизм вроде JNI (да, я испорчен виндой и "высокими технологиями")?

Есть FFI к С. google haskell ffi

Не хочешь мешать языки - не мешай. Напиши императивную часть на том же Ocaml или Haskell.

> смысл курса БД заключается в том, чтобы написать парсер sql?? зашибись
Это курс про СУБД, называется "Методы имплементации БД". Про БД был курс в тетрадке и в Акцесе. ;)

> Причем что самое обидное, что этот инстик то скоро закончится, на работе сплошной C++, ДатНэт и немного Питона, то есть практически шансы попробовать функциональное программирование равны нулю.

Ну пиши на Nemerle ;-)

>Если в C многие вещи будет просто сделать, скажем UPDATE, просто сделал fseek() куда нужно, заменил то что нужно и привет.

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

>единственное верное решение это использовать язык в котором можно смешивать императивный и функциональный стиль

"Хаскель - лучший из императивных языков" (с)SPJ, кажется.

>Вообще как оказалось парсер SQL надо ручками писать

Parsec не рулит?

> Parsec не рулит?
Это какой-то парсер SQL? Может и рулит, но упражнение похоже в себе включает написание парсера SQL. По крайней мере так одноклассники говорят.

А насчет откатов и деструктивных UPDATE это просто пример. Я имел ввиду что эффективные структуры, которые не местятся в памяти особенно в функциональном стиле не напишешь. Ну или скажем так труднее напишешь.

>> Parsec не рулит?

>Это какой-то парсер SQL?

Это средство разработки парсеров на Хаскеле (за что тебя зобанели в гугле? :))

>насчет откатов и деструктивных UPDATE это просто пример

Ну так я тоже просто пример привёл :). "Потокобезопасные" структуры вполне могут быть эффективнее "эффективных" на современном ширпотребовском железе, а писать их в ф-ном стиле намного проще. Не влезть в память при нынешних обьёмах тоже нужно постараться. Естественно проблемы масштабируемости всегда могут возникнуть. Но всегда стоит посмотреть на код - ф-ный имеет тенденцию быть меньше (*) -- следовательно и переделывать придётся меньше, что при нынешней цене программисто-часа очень даже стоит.

(*) Несколько цифирей я когда-то собрал, они давно утеряны, но слова про "минимум в 5 раз на эквивалентной задаче" вполне подтверждались.

>Это средство разработки парсеров на Хаскеле

Точнее библиотечка. Причём довольно хорошая демонстрация возможностей языка.

>Ну или скажем так труднее напишешь.

Ну почему? Не труднее, просто по-другому. Все-таки, видимо, курс ФП у тебя был паршивый.