да потому что началось это обычное, а посмотрите как в жс плохо. это как если бы стоматолог вместо обезбаливания говорил "а представь как страдает программист на си++", спасибо доктор, стало намного легче

yarn же

И чем он лучше?

Просто работает

С некурируемой помойкой

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

Ага, потому что ошибки в рантайме всплывают

Ага, потому что ошибки в рантайме всплывают

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

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

Это верно. Тогда вопрос: где лучше, чем в Haskell и почему?

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

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

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

Не курируемый yarn ничем от не курируемого hackage не отличается. Только в одном случае у тебя ошибки при компиляции а в другом в рантайме

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

кстати, почему в хекедж матрикс билдер до сих пор 8.4 нету?

кстати, почему в хекедж матрикс билдер до сих пор 8.4 нету?

В питоне есть пакетный менеджер conda, он в основном было сначала для бинарных зависимостей, там были каналы (ака репозитории) только из коробки... Но потом в ней появились кастомные каналы и нормальные курируемые пакеты и все стали счастливы, а pip в ней используется как бекэнд (прямо как кое-что другое). npm shrinkwrap не работает, потому что нельзя обновить зависимость с критической уязвимостью, да и вообще npm перезаписывает package.lock при установке, например. Поэтому в yarn сделали resolutions. npm в бэкенде. короче вся эта конфигурационная байда придумана не на пустом месте и это только к лучшему, что она развивается. Лично мне гораздо больше нравится подход, когда есть и низкоуревневая ("cabal", "pip", "npm"), так и высокоуровневая система пакетов, вплоть до докера и далее. Думаю, что stack.yaml может быть непонятен только из-за исторических причин, когда всё объясняется через команды cabal. Я зеленый, поэтому не встречал package.yml, но это не должно мешать новичку смотреть хотя бы в первую страницу документации.

сорян, случайно референснул сообщение :(

преттипринтеры Мэйнланда и Вадлера—Лейена писаны независимо?

наблюдаю идентичный баг в обоих, но уже сомневаюсь, что это действительно баг

В питоне есть пакетный менеджер conda, он в основном было сначала для бинарных зависимостей, там были каналы (ака репозитории) только из коробки... Но потом в ней появились кастомные каналы и нормальные курируемые пакеты и все стали счастливы, а pip в ней используется как бекэнд (прямо как кое-что другое). npm shrinkwrap не работает, потому что нельзя обновить зависимость с критической уязвимостью, да и вообще npm перезаписывает package.lock при установке, например. Поэтому в yarn сделали resolutions. npm в бэкенде. короче вся эта конфигурационная байда придумана не на пустом месте и это только к лучшему, что она развивается. Лично мне гораздо больше нравится подход, когда есть и низкоуревневая ("cabal", "pip", "npm"), так и высокоуровневая система пакетов, вплоть до докера и далее. Думаю, что stack.yaml может быть непонятен только из-за исторических причин, когда всё объясняется через команды cabal. Я зеленый, поэтому не встречал package.yml, но это не должно мешать новичку смотреть хотя бы в первую страницу документации.

package.yaml (hpack) сам по себе довольно удобен. Проблемы вызывает включение оного по умолчанию в умолчательном же шаблоне для stack-проектов.

Пришлось даже викифицировать назначение "всех этих разных файлов" :)

Пришлось даже викифицировать назначение "всех этих разных файлов" :)

Wiki.haskell.org?

Выскажу не самое популярное мнение, но мне сильно не нравится hpack. Как по мне, он даёт не так много преимуществ, но поддержка со стороны тулинга и дружелюбность экосистемы уменьшается. А точнее по пунктам: 1. Многим нравится поле общих зависимостей (и не только) в hpack, но в cabal-2.2. это уже впилено, и там можно указать в общей станзе любой кусок станзы. 2. Автоматический поиск модуля: добавить модуль — одна строка. Это не так часто происходит, чтобы было слишком неудобно. К тому же, когда есть модули, которые генерируются пакетами вроде proto-lens, то их всё равно надо добавлять в package.yaml явно, без этого не работает, поэтому проблема всё равно полностью не решается. 3. YAML. Я сам лично не люблю этот формат, мне в нём много не нравится. Например, там были проблемы с парсингом версий, когда они у пакетов похожи на число. В одном multi-package проекте мы использовали hpack, и там дублицирование кода уменьшилось благодаря алиасам в yaml. Но полностью дублирование убрать не удалось, потому что yaml не поддерживает конкатенацию списков. Поэтому общие куски зависимостей между пакетами всё равно нельзя вынести в отдельный файл :( Если уж хочется полноценную и программируемую конфигурацию, тогда лучше использовать dhall. 4. Генерация .cabal файла с новым хешом каждый раз. Если над проектом работает несколько людей, то у них постоянно будут конфликты в этом .cabal файле, если он есть на GitHub. А если его нет на GitHub, то людям, у которых не стоит hpack, будет трудней сбилдить проект, надо прилагать больше усилий, чтобы этот cabal файл сгенерить. Да, stack работает, но вокруг одного stack мир не вертится. То есть как по мне, преимущества довольно сомнительные, но есть недостатки, создаётся раскол в сообществе, ухудшается и без того не самый хороший тулинг. Уж лучше все силы, что были потрачены на создание hpack ушли бы в cabal — добавить в exposed-modules какое-нибудь поле типа automatic, и весь hpack был бы не нужен.

Wiki.haskell.org?

https://github.com/ruHaskell/ruhaskell/wiki/%D0%A4%D0%B0%D0%B9%D0%BB%D1%8B-%D0%BA%D0%BE%D0%BD%D1%84%D0%B8%D0%B3%D1%83%D1%80%D0%B0%D1%86%D0%B8%D0%B8-stack-%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%BE%D0%B2

https://github.com/ruHaskell/ruhaskell/wiki/%D0%A4%D0%B0%D0%B9%D0%BB%D1%8B-%D0%BA%D0%BE%D0%BD%D1%84%D0%B8%D0%B3%D1%83%D1%80%D0%B0%D1%86%D0%B8%D0%B8-stack-%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%BE%D0%B2

Спасибо

не сказал бы, что это непопулярное мнение

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

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

У hpack более разумные умолчания. dependencies: - base executable: main: Main.hs минимальный package.yaml

Что там у кабала?

У hpack более разумные умолчания. dependencies: - base executable: main: Main.hs минимальный package.yaml

Я помню вот такой блог пост, где человек шаг за шагом пытался создать минимальный .cabal файл: https://jpvillaisaza.github.io/2017/03/14/minimal-cabal-files/ Но как по мне, минимальный размер — вообще не проблема, если используешь какую-нибудь тулу, которая создаёт новый проект за тебя: cabal init или stack new или summoner.

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

Чем меньше рутинных кусков конфига, тем проще его читать.

мне нравится идея минималистичных файлов, я считаю, что редактирование чего-либо автосгенерированного от сатаны

т.е. если автосгенерил, то оставь и не трогай

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

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

Потому что не академики в тулинг не могут. Вот если бы фейсбук или гугл пилили что-то большое на хаскеле, тулинг бы и появился

т.е. если автосгенерил, то оставь и не трогай

а как тебе идея скаффолдинга?

ну так это о чем я говорю, не нравится

вот человеческий мозг генерирует какие-то строчки и мы их кладем в файлы, это поэтому назвываются ИСХОДНЫЕ файлы если что-то потрогал компьютер, это уже не исходные, а сгенерированные файлы

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

скаффолдинг решает проблему не избыточности, а порога входа

просто пустой файл должен быть валидной конфигурацией

просто пустой файл должен быть валидной конфигурацией

полностью поддерживаю

да, кабал плохой формат, ну так и хпак плохой, нормальных улучшений нет, а боли от двух форматов и еще и генерации файлов есть

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

Сорец на хаскеле а ля конфиг XMonad бы кто запилил :) Шоб со статической проверкой, комплитом в редакторе на основе типиков

язык общего назначения для конфигурации тоже ничего хорошего (но все равно лучше чем кабал и хпак)

есть уже один необщего - Nix

Вон в кложурке проект описывается в виде EDN-словарика. Мне нравится

я про него высказался уже, он именно как язык плохой

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

Makefile?

нет

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

из чего во что?

из пакетов в пакеты

да, фвп в общем случае

из "модулей" в "модули"

"сложна"(с)

или я не слишком понимаю идею

helloWorld :: (Has Prelude p, Has TypeApplications c => p -> c -> Obj helloWorld p c = c $ main p main Prelude{..} = { main = print @Int 42 }

хз офтоп или нет, но jetbrains mps никто не трогал?

В книжке харпера норм про модули написано

Но насколько я понимаю после функторов ещё чо-то придумали, но я только только пайпер видел

миксины

https://people.mpi-sws.org/~rossberg/mixml/mixml-toplas.pdf

Я и так и не понял как они работают

Полупрямая сумма меня смущает

еще можно https://people.mpi-sws.org/~dreyer/thesis/main.pdf почитать

Ну они тут как раз что-то в духе dhall'а предлагают (только на уровне модулей)

helloWorld :: (Has Prelude p, Has TypeApplications c => p -> c -> Obj helloWorld p c = c $ main p main Prelude{..} = { main = print @Int 42 }

чёт хардкорно слишком

Ну я когда на SML писал, было прикольно

Скорее у них проблема в том, что они юзают их как тайпклассы

возможно, но это так, псевдо псевдокод, я его не приходя в сознание написал

как тайпклассы их особо не поюзаешь

Поэтому и загнулось

не совсем

https://twitter.com/ruHaskell/status/1017070493986426881

Переехать в токс? (табличка сарказм для непонимающих юмора)

гоу в кейбэйс, там даже гит встроенный)

Можно поднять селф-хостед маттермост

@cblp_su а дискорд открытый что ли? Последний раз когда искал нормальную опцию, это был Keybase