Хм, у нас вручную nix файлы прописаны

в общем когда разрабатываешь делаешь nix-shell и работаешь со стеком

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

перезайти надо если только shell.nix поменяешь

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

а, в этом смысле

скриншот или не было

если поменял зависимости, то stackage2nix прогнать

CI собирает минимум настолько же гранулярно как и стек

А, т.е. в окружении все пакеты проекта

+ может лучше (т.к. не умирает все если -prof флаг добавить но стеку это не нужно)

да

у нас в окружении только конкретный, над которым работаешь

он же на интере? т.е. где-то с 1KLOC начинает тормозить как континентальный дрейф

он же на интере? т.е. где-то с 1KLOC начинает тормозить как континентальный дрейф

stack не тормозит

сколько в нём строк, всяко же больше 1K?

но мне тут не все нравится - у стека плохо с пересборкой пакета с флагами

если не переопределить STACK_ROOT он вообще тупо умирает

сколько в нём строк, всяко же больше 1K?

наверное мало дженериков и темплейтхаскеля

и с линковкой проблема

наверное мало дженериков и темплейтхаскеля

так нечестно, что ли?

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

думаю, что скорее это фактор на не LOC-и

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

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

Если в гите починили cabal new, то стек и не нужен

но на моих паре проектов в тысячи локов интера мертвая, а hie кое-как работает еще

у нас в окружении только конкретный, над которым работаешь

есть же https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/haskell-modules/make-package-set.nix#L257

стек нужен для интеграцие с ide

(я не использую, но видимо нужен)

тем временем у меня похоже cachix завелся

есть же https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/haskell-modules/make-package-set.nix#L257

Воу, спасибо, это похоже на спасение

стек нужен для интеграцие с ide

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

А почему hoogle работает настолько хуже stackage? Пример: не находит mapLeft, ни по названию, ни по сигнатуре. https://www.haskell.org/hoogle/?hoogle=%28a+-%3E+b%29+-%3E+Either+a+c+-%3E+Either+b+c https://www.stackage.org/lts-12.9/hoogle?q=(a%20%2D%3E%20b)%20%2D%3E%20Either%20a%20c%20%2D%3E%20Either%20b%20c

есть новая версия Hoogle. Она находит https://hoogle.haskell.org/?hoogle=(a%20-%3E%20b)%20-%3E%20Either%20a%20c%20-%3E%20Either%20b%20c

он хотя бы быстрый

есть новая версия Hoogle. Она находит https://hoogle.haskell.org/?hoogle=(a%20-%3E%20b)%20-%3E%20Either%20a%20c%20-%3E%20Either%20b%20c

это та же версия (примерно), что и на стекедже

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

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

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

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

Да, ибо ide дергает билд тул.

Ci

Оно мне разве что смотреть сигнатуры функций

тем временем у автора скалового ленгвидж-костыля (энзима) большие планы по конспиративной работе > Is it true that you use an alias nowadays, Alois? I am increasingly coming to conclude that this is the only safe way to do it. My experience with using my real name in Scala has been terrible and I'm thinking about hiding my identity in haskell incase it becomes political too.

Iurii будет жить. Поприветствуем!

kruta

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

Вместо grep могу посоветовать hgrep * https://github.com/thumphries/hgrep

Вместо grep могу посоветовать hgrep * https://github.com/thumphries/hgrep

Для хаскелля есть свой греп, круто

Даже для nix запаковано, идеально

сегодня прямо столько нового :)

Вместо grep могу посоветовать hgrep * https://github.com/thumphries/hgrep

the_silver_searcher

а там haskell specific ясно

the_silver_searcher

+1

the_silver_searcher

Нет. * https://github.com/BurntSushi/ripgrep

смотрите-ка какой митчелл вредитель ни типоменяющих апдейтов, ни поддержки линз. давайте сделаем плохо, вместо того чтоб ничего не делать https://github.com/ghc-proposals/ghc-proposals/pull/158#issuecomment-419442921

@vecser будет жить. Поприветствуем!

@vbyno будет жить. Поприветствуем!

@relmay будет жить. Поприветствуем!

На Clojure не любят городить абстракции ради чего-то на будущее

https://habr.com/company/oleg-bunin/blog/420147/

это так

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

go https://t.me/haskell_blah?

процедурный подход какой-то)

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

однажды в личной беседе Никита сказал, а зачем вам типы, монады и все это

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

@denqxotl будет жить. Поприветствуем!

а зачем нужны нетипизированные языки?

чтобы писать нетипизированный код

а зачем нетипизированный код?

а зачем типизированный?

есть ситуации, когда меньше церемоний с типами == больше продуктивность, может, поэтому?

затем, что его легче написать, чем не типизированный

есть ситуации, когда меньше церемоний с типами == больше продуктивность, может, поэтому?

такие ситуации существуют только в допотопных типизированных языках, после 78-го года нетипизированные языки не нужны

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

затем, что его легче написать, чем не типизированный

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

> а в другой отрисовка этого говна (тут типы увеличают кода в 3 раза, сомнительно

сомнительно что именно?

что кода в 3 раза больше?

что из-за типов

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