AK
А, тогда жаль. Не смогу отвечать на претензии, не видя самих претензий.
Size: a a a
2018 March 14
AK
Нет чтобы на публике Эльм не любить, так нет секретничают
AK
Потому что знают что мы за Эльм в ответе. И боятся!
PF
Ну так же можно про любые абстракции писать.
Ну окей, попытаюсь - Generic для генерации декодеров/енкодеров
Линзы для вложенных обновлений
Ну окей, попытаюсь - Generic для генерации декодеров/енкодеров
Линзы для вложенных обновлений
Линзы, написанные вручную, читаются лучше кмк. Это вкусовщина, а не концепиуальное ограничение.
про дженерики не понял. они есть, что же ещё нужно?
про дженерики не понял. они есть, что же ещё нужно?
к
Линзы, написанные вручную, читаются лучше кмк. Это вкусовщина, а не концепиуальное ограничение.
про дженерики не понял. они есть, что же ещё нужно?
про дженерики не понял. они есть, что же ещё нужно?
не генерики, речь про обобщенное программирование зная в рантайме структуру типов (рефлексия в какой-то мере)
через это в хаскеле/пурсе, например, те же энкодеры и декодеры и генерируются
через это в хаскеле/пурсе, например, те же энкодеры и декодеры и генерируются
к
Линзы, написанные вручную, читаются лучше кмк. Это вкусовщина, а не концепиуальное ограничение.
про дженерики не понял. они есть, что же ещё нужно?
про дженерики не понял. они есть, что же ещё нужно?
как они могут читаться лучше, код же точно такой же, только их нужно еще вручную определять, очень-очень много одинакового кода, настолько много что их попросту не использовал
тут правда все равно без кодогенерации не обойтись, иначе придется добавлять еще какие тайпл-левел метки и type application
тут правда все равно без кодогенерации не обойтись, иначе придется добавлять еще какие тайпл-левел метки и type application
PF
не генерики, речь про обобщенное программирование зная в рантайме структуру типов (рефлексия в какой-то мере)
через это в хаскеле/пурсе, например, те же энкодеры и декодеры и генерируются
через это в хаскеле/пурсе, например, те же энкодеры и декодеры и генерируются
рефлексия же утяжеляет рантайм очень сильно и создат дыры в безопасности - зогчем? если чисто для энкодеров/декодоров, то я бы лично не стал эту фичу использовать - я уже давно приловчился кодогенерировать их из жсон-а с сервера с помощью json-to-elm, а не писать вручную.
PF
как они могут читаться лучше, код же точно такой же, только их нужно еще вручную определять, очень-очень много одинакового кода, настолько много что их попросту не использовал
тут правда все равно без кодогенерации не обойтись, иначе придется добавлять еще какие тайпл-левел метки и type application
тут правда все равно без кодогенерации не обойтись, иначе придется добавлять еще какие тайпл-левел метки и type application
если давать им осмысленные имена, то для чтения и вызывающего кода никаких проблем - такой бойлерпоейт попросту не замечаешь.
RS
а кто следит за дискорсом ельмовским? там вобще часто бывает что-то заслуживающее внимания от Эвана?
AK
@bardt от Эвана не часто
PM
Линзы, написанные вручную, читаются лучше кмк. Это вкусовщина, а не концепиуальное ограничение.
про дженерики не понял. они есть, что же ещё нужно?
про дженерики не понял. они есть, что же ещё нужно?
Я слышал такой совет: если вам нужно менять значения где-то в глубине структуры данных, значит у вас что-то не так с архитектурой. Менять нужно только то, что на первом уровне вложенности. Следовательно, линзы не нужны. Что думаете, дельный совет или нет?
QZ
ну в элме просто не завезли удобных механизмов для апдейта структур
QZ
так что да, стараться плоско делать и это не от хорошей жизни
PM
Тут как бы обратный посыл: правильно и хорошо - это плоско, а значит и механизмы «глубокого обновления» не нужны
PF
Я слышал такой совет: если вам нужно менять значения где-то в глубине структуры данных, значит у вас что-то не так с архитектурой. Менять нужно только то, что на первом уровне вложенности. Следовательно, линзы не нужны. Что думаете, дельный совет или нет?
насколько я помню там в оригинале шла речь о том, что архитектурной ошибкой будет большое количество таких выпуклых структур данных, а не единичные случаи - это да. Я для себя выработал критерий, что если подобных вручную написанных линз больше чем 5 - 6 на модуль, то стоит задуматься о рефакторинге
PF
вообще я хочу сказать - всё это фигня не стоящая внимания, а не какая то там концептуальная проблема языка. выпуклые или плоские рекорды - вкусовщина же. А что автор языка навязывает программистам опрелённый подход, ограничивая возможности говнокодить, так это очень даже гут. а недовольные в любом случае будут
rq
глубокое обновление иммутабельных структур это не "вкусовщина"
rq
если у тебя пабсаб, обсерверы etc, можешь делать что угодно, там другие практики
PF
в таком случае создай ишшуй, в которм опиши проблему по всем правилам - с примерами из практики.
а при чём здесь пабсаб ?
а при чём здесь пабсаб ?