https://twitter.com/zedshaw/status/965481063555522560 да что с ним не так?

он токсичный гопник, и за 10 лет никак не изменился. про "Rails Is A Ghetto" слышал?

Чувствую что не удержу место главного шитпостера русского Хаскель сообщества.

Мне не очень ясно, какие проблемы испытывают люди с ленивостью в Haskell. При прочих равных, о ленивости, о потреблении памяти, о производительности хаскельного кода можно не думать вообще, - до поры, когда это действительно понадобится, а это, пожалуй, небольшой процент случаев работы с большим количеством данных. Некоторые жалуются на ленивое IO, но я даже не представляю, что они там такого написали, чтобы поиметь проблем. Аргументация к производительности вообще довольно смешна, и детектит либо плюсовиков, либо студентов, которые с бешенными глазами носятся вокруг, желая все преждевременно оптимизировать. Хотя лишь 10% задач требуют оптимизации, а из них - только 10% кода, да и то - только после обнаружения этих проблем в профилировщике (цифры с потолка). И уж совсем странно выглядит хейт производительности в ФП/Хаскеле на фоне крайней распространенности Питона.

Можно. Но известно же, что наивные, лобовые решения в Хаскеле работают не очень хорошо. Это, я думаю, все уважающие себя хаскеллисты знают, и умеют с этим жить. Точно так же и плюсовики обходят свои обстрелы ног.

в ногу себе выстрелить невозможно

правда можно дойти до точки когда твой проект неподдерживаемое месиво а потом потратить кучу денег на переход на другую технологию(в случае с Рельсами)

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

С рельс?

заходит такой воннаби хаскелист в чат

Вообще "текучесть" (в смысле ВНЕЗАПНОГО подскакивания потребляемой памяти на несколько гигов с последующим рассасыванием, а не заагдочного роста потребления памяти на сколько-то там в день) это не свойство ленивости, а ФП вообще. Т.е. сами подходы с приниманием и возвращением иммутабельных данных такие. В строгом ФЯ просто в таком смысле текут все функции над списками кроме foldl, а в ленивом foldl

Только я не вышел. Видимо, я всё же что-то понял. Осталось понять, что именно.

s/foldl/foldr/

а потом понемногу ему бы дали Real World Haskell, другие книжки, посмотрел бы видосы Пейтона Джонса

да нет, все правильно. foldr как раз в ленивом может не течь, а в строгом не может.

Душкина уже прочёл, однако.

короче ленивый foldl течет, а строгий нет

Что не так с Душкиным?

> 90% функций над списками это foldr и 10% foldl Детали реализации же.

я не очень понимаю фразу что о том что 90% это foldr, т.к. выразимо в обе стороны, семантика одинаковая будет, если пренебречь временем выполнения и ресурсами

А вот первая его книга совершенно отвратительна

если мы выбираем более оптимальную реализацию по строгости/ленивости ЯП, то ответы же будут разные

(Я, в целом, согласен, но хотел бы в скобках заметить, что в западной культуре не принято так резко говорить вещи в глаза или за глаза. Там бы сказали: написана в качестве хобби, то бишь, с любовью и без профессонализма. 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).

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