я помню был пост га гисте на эту тему, но я целиком не прочитал - там такие варианты рассматривались?

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

(Я, в целом, согласен, но хотел бы в скобках заметить, что в западной культуре не принято так резко говорить вещи в глаза или за глаза. Там бы сказали: написана в качестве хобби, то бишь, с любовью и без профессонализма. P.S. https://cs8.pikabu.ru/post_img/big/2016/08/15/1/1471214713140571170.jpg).

а он в этом чате?

а он в этом чате?

Не знаю

я помню был пост га гисте на эту тему, но я целиком не прочитал - там такие варианты рассматривались?

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

я давненько пролистывал, уже не помню

не зря я вчера сюда восстановился )

как раз запросил сабж

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

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

(Я, в целом, согласен, но хотел бы в скобках заметить, что в западной культуре не принято так резко говорить вещи в глаза или за глаза. Там бы сказали: написана в качестве хобби, то бишь, с любовью и без профессонализма. P.S. https://cs8.pikabu.ru/post_img/big/2016/08/15/1/1471214713140571170.jpg).

спутаны понятия "профессионально" и "качественно".

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

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

спутаны понятия "профессионально" и "качественно".

Я думаю, эти понятия настолько связаны, что в данном контексте уместно.

Я думаю, эти понятия настолько связаны, что в данном контексте уместно.

профессионально - это за деньги, к качеству не имеет отношения. Можно профессионально делать халтуру.

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

я как раз про это хотел говорить на несостоявшемся докладе ) абстракция настолько высока, что детали реализации не рассматриваются, а в них всем известно кто )

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

в мейнстримных языках

в мейнстримных языках

это про что речь?

если не на персистентную структуру данных натягивают map

про линк и джавастримы полагаю

rust например

думаю что и скала наверняка

и фиг знает сколько языков еще

там совсем не ок

почему кстати не ок, если там массив/вектор под капотом?

rust например

ну вот линк ту обджектс в сишарпе считается за мейнстримную функциональщину на неперсистентной структуре (энумераторе, который мутабельный)?

ну вот линк ту обджектс в сишарпе считается за мейнстримную функциональщину на неперсистентной структуре (энумераторе, который мутабельный)?

не знаком с этим, хз

поэтому и не ок, что трансдьюсров нет и все материализуется на каждом шаге

то что не фьюзится в цепочке комбинаторов это другой вопрос

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

поэтому и не ок, что трансдьюсров нет и все материализуется на каждом шаге

foldl от Гонзалеса

ну как другой вопрос - это причина неокея

так что в целом в мейнстриме с этим еще хуже чем даже в наивных ФЯ-имплементациях, в основном от дремучести и нечитательства

про фьюжен вообще речи нет, этого почти нигде нет и там где есть работает только когда повезет

ну как другой вопрос - это причина неокея

в целом неок, да

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

ну и в результате разница по производительности всех этих костылей для объединения функций в конвейер в разных языках отличается на несколько десятичных порядков

но это пока только для sci-fi фантастов

ну и в результате разница по производительности всех этих костылей для объединения функций в конвейер в разных языках отличается на несколько десятичных порядков

в общем то шокирующий вывод о том что ФЯП лучше приспособлены для функционального кода - не такой уж и шокирующий

да нет, лично меня шокировала 1) адовость хаков которые приходится для всего этого применять 2) размеры разницы, понятно, что какая-то разница должна была быть. 3) вообще сам дизайн спейс где столько всего и одно хуже другого (эта проблема вроде той что с рекордами)

только в последнем "instead of solving the problem"

Раст и элм в одном ряду

инженер-восемнадцатого-века вместо инженер, таких среди программистов пока нету.

поэтому и не ок, что трансдьюсров нет и все материализуется на каждом шаге

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

значит ситуация лучше чем я пессимистично полагал. но все равно не уверен в окее

а есть какие-то чёткие критерии для окея?

четких нет - только степень окейности. играться то и на неокейных реализациях можно

если скала -то окей

Какой сейчас бинарный сериализатор побыстрее? У меня тут binary и он какой-то тормозной.

если именно сериализатор то cbor/serialise или store наверно

https://hackage.haskell.org/package/serialise ? по случайности смотрел talk Дункана про это дело

говорил, что упор был на скорость

store или flat

но если хочется стандартизированный формат, то serialise тоже ок

мне хочется 1) быстро 2) дженерики 3) компактно

а flat быстрый что-ли?

по бенчмаркам быстрый

по каким бенчмаркам? Из серии репозиториев на гитхабе, где сравнения библиотек вроде все последовательности, все словари и т.д.?

да

а покажите репу с бенчмарками?

Я бы относился к результатам этих бенчмарков с осторожностью

В cbor были бенчи

Store там точно был. @qnikst пилил

https://github.com/haskell-perf/serialization

я адаптировал для сторе и сериалайз

они сравнимы были

на плоских сторе выигрывал

на деревьях цбор

надо походу store брать

он в генерики умеет?

так, умеет

store это когда 1) читать той же программой. 2) сериализуем в основном массивы стораблов но изредка что-то еще

1 это ок, по 2 - есть куча своих нерекурсивных типов, вроде особых противопоказаний нет

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

Stack dot?

подходит, спасибо

теперь осталось понять как в этой мешанине разобраться

ой да, я помню эту проблему

потом либо разрешения не хватает в png, либо софт не умеет зумить настолько сильно

надо прям дот-файл разбирать

а постресовый бинарный протокол для copy-to уже кто-нить зопилил?

@catamorphism там же просто перечисление связей

я через dot сразу нарисовал

там безумная лапша такая, на волосы похоже

в .svg надеюсь?

можно и в svg наверное, если dot умеет

впрочем, с svg у меня вчера фейл был

я так и не нашел чем можно огромный svg перекрутить

никакие тулзы не справляются

а постресовый бинарный протокол для copy-to уже кто-нить зопилил?

Был на Хакадже, под пгс вроде

WT в соседнем проекте сами пилили

но тот код не открытый, а перепиливать лень

https://hackage.haskell.org/package/postgresql-copy-escape

Но вроде только csv

Бинарный можно из хаскл слепить

мы так прочненько на postgresql-simple сидим, думаю в этих проектах никогда не слезем