А теперь насчет Postgresql

Я тут таки закончил кодогенератор на F# и запустил ноччу конвертировать базу в PGSQL.
Работало оно у меня два часа на базе с 20 таблицами и около 2.5 млн объектов, в результате получилось 1.3 гига на сервере и 500 мег нескомпрессированного дампа базы.

Но больше меня интересует другой аспект.
Я сейчас снял снифером дамп взаимодействия клиента и сервера и просто пребываю в шоке. Я сделал заранее препарированный запрос, с bind-параметрами, как положено, подставляю нужные значения и делаю выполнение запроса. А оно на сервер шлет его в виде тупого плейн-текста, т.е. insert into (поля) values (все значения параметров в виде строк).

Для интереса сделал то же самое с Firebird - вроде там все культурно - т.е. сначала препаре запроса, а потом посылка хендла запроса со списком текущих параметров на на выполнение.

Потом сделал select * from table на Postgresql - тоже вроде культурно, шлет бинарный поток с данными.

Это скажите - у меня клиентский софт такой тупой, или я тупой, и сейчас insert модно делать в лоб текстом и парсить запрос с параметрами на клиентской стороне?
Причем это ж все с кучей проблем типа того, что текст запроса будет зависеть от кучи параметров локали которые нужно учитывать.

Так што текстовый бэкап PGSQL - это не обязательно сознательное решение разработчиков, а вполне может оказаться "сделано по историческим причинам, потому что всегда разговаривали с сервером в тексте". Хотя нет - счас проверил pg_dump - читает он с сервера бинарнейший дальше некуда поток.

Ссылка с planet haskell, наследование

Reflections on leaving Haskell

Там есть две вещи, которые чувака упарили в хаскеле. Первая - это отсутствие наследования реализации datatype. Я тут немного долбанулся головой в последнее время и забыл зачем вообще нужно наследование реализации.

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

Например, недавняя задача: есть объект типа "датагрид". C ним пользователь сделать три действия: открыть текущую запись-объект на редактирование, воспроизвести из одного из полей текущей записи аудиозапись, открыть из другого поля этой записи большой текстовый документ на редактирование. Это все представляется в виде объекта типа "текущее рабочее место пользователя", содержащей этот грид и методы, замапленные на меню/тулбар. Если бы действия были независимы - сделал бы три наследника базового рабочего места: "с редактором записи", "со звуком", "с редактором текста".
Но дело в том, что эти три действия могут комбинироваться в любых вариациях и вместо наследования тут получается проще сделать некую аггрегацию, собирая из комбинаций типов "рабочее место с гридом", "рабочее место с редактором объекта", "рабочее место со звуком, "рабочее место с редактором текста" итоговый тип рабочего места, склеивая их анонимными делегатами, связывающими текущую запись в гриде и действия с ней из других классов.

И так, если глянуть, почти везде - везде наследование реализации выглядит прибитым гвоздями сбоку. Кроме одного частного случая, как и там по ссылке - когда нужно из двух-трех объектов данных, отражающих частные аспекты, собрать новый. Например "финансовый документ" + "объект, внесенный в определенном филиале по определенной ИМНС" = "финансовый документ с привязкой к подразделению и ИМНС". Хотя тут, по идее аггрегация, тоже бы помогла, наследование тоже выглядит прибитым сбоку.

Ссылка с planet haskell, IO monad

Теперь про IO.
В ссылке с прошлого поста товарищ жалуется на то, что IO монада лезет в любую дыру без мыла и заражает в итоге любую более менее осмысленную программу.

В этом плане я не совсем понимаю, почему в хаскеле эта монада - одна на все виды взаимодействия с внешним миром? Например, с моей точки зрения чтение и запись файлов совершенно отличается от обращения к серверу БД, что в свою очередь отличается от разговора с пользователем в консоли, что опять же отличается от взаимодействия в GUI, итд. Еще можно вспомнить работу по сети, работу с COM-портами, FFI итд.

Предположительно, было бы гуманно дать программистам возможность самостоятельно делать IO-подобные монады и расселить разные виды взаимодействия по разным монадам, заодно как-то прикрутить к этим монадам некие атрибуты на тему ленивости и порядка вычислений - т.е. например, запись в лог без разницы в каком порядке будет делаться и вообще должна вычисляться только тогда, когда это значение кому-то интересно.

Это я как-то размышлял на тему, "как бы выглядел хаскель, встроенный в СУБД в качестве языка запросов". Я с трудом могу перейти от размышления над обычной программой в стиле "запустили, ввели данные, получили результат" к постоянно запущенной программе, управляемой событиями типа "сервер, ждет запроса от клиентов" или "GUI приложение ждет нажатия кнопки пользователем".
И от "программа читает файл с состоянием, обрабатывает запрос и сохраняет файл обратно" к "программа живет с внутренним состоянием, которое обрабатывается интегрированным в компилятор/виртуальную машину/интерпретатор движком БД.
Реализация IO мешается в голове, а для СУБД нужна была бы еще одна монада (а может и не одна), отражающая внутреннее состояние, упорядочивающая действия с записями, транзакциями и взаимодействием между различными пользователями, лезущими к одним и тем же данным).

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