за счёт чего так?

https://github.com/kcsongor/generic-lens/commit/771506b9e43394ea0ec655b46139f5cf82617fc7

вот такое вот ускорение

не в десять раз, но

https://github.com/ghc-proposals/ghc-proposals/pull/102 foreach....

и даже на 20 полях не помирает, тут я уже серьезно начинаю подозревать что я что-то не то посмотрел

https://github.com/ghc-proposals/ghc-proposals/pull/102 foreach....

над форичом тут вроде уже давно посмеялись

на 50 полях тормозит как старая версия на 10 ГОТОВО ДЛЯ ПРОДАКШОНА

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

это в каком гхц?

8.2

впрочем, я даже не проверил, не поломали ли они оптимизацию просто напросто

над форичом тут вроде уже давно посмеялись

всем чатом

смое адовое что я видел в пропозалах за последнюю неделю это, конечно, что в деп.хаскеле pi будет называться foreach

все ROFL и не могли даже ответить

foreach же @int_index придумал небось?

Да.

сразу видно руку мастера

https://hackage.haskell.org/package/vinyl-0.9.3/docs/Data-Vinyl-Core.html#t:ReifyConstraint

Впервые я противопоставление all/each увидел здесь.

Мне показалось, что с forall такая же ситуация.

iosevka detected

да, похоже что оптимизацию испортили как оказалось, и старая-то версяи не осиливала рекорды (5 да, 10 - нет) а новая версия и 5 не тянет

и где их хваленые инспекшон-тесты?

смое адовое что я видел в пропозалах за последнюю неделю это, конечно, что в деп.хаскеле pi будет называться foreach

Возникает вопрос как будет называть сигма. Экзистол?

Там все очень плохо было с библиотекой elm-export (и она вообще кажется заброшенной), поэтому мы в итоге перешли на elm-bridge. Она поддерживает суммы типы (и есть другие полезные плюшки), но использует TemplateHaskell, а не Generic (хотя с этим можно жить). Правда, возникла проблема, что она не работает с фантомными типами. Поэтому пришлось вручную патчить elm-bridge и использовать нашу патченную версию.

Отбой. Мы теперь не используем ни elm-bridge, ни elm-export ?

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

а давайте сделаем какой-нибудь хакатон в Питере, Москве, Гатчине, где угодно, особенно приглашаются авторы либ для постргреса. (очень хочется применить в жизни идею @catamorphism) И ЗАПЕРЕТЬ ВСЕХ К ЧЕРТЯМ ПОКА НОРМАЛЬНУЮ ЛИБУ НЕ НАПИШУТ

доклады на тему "Почему сборщик запросов должен быть категорией и как это примерно реализовать" будут приниматся?

как раз медленно делаю исследование на эту тему и вроде все замечательно, если отбросить проблемы типизации

профункторы уже жмут?

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

а то 0 библиотек без странных проблем

профункторы уже жмут?

скорее стрелки очень удобные для записи дичи

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

видел кучу ORM где такой подход игнорируется почем зря в пользу каких то собственных dslей

опалай так делает

мне их подход (может реализация) не очень импонирует

и авторы говорят, что если бы делали с нуля, то не делали бы стрелки

а можно точное название? Не слышал про них

(без ссылки)

http://hackage.haskell.org/package/opaleye

но это не планировщик, это генераторы запросов

читаю их доку и у меня волосы на затылке шевелятся

а то 0 библиотек без странных проблем

https://hackage.haskell.org/packages/search?terms=postgres выдаёт 112 либ. Неужели ни одной рабочей??

мне кажется без стрелочного o было бы куда лучше

им сейчас тоже

стрелки дают гарантию того что нету зависимостей лишних

Всем привет. Кто какие ORM пользовал для SQL?

эффектов от результата которых меняется хвост

alchemy, zend!

я про do-нотацию для них

вообще очень странные ребята

а ещё Hybernate

и что-то попроще в java было

но вообще ORM переоценено

возможно это из-за того что они реально влезли в типы

но вообще ORM переоценено

зависит от задачи

если нужно шарить логику между sql запросами без orm тяжко

ERROR: S client not available

https://hackage.haskell.org/packages/search?terms=postgres выдаёт 112 либ. Неужели ни одной рабочей??

ну на хакадже 2 либы низкоуровневых hasql и p-g-simple

обе плохие

можно конечно на хранимых объектах это делать, но хранимые объекты гораздо слабее чем современные orm

мне пока больше всего понравился олеговский quel, но реализации нету

просто в ORM проблема в том, что теряются часто возможности SQL или возможности ORM

в итоге 2 стула получаются

и оба по отдельности не очень

ну часто не значит всегда

у нас вот в руби есть sequel, никогда особых проблем не было с ним

в плане функционала, разумеется

можно в общем то и лучше сделать, например реально применив теоркат

После всяких орм и собирателей запросов я пришел к выводу что лучше уж sql. какой-нибудь postgres-query

+

обе плохие

а что с ними не так? глючат? hasql скачивают вроде гурьбой..

hasql, например, не дает сделать "SELECT *"

случайные баги, плохо с GC, у Никиты ещё и подход к архитектуре либ, что невозможно дебажить

не говоря уже о том что там инстансов не хватает

у pg simple можно легко влететь в то что программа в будет на спинлоках в ожидании capability 90% времени проводить

что там с pg-wire не знаю

Подскажите, а есть ли какие-то способы "подслушать" содержимое TChan? Чтобы при записи в него вызывался мой callback.

надо бы попробовать возможно

Подскажите, а есть ли какие-то способы "подслушать" содержимое TChan? Чтобы при записи в него вызывался мой callback.

конечно, склонируй и читай

lpsmith проснулся и травит пользователей pgs https://github.com/lpsmith/postgresql-simple/issues/220#issuecomment-412622297

Всем привет. Кто какие ORM пользовал для SQL?

persistent

в общем я прекрасно понимаю людей которые просто пишут sql, но любая серьезная схема архитектуры бд при таком подходе превращается в боль

ну это смешно, его называть ORM

с эскулетой даже не дотягивает

например сделали one_to_many а через год оказалось что это many_to_many

ну это смешно, его называть ORM

смешно вообще говорить об объектах в Хаскеле

например сделали one_to_many а через год оказалось что это many_to_many

и?

ну и все, работа стоит