Size: a a a

2021 January 04

AL

Anton Lapshin in pro.elixir
так что тут цель зачастую не в том, чтобы переиспользовать один и тот же код, а в том, чтобы упростить его расширение.
типа - писать один плохой объект, который умеет всё, плохо. лучше разделить зоны ответственности. так же и тут. главное в обратную сторону не перегибать при этом :)
источник

ML

Maksim Lapshin in pro.elixir
Mexx
Добрый вечер, я не давно начал алхимить после jvm языков, привлёк beam. Есть вопрос: Имеется проект, там куча модулей и в каждом модуле куча маленьких приватных функций для обработки какого то кейса - Я так понимаю это норм подход. Но меня после императивных языков, очень сильно передергивает что в целом все эти маленькие функции никогда не переиспользуются и по факту в проекте злоупотребляют этим подходом и разбивают сложный алгоритм на множество маленьких кусочков. Это норм в целом или что то не так ?
так значит у тебя и на императивных языках может быть не самая хорошая привычка переиспользовать лишнего.

В руби например или яваскрипте здорово всё испоганено неудачными попытками _лишнего_ переиспользовать.

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

Эликсир тут сам по себе не особо отличается, могут отличаться разве что практики его использования.
источник

LL

Lama Lover in pro.elixir
Mexx
Добрый вечер, я не давно начал алхимить после jvm языков, привлёк beam. Есть вопрос: Имеется проект, там куча модулей и в каждом модуле куча маленьких приватных функций для обработки какого то кейса - Я так понимаю это норм подход. Но меня после императивных языков, очень сильно передергивает что в целом все эти маленькие функции никогда не переиспользуются и по факту в проекте злоупотребляют этим подходом и разбивают сложный алгоритм на множество маленьких кусочков. Это норм в целом или что то не так ?
Это типа самодокументируемый код. Если ты боишься за стек, то можно использовать @compile {:inline, ...}, хотя компилятор, вроде, инлайнит приватные функции, которые используются один раз
источник

AL

Anton Lapshin in pro.elixir
Maksim Lapshin
так значит у тебя и на императивных языках может быть не самая хорошая привычка переиспользовать лишнего.

В руби например или яваскрипте здорово всё испоганено неудачными попытками _лишнего_ переиспользовать.

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

Эликсир тут сам по себе не особо отличается, могут отличаться разве что практики его использования.
мне напротив кажется, что в руби (точнее даже в рельсах наверное) слишком много лишнего написано. миллион однотипных функций и алиасов к ним. миллион разных гемов с объектами, которые _типа_ заточены для одной конкретной цели, но по факту отличаются каким-то мизером (читай: можно сделать из чего-то типового тот же функционал без ещё одной зависимости). весь этот dry-зоопарк, форм-обжекты и прочее
источник

B

Bogdan in pro.elixir
Maksim Lapshin
так значит у тебя и на императивных языках может быть не самая хорошая привычка переиспользовать лишнего.

В руби например или яваскрипте здорово всё испоганено неудачными попытками _лишнего_ переиспользовать.

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

Эликсир тут сам по себе не особо отличается, могут отличаться разве что практики его использования.
Если можно избежать boilerplate то лучше переиспользовать, так легче всеже дебагать,  то в одно место посмотреть, а то в 3 например.
источник

AL

Anton Lapshin in pro.elixir
есть две разницы - переиспользовать грамотно и тащить из одного специфического модуля вызовы в другой специфический модуль. если уж так хочется какой-то общий кусочек иметь - выдели в общий модуль. а если за всё время там нужно по сути два раза эту функцию юзать, зачастую может быть правильнее написать примерно одно и то же в разных модулях. ну т.е. явно продублировать
источник

AL

Anton Lapshin in pro.elixir
короче, мысль слишком обтекаемая, тут надо просто ловить себя на мысли, когда переиспользование ок, а когда и дублирование не зазорно
источник

B

Bogdan in pro.elixir
Да я скорее про выделение в общий модуль имел ввиду…хотя не все так однозначно))
источник

B

Bogdan in pro.elixir
На моменте написания изначального когда я не сильно думаю, что там где будет переиспользоваться. Но дальше если вижу похожие паттерны то выношу в модули, как-то так. А внутри модуля функции редко у меня переиспользуются и у других не часто видел.
источник

AL

Anton Lapshin in pro.elixir
да. ну типа есть у тебя какая-то общая тема, типа вывод строки в число по неким правилам. это точно просится в общее с переиспользованием. а, скажем, раскладывание мапа в список по определённому правилу в разных модулях лучше явно закодить, чем тащить это в некую функцию с флажками там или входящими аргументами для определения поведения
источник

ML

Maksim Lapshin in pro.elixir
Bogdan
Если можно избежать boilerplate то лучше переиспользовать, так легче всеже дебагать,  то в одно место посмотреть, а то в 3 например.
Посмотреть _в одно_ место — как раз заюзать чужой код и вставить его к себе.

Вызвать чужую функцию — посмотреть минимум в два места.
источник

B

Bogdan in pro.elixir
Maksim Lapshin
Посмотреть _в одно_ место — как раз заюзать чужой код и вставить его к себе.

Вызвать чужую функцию — посмотреть минимум в два места.
Да согласен)
источник

M

Mexx in pro.elixir
Ок, спасибо. Да с читаемостью согласен, только если уж не слишком много кусочков. Однозначно паттерн матчинг рулит (просто сложно сразу перестроить после многих if else)
источник

M

Mexx in pro.elixir
Anton Lapshin
есть две разницы - переиспользовать грамотно и тащить из одного специфического модуля вызовы в другой специфический модуль. если уж так хочется какой-то общий кусочек иметь - выдели в общий модуль. а если за всё время там нужно по сути два раза эту функцию юзать, зачастую может быть правильнее написать примерно одно и то же в разных модулях. ну т.е. явно продублировать
Вот тащить из одного, сразу ассоциации со спрингом в сложных/больших энтерпрайз проектов + boilerplate -> пол экрана конструктор с бинами занимает
источник

M

Mexx in pro.elixir
Ещё один вопросик, допустим есть алгоритм где вызывается последовательно много сайд эффектов: обновить одну таблицу в базе, обновить другую и тд. Встретил в коже много случаев когда эти вызовы оформляют в Task.start - вопрос как время выполнения такого запроса повлияет на основной алгоритм? (опять таки тут моё ещё не перестроенное jvm мышление, где все это залочит  thread и чаще всего если результат не важен в данный момент, то запос уйдёт через какой нить message broker)
источник

LL

Lama Lover in pro.elixir
Mexx
Ещё один вопросик, допустим есть алгоритм где вызывается последовательно много сайд эффектов: обновить одну таблицу в базе, обновить другую и тд. Встретил в коже много случаев когда эти вызовы оформляют в Task.start - вопрос как время выполнения такого запроса повлияет на основной алгоритм? (опять таки тут моё ещё не перестроенное jvm мышление, где все это залочит  thread и чаще всего если результат не важен в данный момент, то запос уйдёт через какой нить message broker)
Task.async выполнит переданную функцию в стороннем потоке и будет ждать пока результат запросят через Task.await (или процесс, создавший Task умрёт)
источник

M

Mexx in pro.elixir
А что будет с конекшеном к базе?
источник

B

Bogdan in pro.elixir
источник

B

Bogdan in pro.elixir
Task.async_stream есть еще, посмотри в статье, найдешь как работает.
источник

B

Bogdan in pro.elixir
А зачем, кстати базу таким образом обновлять?
источник