можно конкретно в данном случае

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

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

а тупые то конечно и там и везде

можно конкретно в данном случае

я не знаю

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

поддерживаю этих ребят

ну я точно тупой

это конечно в blah

в общем использование unsafePerformIO для создания топ-левел констант инициализация которых в IO это один из немногих валидных юзкейсов

естественно с uninline

noinline

(тупой Т9)

но константа действительно должна быть константой

это хуже reader тем, что нету функции local

так же тем что по типу такого поведения не видно

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

учитывая, что это используется для отладки - не платить трейдоф за ReaderT просто так - вполне нормально

учитывая, что это используется для отладки - не платить трейдоф за ReaderT просто так - вполне нормально

преждевременная оптимизация?

господи

вы на хаскеле пишете, хеллоу

надо различать преждевременную оптимизацию и правильное проектирование

надо различать преждевременную оптимизацию и правильное проектирование

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

вот я уверен что фраза про преждевременную оптимизацию вырвана из контекста. А привела она ко всему этому горькому катаклизму который я тут наблюдаю... И Владимир Николаевич тоже

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

как и неиспользование

соглашусь

вот я уверен что фраза про преждевременную оптимизацию вырвана из контекста. А привела она ко всему этому горькому катаклизму который я тут наблюдаю... И Владимир Николаевич тоже

Может и вырвана, но ботлнек это (почти)всегда ио, а не вот это вот.

делать ReaderT на любую константу (или runtime константу конечно можно)

Может и вырвана, но ботлнек это (почти)всегда ио, а не вот это вот.

только если IO это ботлнек в ТВОЁМ приложении

но это же почти всегда

Почти всегда в каких задачах то? В компиляторе? Или в рейтрейсере? Или в игрушках (разве что IO с gpu) ?

во многих

тут-то ботлнек при чем?

ReaderT Conf имеет смысл если зависимость от Conf это важная часть приложения

кстати есть веселая либа hflags

там все радостные практики связаны, TH, сборка инстансов в Main, unsafePerformIO

unsafe у unsafePerformIO т.к. через него можно сделать unsafeCoerce

Не только. IO будет выполняться неопределённое число раз. Можно нарваться на случае, когда мутабельный буфер будет шарится, когда не должен и не будет шарится, когда должен

идеология в инженерных науках неприемлима

я буду спорить

идеология не только приемлима, она еще и нужна

не нужна, нужна аргументация нормальная и доводы

Если нет идеологии, то получается c++

Без нее можно скатиться в локальные максимумы слишком легко. Если адекватно взвестить все за и против, можно прийти к решению, которое в данном контексте наилучшее. Идеология может (а хорошая - должна) привести к качественным прорывам

А если есть — эльм

Например, можно было использовать unsafeCoerce потому что так быстрее и "I know what I'm doing", а можно было придумать Coercible

Ну и собственно вариант с unsafeCoerce и привел к тому, что до ролей и Coercible у нас GND был subtly broken

Или еще пример. Если руководствоваться только практикой и юзкейсами, можно взять и придумать stack, а потом страдать с его снэпшотами. А можно до последнего добиваться нормального солвера и придумать cabal new-build с nix-style storage

ЧТД

Практики можно тут спрашивать, если что. Мы хоть посремся

Мне кажется, что @qnikst и @int_index понимают под идеологией разные вещи

а вы при разработке используете репл?

немножко

немного, т.к. полноценно тулинг не позволяет

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

немного, т.к. полноценно тулинг не позволяет

а можешь подробнее описать?

я просто для запуска м проверки простых вещей и быстрого ребилда использую

ну я тоже для проверки простых вещей

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

я когда надо что-то посложнее сделать - делаю модуль отдельный и его загружаю

в репл

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

Он про лиспы в первую очередь пишет. А там REPL-driven development совсем иначе выглядит

Позднее связывание же

ну я понимаю - я поэтому и спросил

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

и мне очень не хвататет его в других местах

*языках

*языках

вроде во многих есть реплы

в других - это у меня Го, правда я уже на нем не писал совсем месяца 3-4

для репла нужно или лиспом быть лиспом или много тулинга

Репл в хаскеле заменяет 80 юзкейзов дебагера в плюсах

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

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

Один из юзкейзов репла: удобно было структурки данных сериализовать на лету, чтобы затем написать бинарный протокол в документации (на случай если захотят люди на других языках реализовать протокол). А сейчас репл используется, чтобы тестировать Servant-овские хэндлеры, выполняющие SQL запросы. Используется protocol-buffers, поэтому непосредственно эндпоинты потестировать какой-нибудь тулой возможности нет, а вот из репла вызвать функции и посмотреть результат вполне можно. Не то, чтобы это было очень удобно (особенно когда надо всякие сессии создать, прежде чем потестировать), но зато хотя бы как-то возможно.

> Используется protocol-buffers, поэтому непосредственно эндпоинты потестировать какой-нибудь тулой возможности нет любопытно

так в аллегро телеграмм работает, а линкедин нет

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

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

ну мне кажется что это взлетит, но на практике я не прове😼рял

елки палки.. откуда тот смайл :/

Или еще пример. Если руководствоваться только практикой и юзкейсами, можно взять и придумать stack, а потом страдать с его снэпшотами. А можно до последнего добиваться нормального солвера и придумать cabal new-build с nix-style storage

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

то есть если у меня B depends on A v1 C depends on A v2 D depends on B, C то не соберётся?

А раньше могло собраться?

не, я про то когда у A одинаковые версии, а вот версии зависимостей разные

А раньше могло собраться?

емнип в самом первом демо http://blog.ezyang.com/2015/08/help-us-beta-test-no-reinstall-cabal/ это работало, а уж в планах точно было