Да и размер бинарей впечатляет

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

Да тут все из итмо

Нет

было дело, но вроде отказались от хаскеля

Линк? Семен как пилил Haxl так вроде и пилит, и использт судя по тому что в кафе пишет

Линк? Семен как пилил Haxl так вроде и пилит, и использт судя по тому что в кафе пишет

я же сказал, ошибся)

Ну я всерху вниз читаю

А не все сразу, а потом отвечатб

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

На питоне и сложный код читается. Осложняется только построение связей и понимание общей логики.

Когда либо так, как задумал автор, с его инструментарием, либо никак.

Имеется в виду, что либа не расширяемая. В каких-то случаях это нормально, в каких-то - нет.

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

Нет, и так понятно. Проблему я высосал из пальца ?

На питоне и сложный код читается. Осложняется только построение связей и понимание общей логики.

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

Но ведь хорошо написанный сложный код читается легче, чем он же, но написанный тяп ляп

Мне не нравится, что нет даже размытых границ между тяп ляп и хорошим стилем и тоном.

Да вот код на питоне говно, обычно

;)

Питон дает рекомендации как писать код, чтобы его могли сходу прочитать другие. Но это только стиль.

Да вот код на питоне говно, обычно

Кто б спорил ?

Нигде нету принятого хорошего стиля, в любом нетривиальных проекте свой стайлгайд, включая паттерны naming convention и т.п

Но это говно читаемо.

А с Haskell если ты возбмешь трех хацкелистов и попросишь договориться о хорошо, то максимум они договорятся о стиле tibbe

Но он не покрывает того что тебе захочется скорее всего

Нигде нету принятого хорошего стиля, в любом нетривиальных проекте свой стайлгайд, включая паттерны naming convention и т.п

Есть такая штука - опенсорс. Вот тут хотелось бы что-то ближе к единому стилю.

Но он не покрывает того что тебе захочется скорее всего

Да покрывает. Читать сразу проще, глаз цепляется.

Большиство так и пишут

Сложность логики не может как-то ограничиваться в любом языке. Разве что best practices, но и то it depends.

Даже крисдон в своих автоформатилках на него перешел со своего лиспостиля

Хороший стиль это возможность записать сложную логику чтобы ее чтение упрощалось

Единые стили типа питона вот не факт что упрощают

Но у меня нету опыта больших проектов

Большиство так и пишут

Скорее нет, чем да. Чаще вижу отступы по 2.

У тиббн вроде 2,4 в стиле

Учитывая что код часто уплывает вправо я предпочитаю 2

haskell-style-guide/haskell-style.md at master · tibbe/haskell-style-guide https://github.com/tibbe/haskell-style-guide/blob/master/haskell-style.md

Indentation

Но у меня нету опыта больших проектов

Да у меня тоже :)

Я про питон если что

Какие нить хелловорды на 1к это максимуп

И чужой код где 1-3 строки поправить вообще не задумываясь о том что вокруг

У меня значительно больше, но весь код писал сам.

И.к. индусы тупые и иногда косячат на пустом месте

(индусы сишники в отличии от питонистов не тупые)

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

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

Стиль tibbe вполне читаем.

Вообще имхо нечитаемо нагромождение поинтфри, смешивание bind и do нотаций и сверххитрые линзы

Но это не совсем стиль уже

Кстати, есть хорошие статьи на тему "как писать высокопроизводительный код"?

Блог тиббе статьи лещинского

Донса

Они не очень много пишут сейчас правда

Кстати статьи лещинского на icfp 2016 были

Жалко вообще что он из ms research ушеш

Всем привет, подскажет ли кто нибудь, в телеграмме есть канал по elm lang??

Всем привет, подскажет ли кто нибудь, в телеграмме есть канал по elm lang??

Нету

Прбовал кто делать в стэке мультипроект?

почему не получается поставить последнюю версию http-client?

https://github.com/snoyberg/http-client/issues/175 Вот тут это починили, но не могу понять как мне установить последнюю версию http-client уууууууу бесит!

https://github.com/snoyberg/http-client/issues/175 Вот тут это починили, но не могу понять как мне установить последнюю версию http-client уууууууу бесит!

В stack.yaml в extra-deps пропиши нужную версию например: - http-dispatch-0.5.0.2 - encoding-0.8.1 а в cabal убери номер А снапшот поставвь например resolver: lts-6.23

В stack.yaml в extra-deps пропиши нужную версию например: - http-dispatch-0.5.0.2 - encoding-0.8.1 а в cabal убери номер А снапшот поставвь например resolver: lts-6.23

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

В stack.yaml в extra-deps пропиши нужную версию например: - http-dispatch-0.5.0.2 - encoding-0.8.1 а в cabal убери номер А снапшот поставвь например resolver: lts-6.23

у меня сейчас в stack.yaml resolver: lts-7.1, он же новее и "лучше" 6.23?

хмм ок, не совсем понятно как с lts-7.6 поставилась версия 0.5.3.3, если тут у 7.6 указана более старая версия пакета, но проект собрался

Почему если не указываешь версию пакета explicitly, ставится старая мажорная версия, зачастую устаревшая на 2 версии от той что на гитхабе? Можно ли как-то заставить стак ставить всегда последние версии?

хмм ок, не совсем понятно как с lts-7.6 поставилась версия 0.5.3.3, если тут у 7.6 указана более старая версия пакета, но проект собрался

В stack.yaml прописал?

ERROR: S client not available

В stack.yaml прописал?

да все по совету. просто не понял почему stackage пишет версию пакета 0.4.31.1 рядом с LTS 7.6 на скриншоте, когда у меня спокойно поставилась версия 0.5.3.3 с этим же lts в stack.yaml

В секции extra-deps указываются то чего нет в снапшоте

stack.yaml specifies which packages to include из док

О, вот и для меня понятней стало, спасибо!

В секции extra-deps указываются то чего нет в снапшоте

Во, писали б такое сразу в установщике стака или на главной

Ну надо просто доку читать там почти всё написано https://docs.haskellstack.org/en/stable/GUIDE/#stackyaml-vs-cabal-files - хотя не всё)))

https://docs.haskellstack.org/en/stable/GUIDE/#adding-dependencies

stack path - хорошая команда

позволяет посмотреть окружение

Помойму у стака документация была не плохая

И в каком-то из выпусков бананов и линз рассказывали про стак

Помойму у стака документация была не плохая

Со стэком адъ зависимостей почти прекратился -)

Да, жить хорошо и просто ?

Типа скачал хэллоуворд и он должен запуститься почти без проблем

Со стэком адъ зависимостей почти прекратился -)

Он уже почти прекратился с cabal sandbox

А кто-нибудь писал многопоточный кравлер на хаскеле? Нужно выжать максимум производительности, интересуют типичные подводные камни. Я вот использую http-client, и мучался с непонятными багами с HTTPS_PROXY из environment. Чудом обнаружил что автор активно поддерживает это дело на гитхабе, и вся туса там в /issues. Оказалось что у меня была старая версия пакета. В новой версии уже общий Manager не жрет 40GB RAM на 500 подключений с tls, и добавлено куча удобных утилити ф-й.

А кто-нибудь писал многопоточный кравлер на хаскеле? Нужно выжать максимум производительности, интересуют типичные подводные камни. Я вот использую http-client, и мучался с непонятными багами с HTTPS_PROXY из environment. Чудом обнаружил что автор активно поддерживает это дело на гитхабе, и вся туса там в /issues. Оказалось что у меня была старая версия пакета. В новой версии уже общий Manager не жрет 40GB RAM на 500 подключений с tls, и добавлено куча удобных утилити ф-й.

Интересно а зачем многопоточный кравлер на хаске а не например на го?

Вот еще всегда хотел спросить – почему в хаскеле такая странная система импортов через категории, по типу веб-порталов конца девяностых-начала нулевых? Почему не import "http-client" например? Если появится конкурирующая с http-client либа, она тоже поместится под Network.HTTP.Client?

Интересно а зачем многопоточный кравлер на хаске а не например на го?

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

а в go мне этот хорёк не нравится, ненавижу его

и еще слышал что у хаскеля более продумано распараллеливание на N ядер в отличае от го

А как ты обрабатывешь "ошибки" в этом "кравлере" - я опять про 10 способов почитал и опечалился снова)))

А как ты обрабатывешь "ошибки" в этом "кравлере" - я опять про 10 способов почитал и опечалился снова)))

verbatim: catchAny :: IO a -> (SomeException -> IO a) -> IO a catchAny = Control.Exception.catch ?

еще retryN

меня вообще вот эта статья натолкнула на хаск http://www.michaelnielsen.org/ddi/how-to-crawl-a-quarter-billion-webpages-in-40-hours/

ой не не эта, какая-то другая, тоже EC2, только код на хаскеле

использовать cabal уже предлагали?

использовать cabal уже предлагали?

угу все решили, спасиб

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

вместе не стоит, то, насколько stack использует Cabal и cabal-install внутри себя - достаточно

Вот еще всегда хотел спросить – почему в хаскеле такая странная система импортов через категории, по типу веб-порталов конца девяностых-начала нулевых? Почему не import "http-client" например? Если появится конкурирующая с http-client либа, она тоже поместится под Network.HTTP.Client?

{-# LANGUAGE PackageImports #-}

вместе не стоит, то, насколько stack использует Cabal и cabal-install внутри себя - достаточно

Да вместе их не надо юзать - гремучая смесь)

я иногда делаю stack sh и внутри кабал/pure ghc