A64m
если по какой-то причине хочется пользоваться каким-то ленгвидж сервис костылем вроде hie, то все, нью-билд не подходит Ж(((
Dmitrii
Да ладно, новичкам (и не только) удобно же :)
Во время преподавания курса Haskell я заметил несколько минусов для новичков при использовании stack:
1. Нужно еще понимать stack.yaml и концепции snapshot'ов, чтобы создать проект, порог вхождения увеличивается. Не говоря про те случаи, когда надо еще патчить extra-deps, чтобы сбилдилось.
2. stack new не может создать полноценный проект, если нет интернета или интернет фиговенький.
3. Последние версии stack по умолчанию создают package.yaml файл, и тут у новичков вообще едет крыша, когда они пытаются редактировать .cabal файл, а все равно ничего не работает.
4. Поведение команды stack repl внутри какого-нибудь проекта и вне проекта разное, потому что вне проект используется неявный снэпшот в ~/.stack/global-project/stack.yaml и там по разному ставятся разные тулы.
Я написал beginner-friendly туториал для новичком по использованию cabal new-build и stack, поэтому теперь хотя бы могу скидывать людям, что почитать, если они захотят проекты на Haskell создавать
Dmitrii
Но все равно очень много вопросов и проблем возникает при попытках создать первый проект с зависимостями и все такое...
Vladislav
https://github.com/haskell/cabal/issues/5425
Vladislav
Вот такого не хватает. Посмотрим, какой повод найдут, чтобы не имплементить
Vladislav
Ради этого до сих пор stack запускаю. Он, конечно, медленный, это раздражает.
Timofey
Вопрос по парсингу:
- есть ленивый байтстринг (грубо говоря, результат svn cat, вытащенный через typed-process), который точно является ascii.
- почти все необходимые парсеры будут иметь сигнатуру Parser String или что-то в этом же духе
- я могу байтстринг запаковать в стринг/текст и парсить без особых напрягов тем же мегапарсеком
- попробовать перезаточить все парсеры под потребление байтстринга, но огрести распаковку/запаковку условий и результата парсинга
Собственно, вопрос - что будет работать быстрее?
Kirill
сделать бенчмарк и посмотреть? :)
Timofey
этот вариант всегда есть, да=) Мне бы какую-то априорную эвристику=)
Kirill
вообще быстрее вариант будет с минимумом переупактовки/перекодировки
A64m
какое-то время назад смело рекомендовал стек для начинающих, но потом началось это адище с package.yaml и тут стали чуть не каждый день спрашивать почему ничего не работает. теперь даже не знаю, что и рекомендовать Ж(((
Kirill
а есть ещё mafia к примеру
Aleksei (astynax)
Kirill
хотя оно, конечно, поверх кабала
Aleksei (astynax)
снапшоты - коллер-фича. Я помню всю эту возню с подбором версий, которую имел до появления stack.
Новичку в любом случае сложно в Haskell.
Aleksei (astynax)
И уж не сложнее, чем в JS, со всеми из package.json, webpack.js, babel.js или что там ещё у них?
Kirill
и войнушки аля stack vs cabal не помогают как минимум
Leonid 🦇
а когда в 8.4.3 завезут поддержку федоры 28?
Aleksei (astynax)
hpack по умолчанию - странное решение, наверное. Хотя мне нравится
Kirill
@lonokhov прям гхц надо чинить для поддержки дистра?
Leonid 🦇
@lonokhov прям гхц надо чинить для поддержки дистра?
ну это так, шутканы про стэк за 300 https://www.reddit.com/r/haskell/comments/8xw4tl/when_will_843_support_fedora_28
Leonid 🦇
т.е. кому и стэк == хаскель
A64m
война кабалистов против снойманитов не помогает, потому что ведется недостаточно интенсивно. когда стеку надо было завоевывать пользователей они там что-то делали, старались, сейчас ничего не работает, на все плевать, странные решения, новинки годами не поддерживаются.
A64m
если бы кабалисты получше ударили по снойманитам, быстрее бы делали кабал 3 и т.д. снойманитам тоже пришлось бы что-то делать, кроме сабатирования всего нового что есть в хаскеле и подведения обоснований под то что ничего полезного делать не надо
Kirill
ну кабалисты ломают форматы хотяб :)
Aleksei (astynax)
Вся ситуация с разбродом и шатаниями в целом плохая. А не "стэк плохо" или "кабал плохой"
A64m
даже ситуация с разбродом и шатаниями лучше предыдущего болота, когда пять лет еле еле как бы делали новый кабал с нулевым видимым эффектом
Alexander
Да все у нас хорошо в сравнении с экосистемой JS. Там никто по этому поводу не парится
Kirill
ну вроде чуть парятся
Kirill
чот там недавно про npm vs yarn было
Alexander
Там еще кучи разных тулзов для установления нужной версии node.js, например
Alexander
И всяко в Хаскеле лучше, чем в С++, где проект через год лежания на компьютере, который ты не включал, может вообще без всякой причины не собраться.
Aleksei (astynax)
В среднем в Haskell неплохо, это уж точно
Aleksei (astynax)
Но специфика, обусловленная тем, что "так сложилось", есть
Aleksei (astynax)
И cabal-hell ещё из памяти не стёрся :)
Kirill
а где её нет?
Aleksei (astynax)
Везде есть в разной степени
Aleksei (astynax)
cargo - приятный
Aleksei (astynax)
pip - дно
A64m
от того что кто-то там страдает от писания на языке, на котором уже и не пишешь давно, а может и не писал никогда, хаскелисту то не легче.
Aleksei (astynax)
Я однажды хотел pipenv запатчить. Посмотрел в код. Три дня пил валерианку потом. <гифка из со священником, говорящим "Да ну нахер!">
Kirill
кстати в наших краях тоже "энвы" присутствуют - https://github.com/hvr/cabal-env :)
eahqzsr
Я не знаю как работает yarn/npm, но никогда там с зависимостями проблем не было
Aleksei (astynax)
Ага, просто в рантайме валилось
Aleksei (astynax)
npm shrinkwrap тоже придумали просто так, от скуки
eahqzsr
В рантайме тоже не валилось, может библиотеки были слишком мейнстримные
Aleksei (astynax)
В хаскеле возни с версиями больше, потому что всё всместа компилится. Или не компилится. В любом случа еошибки получаются до запуска. В дин.тип языках очень часто проблемы всплывают сильно после бампа зависимостей
Cheese
ну да, NPE раз в неделю — это не считается
eahqzsr
shrinkwrap нужен в первую очередь для врспроизводимой сборки, чтобы либы регрессий не принесли.
Cheese
Cheese
воспроизводимая сборка => минимизация неожиданных багов
Cheese
использовать докер — сложнее, чем не использовать докер
Cheese
использовать что угодно — сложнее, чем не использовать
Aleksei (astynax)
shrinkwrap в любом случае предполагает, что программист знает, что с текущим набором версий сборка работает. Что в целом сомнительно в языке без статической проверки типов
eahqzsr
Я вот не знаю как раньше без докера жил
eahqzsr
shrinkwrap в любом случае предполагает, что программист знает, что с текущим набором версий сборка работает. Что в целом сомнительно в языке без статической проверки типов
Ой, я умоляю. Во-первых, flowtype & typescript. Во-вторых, вопрос не в том чтобы багов не было, а чтобы от сборки к сборке новых не появлялось
Aleksei (astynax)
gradual typing не работает
Aleksei (astynax)
flow ещё туда-сюда
eahqzsr
Ну нужно делать так, чтобы он был не gradual а total
eahqzsr
В новых проектах конечно
Aleksei (astynax)
Т.е. все библиотеки были на 100% типизированы?
Aleksei (astynax)
Зачем тогда писать на JS/TS?
eahqzsr
Ну фронт например
Aleksei (astynax)
React полностью статически проверен и типизирован?
eahqzsr
По крайней мере внешний api типизирован
Aleksei (astynax)
Вот поэтому gradual typing и не работает - типы ка будто есть, но падает всё в рантайме
Aleksei (astynax)
Опциональные типы делают язык лучше (чуть-чуть). Но не делают хорошим
Aleksei (astynax)
Кароч, оффтоп.
eahqzsr
Да
Aleksei (astynax)
Или в blah продолжаем, или соглашаемся, что JS - плохой, негодный язык :)
eahqzsr
Лучше руби всяко
A64m
не надо отвлекаться от стек вс кабал
eahqzsr
Hackage vs stackage?
eahqzsr
Ну вот я не в восторге ни от stack, ни от cabal
A64m
хотя мне в принципе нравятся плоды того что хекедж стал курируемым, мне не нравится, что он стал таким, и первоначальный план для кабала, который подразумевал что тот начнет работать лучше с некурируемой помойкой в основном заброшен