Alexander
реакт бы кто портировал
Alexander
а то несолидно
Cheese
а для клиентской стороны Пурскрипт и Эльм. зачем ещё один такой же язык?
Cheese
вроде уже портировали https://pursuit.purescript.org/packages/purescript-react/5.1.0
Alexander
пурскрипт не считается
Cheese
и даже на сабж https://github.com/fpco/ghcjs-react
Cheese
пурскрипт не считается
пока Хаскель нормально не заработает в браузере, Пурскрипт считается за Хаскель
Alexander
пока Хаскель нормально не заработает в браузере, Пурскрипт считается за Хаскель
там llvm и wasm обещали вроде
Alexander
петпроджекты по идее уже можно делать
Евгений
Пурскрипт не хаскель по очевидным причинам (ибо не ленивый), но лучше ризона, естественно
Cheese
наш эксперт @A64m_qb0 говорит, что в WAsm не хватает важных для Хаскеля примитивов
Влод
да что вы ждёте то от wasm?
Влод
там можно просто числа складывать
Влод
всё
Дима
Нет конечно
A64m
наш эксперт @A64m_qb0 говорит, что в WAsm не хватает важных для Хаскеля примитивов
анрегистеред-то все равно можно сделать, и все равно будет быстрее ghcjs-ного продукта
Дима
Но все почему-то думают что wasm для них специально делали
Alexander
wasm в первую очередь будет лучше чем js.gz
A64m
Пурскрипт не хаскель по очевидным причинам (ибо не ленивый), но лучше ризона, естественно
тайпклассами и синтаксисом?
Alexander
тайпклассы это счастье
Дима
Я думаю медленнее чем буквальное прочтение ghc в браузере воббще нереально сделать даже если постараться. ghcjs это такая видимость решения проблемы, чисто формальная, кому совсем припёрло
A64m
да что вы ждёте то от wasm?
того что в него, пусть и с костылями, можно нормальные языки компилировать?
Alexander
единственная нормальная реализация ООПшных интерфейсов
Влод
того что в него, пусть и с костылями, можно нормальные языки компилировать?
а где-то есть продвижения в эту сторону?
Дима
Есть
Дима
Но это всё равно не то чего все ожидают
Alexander
мне всетаки кажется, что люди ожидают чтобы было быстрее чем трансляция в js
Alexander
и эти ожидангия оправдываются
Дима
Вы не будете делать интерфейс на нём, это попросту оверкилл. И на этом месте внезапно выясняется что других желаний у людей как-то не наблюдается
Dmitry
Коллеги, поясните один момент. Вот если я делаю stack install snap-loader-static - всё ок, пакет ставится, всё отлично
Влод
есть какая нибудь надежда что в этом или следующем году можно общаться с гц-шными объектами?
Влод
я просто давно не смотрел как там у них дела
Dmitry
Но если он в .cabal файле - то всё падает, stack init упорно не видит пакет
Дима
мне всетаки кажется, что люди ожидают чтобы было быстрее чем трансляция в js
Всё быстрее чем безумная идея затащить весь хаскел в рантайм
Dmitry
где в этом логика?
Alexander
Вы не будете делать интерфейс на нём, это попросту оверкилл. И на этом месте внезапно выясняется что других желаний у людей как-то не наблюдается
почему сразу оверкилл? Можно будет использовать одни и те же модели данных на фронте и бэке, это удобно
Alexander
статические проверки api это счастье
Alexander
а какого то оверхеда по сложности разработки для интерфейсов не будет имо
Дима
есть какая нибудь надежда что в этом или следующем году можно общаться с гц-шными объектами?
Я не могу сказать про сроки но концепция gc разрабатывается, но чтобы сразу исключить запросы в духе "мне нужен был от gc %feature_name%" его делают максимально низкоуровневым, набором инструментов чтобы каждый сам себе сделал тот gc который потребуется (если вывезет)
A64m
Всё быстрее чем безумная идея затащить весь хаскел в рантайм
не совсем, из-за гхц-ного оптимизатора результат может быть быстрее того, если хаскельный рантайм на яваскрипте не делать но и не оптимизировать нормально (а кто там нормально оптимизирует-то?)
Влод
нет
Дима
почему сразу оверкилл? Можно будет использовать одни и те же модели данных на фронте и бэке, это удобно
Если у вас нельзя так делать сейчас то это, конечно, весьма грустно
Влод
я не про кастомный гц
Alexander
Если у вас нельзя так делать сейчас то это, конечно, весьма грустно
предлагаешь бэкенд на node.js?
Влод
про общение с объектами из хипа
Влод
гц-шного
Дима
предлагаешь бэкенд на node.js?
Нет. Я не вижу ни единой причины почему модели должны быть привязаны к языку в случае нормальной реализации
Влод
чтобы хоть какой то здравый язык можно было сделать
Alexander
Нет. Я не вижу ни единой причины почему модели должны быть привязаны к языку в случае нормальной реализации
ну в этом есть своя логика
Alexander
надо бы подумать об этом
Дима
Причём я сейчас не умозрительно рассуждаю, а у нас так и есть
Alexander
dtdшки трансилруете в код?
Дима
Бэкенд и все платформы работают на единой основе. Скала -> js, ObjC, Desktop и ещё что-то, короч все платформы
Aleksei (astynax)
Коллеги, поясните один момент. Вот если я делаю stack install snap-loader-static - всё ок, пакет ставится, всё отлично
stack install не устанавливает пакеты, сторого говоря. Они просто скачиваются, собираются и сохраняются в кэше соответствующего снапшота
Aleksei (astynax)
вот если "устанавливать" программу, а не билиотеку, то полученный исполняемый файл потом копируется в ~/.local/bin и получается "установка"
Aleksei (astynax)
В конкретном проекте пакет может не подцепляться потому, например, что пакет отсутствует в снапшоте. Тогда потребудется указание в секции extra-deps в stack.yaml
Aleksei (astynax)
@ahiddenseeker даёте больше информации - ошибку от stack, строку с зависимостью в .cabal
Dmitry
@astynax спасибо, уже сам разобрался, просто прописал в extra-deps stack.yaml, предварительно сгенерив его через stack init с пропуском пакетов.
Aleksei (astynax)
👍
Andrei
Бэкенд и все платформы работают на единой основе. Скала -> js, ObjC, Desktop и ещё что-то, короч все платформы
круть. исходники кодогенератора открыты?
доня.
а как вообще со всем этим IDE дружат?
доня.
ну то есть делаете ли что-то чтобы не ломался комплит и инспекции, если да то что, если нет то как жить?
Andrei
а как вообще со всем этим IDE дружат?
если там валидный исходник, то должно быть всё нормально
Denis
DSL и кодогенерация должны быть настолько удобными, чтобы ими можно было даже без мысли об IDE пользоваться.
Denis
но это в идеальном мире
доня.
если там валидный исходник, то должно быть всё нормально
хм, то есть получается кодогенератор генерирует модель один раз и она кладётся вместе с исходниками?
я просто думал типа как в kapt (процессор аннотаций для котлина), там код генерируется сразу в папку билда, то есть он не попадает в git репозиторий и всё такое, что с одной стороны логичнее, с другой стороны требует некоторых телодвижений для того чтобы в IDE не ломались инспекции, комплит и всё такое
доня.
DSL и кодогенерация должны быть настолько удобными, чтобы ими можно было даже без мысли об IDE пользоваться.
я всё ещё не уверен что кодогенерация вообще должна быть, в целом это всегда выглядит как некий костыль)
Andrei
хм, то есть получается кодогенератор генерирует модель один раз и она кладётся вместе с исходниками?
я просто думал типа как в kapt (процессор аннотаций для котлина), там код генерируется сразу в папку билда, то есть он не попадает в git репозиторий и всё такое, что с одной стороны логичнее, с другой стороны требует некоторых телодвижений для того чтобы в IDE не ломались инспекции, комплит и всё такое
не, версионировать нагенеренное обязательно. его только мержить нельзя.
доня.
> версионировать нагенеренное обязательно
зачем, если версионировать исходник (допустим то же описание модели в JSON)?
Andrei
я всё ещё не уверен что кодогенерация вообще должна быть, в целом это всегда выглядит как некий костыль)
ну в руби генерят код в рантайме, начиная со stdlib. это адочек. все 5 лет, которые я это ворочаю.
доня.
ну в руби генерят код в рантайме, начиная со stdlib. это адочек. все 5 лет, которые я это ворочаю.
не, я немного про другое
в целом почти все применения кодогенерации которые я встречал выглядят как костыль для обхода ограничений языка (взять хоть тот же Go с его отсутствием дженериков и какими-то приблудами для эмуляции дженериков через собственно кодогенерацию внешними тулзами)
Andrei
> версионировать нагенеренное обязательно
зачем, если версионировать исходник (допустим то же описание модели в JSON)?
затем, чтобы нагенеренное точно соответствовало исходнику и чтобы по исходникам было проще ползать из вебморды гитхаба/bitbucket/gitlab и сторонних инструменты вроде Upsource
Denis
если уж кодогенерация есть, то под гитом я её видеть как правило не хочу
доня.
не, я немного про другое
в целом почти все применения кодогенерации которые я встречал выглядят как костыль для обхода ограничений языка (взять хоть тот же Go с его отсутствием дженериков и какими-то приблудами для эмуляции дженериков через собственно кодогенерацию внешними тулзами)
но вот в случаях когда надо разные языки связать альтернатив вроде как нет