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

npm shrinkwrap тоже придумали просто так, от скуки

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

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

ну да, NPE раз в неделю — это не считается

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

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

об этом и речь

воспроизводимая сборка => минимизация неожиданных багов

а когда в 8.4.3 завезут поддержку федоры 28?

А не проще уже докер использовать?

А не проще уже докер использовать?

Это наброс был

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

использовать что угодно — сложнее, чем не использовать

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

Я вот не знаю как раньше без докера жил

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

Ой, я умоляю. Во-первых, flowtype & typescript. Во-вторых, вопрос не в том чтобы багов не было, а чтобы от сборки к сборке новых не появлялось

gradual typing не работает

flow ещё туда-сюда

Ну нужно делать так, чтобы он был не gradual а total

В новых проектах конечно

Т.е. все библиотеки были на 100% типизированы?

Зачем тогда писать на JS/TS?

Ну фронт например

React полностью статически проверен и типизирован?

По крайней мере внешний api типизирован

Вот поэтому gradual typing и не работает - типы ка будто есть, но падает всё в рантайме

Опциональные типы делают язык лучше (чуть-чуть). Но не делают хорошим

Кароч, оффтоп.

Да

Или в blah продолжаем, или соглашаемся, что JS - плохой, негодный язык :)

Лучше руби всяко

не надо отвлекаться от стек вс кабал

Hackage vs stackage?

начинали с stack vs cabal а в итоге js плохой

лол

Ну вот я не в восторге ни от stack, ни от cabal

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

Ну вот я не в восторге ни от stack, ни от cabal

А какой пакетный менеджер вам нравится?

А какой пакетный менеджер вам нравится?

yarn же

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

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.

ERROR: S client not available

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

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

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

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

либо нужная какая-то супер-хитрая 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 никто не трогал?

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