вот case заставляет продумывать и ЗАПИСЫВАТЬ все варианты развития событий даже если они тупы е и на первый взгляд излишни, но в долгую такая практика дает более предсказзуемые результаты

if плох тем что позволяет не писать else, а это неявность в коде. а код должен быть явным. if без else в любом языке плох

А вот это уже реальный перегиб

А вот это уже реальный перегиб

почему? в других языках советуют даже писать if (cond) { полезное действие } else { // сюда мы не попадем никогда или printf() или throw HOW??? } на а когда в Elixir есть case и cond которые ругнуться если ты забыли указать все варианты, то выбор очевиден

if же это макрос в Elixir, иногда мне кажется его затянули туда чтобы у новичков не было слома парадигмы

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

Зчем if, когда есть pattern matching =)

почему? в других языках советуют даже писать if (cond) { полезное действие } else { // сюда мы не попадем никогда или printf() или throw HOW??? } на а когда в Elixir есть case и cond которые ругнуться если ты забыли указать все варианты, то выбор очевиден

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

Тут как минимум 3 есть: https://github.com/h4cc/awesome-elixir/blob/master/README.md#orm-and-datamapping

Остальные 2 древние и не поддерживаются

Я думаю что if имеет смысл только в однострочниках без else

Говорить о том, что case матчи все - не приходится, тут не Rust

Но мне просто if визуально не нравится

А ещё он заставляет от декларативного «сравни что-то с паттерном» переходить к императивному «а вот если это равно тому то»

Поэтому cond такое же фуфло

Ой я тут поздно вкатился. &&...|| это тоже самое, что и иф?

почему? в других языках советуют даже писать if (cond) { полезное действие } else { // сюда мы не попадем никогда или printf() или throw HOW??? } на а когда в Elixir есть case и cond которые ругнуться если ты забыли указать все варианты, то выбор очевиден

Где такое советуют? В императивных языках if без else встречается часто: void foo(Bar bar) { if(bar is null) bar = new Bar(1234); do_work(bar); ... if(something) return; ... } А в эликсире можно в императив.

Где такое советуют? В императивных языках if без else встречается часто: void foo(Bar bar) { if(bar is null) bar = new Bar(1234); do_work(bar); ... if(something) return; ... } А в эликсире можно в императив.

была такая статься про такие "мелочи" с if и не только, искал но не нашел, но я в общем то полностью согласен с ее автором. там в качестве подопытного кролика выступал python, но принципы то везде одинаковы ну и что с того что встречается часто ? ))))

В хаскеле if без else нельзя использовать

Как тут говорили if без else это неявно. Я поддерживаю.

Где такое советуют? В императивных языках if без else встречается часто: void foo(Bar bar) { if(bar is null) bar = new Bar(1234); do_work(bar); ... if(something) return; ... } А в эликсире можно в императив.

это будет лучше void foo(Bar bar) { case bar do null -> do_work(new Bar(1234)); bar -> do_work(bar); end ... case something do false -> do_smth_else() true -> return end }

и похрен что текста больше

Как тут говорили if без else это неявно. Я поддерживаю.

в ФП согласен, в императиве нет.

это будет лучше void foo(Bar bar) { case bar do null -> do_work(new Bar(1234)); bar -> do_work(bar); end ... case something do false -> do_smth_else() true -> return end }

Это абберация от ФП. Никто так не пишет в императивных языках.

if в эликрсире, скорее всего из руби приползло

Это абберация от ФП. Никто так не пишет в императивных языках.

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

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

?

Это абберация от ФП. Никто так не пишет в императивных языках.

ты лично знаешь всех кто пишет на императивных языках? ))))

Да

Все кто пишут иначе не програмируют на императивных языках. Они только думают, что программируют на императивных языках.

В погоне за явностью так можно не только до if'а докопаться

Всегда же будет что-то сокрыто ради удобства

Скрытый else блок по-моему довольно безобидная неявность ещё

Ага. А в целом это попахивает Специальной Олимпиадой.

Все кто пишут иначе не програмируют на императивных языках. Они только думают, что программируют на императивных языках.

а о чем я думаю?

В плане cond, он имеет значение в таких случаях: cond do closes_tag?(rest_hd, needed_hd) -> do1(...) opens_tag?(rest_hd) -> do2(...) true -> do3(...) end # Альтернативы:... кхм if closes_tag?(rest_hd, needed_hd) do do1(...) else if opens_tag?(rest_hd) do do1(...) else do3(...) end end case closes_tag?(rest_hd, needed_hd) do true -> do1(...) false -> case opens_tag?(rest_hd) do true -> do2(...) false -> do3(...) end end

Когда есть 2 или более различных условиях, которые не описываются через match, тогда переписать без cond do - это либо портянка из if, либо портянка из case-ов будет вместо одного очень понятного cond.

В общем, как и в случае с if: не представляю кому приятно будет читать и писать (видимо из принципа) портянку из вложенных if-ов в elixir-е или case-ов вместо одного более понятного и не вложенного cond-а. Тоже самое и с Erlang-овским if - его стоит избегать, когда можно переписать и без него, но вот чисто из принципа, даже если с ним код будет намного проще для чтения, сомнительная практика. Имхо.

Чисто из принципа - это всегда плохо. Фанатики - идут лесом.

Да ну вчера был дан исчерпывающий ответ почему иф это плохо) потому что это тупо макрос к case.

@Nekifirus Elixir - как язык состоит из множества макросов.

Из-за стоит отказаться от всех макросов и писать на true SpecialForms?

Ну да) просто с ифом действительно кейз лучше)

Я не согласен с этим "ответ-ом"

так то по барабану. на ифе 3 строчки, на кейз 4, где последняя строчка end)

Я приводил случаи вчера, где if - одна строчка, а всё остальное (включая case-а - 4).

Чо та второй день выясняем уже это))))

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

Чисто из принципа - это всегда плохо. Фанатики - идут лесом.

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

пардон телепатических

В плане cond, он имеет значение в таких случаях: cond do closes_tag?(rest_hd, needed_hd) -> do1(...) opens_tag?(rest_hd) -> do2(...) true -> do3(...) end # Альтернативы:... кхм if closes_tag?(rest_hd, needed_hd) do do1(...) else if opens_tag?(rest_hd) do do1(...) else do3(...) end end case closes_tag?(rest_hd, needed_hd) do true -> do1(...) false -> case opens_tag?(rest_hd) do true -> do2(...) false -> do3(...) end end

Если есть 10 условий - их можно матчить через тупл

Неэффективно, потому что он все 10 расчитает вместо того, чтобы по порядку необходимости.

Если есть вычисления - разбивается на функции

Не более одной хоть какой либо тяжелой операции за функцию - и все

А вот если надо к примеру взять пару значений из нескольких структур - да вообще насрать на то, что это делается не лениво

Зато наглядно

Если такое станет ботлнеком - надо уже на ассемблере программу предписывать, и никакой cond не спасёт

Разбивать на функции (или создавать вложенность - в виде case-ов или функций) вместо одного наглядного cond?

Cond не наглядный

Hello, Лакки! Please, calculate: 20+64=... If you don't answer - you'll get banned from the channel... Good luck!

Cond не наглядный

Как по мне...

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

Ну а какая тут неявность? if(bar is null) bar = new Bar(1234); Никакой телепатии тут не нужно.

вчера с Никитой (Соболевым) разговаривал, он сказал у них credo настроен что бы ругалось, если в коде юзают if-ы)

вчера с Никитой (Соболевым) разговаривал, он сказал у них credo настроен что бы ругалось, если в коде юзают if-ы)

в эликсире вполне оправданно, хотя и перебор, по моему скромному.

Ну а какая тут неявность? if(bar is null) bar = new Bar(1234); Никакой телепатии тут не нужно.

if (bar is null) { bar = new Bar(123); } else { // переданный в функцию указатель должен быть null, иначе оставляем его как есть тк в случае перезаписи мы должны будем подестроить старый объект // а это делается в другом месте } if (bar is null) { bar = new Bar(123); } else { // это основной кейс, в противном случае создаем заглушку } if (bar is null) { bar = new Bar(123); } else { // это условие находится здесь, чтобы не проверять bar на null каждый раз перед вызовом этой функции }

ну и такой код легко рефакторить

Долго пришлось думать, чтобы придумать эти "неявности"? Все гораздо проще: если объект не создан, создаем новый.

Интерфейс функции задокументирован, что там внутри - это дело самой функции и комментариев внутри нее

Долго пришлось думать, чтобы придумать эти "неявности"? Все гораздо проще: если объект не создан, создаем новый.

почему не создан? почему можно создать его здесь? это нормально или хак? можно ли перенести это создание в другое место?

откуда взялись параметры и тд.

ну для этого паттернг-матчинг же есть def func(bar) when bar is integer do def func(bar) when is_nil(bar) do def func(_) do

дооолгооо)))

почему не создан? почему можно создать его здесь? это нормально или хак? можно ли перенести это создание в другое место?

Ну дык на эти вопросы и код с else не ответит. Для этого комментарии придуманы. Так то.

ну для этого паттернг-матчинг же есть def func(bar) when bar is integer do def func(bar) when is_nil(bar) do def func(_) do

Мы обсуждаем императивный язык.

паттерн-матчинг там редко встретишь

Ну дык на эти вопросы и код с else не ответит. Для этого комментарии придуманы. Так то.

комментарии надо писать по месту

если в коде if все явно написано то остается смысловая неявность и ее надо разрешать по месту

комментарии надо писать по месту

ага, дык еще раз повторяю, код c else в данном случае ничего не прояснит, все равно придется писать комментарии если сильно нужно

ага, дык еще раз повторяю, код c else в данном случае ничего не прояснит, все равно придется писать комментарии если сильно нужно

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

если в коде if все явно написано то остается смысловая неявность и ее надо разрешать по месту

нет никаких неявностей поведение if без else четко прописано в спеках.

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

неявности нет

код прозрачен

ага, дык еще раз повторяю, код c else в данном случае ничего не прояснит, все равно придется писать комментарии если сильно нужно

и потом что значит "сильно нужно" ? если кроме тебя код никто никогда читать не будет то и не пиши вообще ничего

код всегда пишется для других программистов

и потом что значит "сильно нужно" ? если кроме тебя код никто никогда читать не будет то и не пиши вообще ничего

Это значит насколько код понятен. Требует ли он пояснения или и так все понятно любому. Вы же не комментируете каждую строчку в программе?

x = x + 2; // прибавляем к x 2

код прозрачен

не прозрачен я и понятия не имею почему в данном месте объект мб null и почем мы можем создать его внутри когда он приходит снаружи. он еще по ходу где то создает и может не в одном месте ))

не прозрачен я и понятия не имею почему в данном месте объект мб null и почем мы можем создать его внутри когда он приходит снаружи. он еще по ходу где то создает и может не в одном месте ))

документация к самой функции поможет

допустим я вставлю else, и что сразу все станет ясно?

документация к самой функции поможет

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

x = x + 2; // прибавляем к x 2

ну перегибать то не надо

И так, повторяю: допустим я вставлю else, и что сразу все станет ясно?

допустим я вставлю else, и что сразу все станет ясно?

конечно, и комментарий напиши хотя бы // не беспокойся я обо всем позаботился

очевидно же что пустой else проблемы не решает

или не очевидно?

Хех. Ну и какую доп инфу дает код void foo(Bar bar) { if(bar is null) do_work(new Bar()); else do_work(bar); } по сравнению с void foo(Bar bar) { if(bar is null) bar = new Bar(); do_work(bar); } ?

Хех. Ну и какую доп инфу дает код void foo(Bar bar) { if(bar is null) do_work(new Bar()); else do_work(bar); } по сравнению с void foo(Bar bar) { if(bar is null) bar = new Bar(); do_work(bar); } ?

да хотя бы тем что первый snippet выглядит читабеленее