Bulletproof you say 
…
iex (19) { opt1, opt2 } = { nil, "opt2" }
{nil, "opt2"}
iex (20) if true, do: opt1, else: opt2
nil
iex (21) true && ( opt1 || true ) || opt2
true
smathy
3
mudasobwa
Creator of Cure
sodapopcan
smathy
It’s the weekend, expectations were very low, but you exceeded them anyway 
You were just excited to see me 
2
GrammAcc
I think this is good evidence to support your argument that ternaries should be avoided. It’s deceptively complex to make bulletproof.
I work in JS for my dayjob, and ternaries are everywhere cause everything can be null or undefined at any point in the program even if we try to be thorough with parsing and validation. Some library will return Optional<T> at some point and we’re back to explicitly checking null on every line unless we wrap every dependency (which is generally good practice in imperative code but also has a cost).
I find that ternaries tend to appear more frequently when the code doesn’t have well-defined data structures to pass between abstraction boundaries.
Since Elixir is strongly typed, we can avoid all this pain by focusing on data flow and pattern matching like @thiagomajesk mentioned. It feels like a huge weight has been lifted from my shoulders when I open up an Elixir project after working in JS all week. lol
I’ve also almost never needed a ternary in Python code since Python is strongly typed and has good support for working with well-defined custom data structures as well.
5
I certainly thought to myself “Hey, 
smathy
Happy to be back. OMG Phoenix 1.8 is amazeballs. Good to see your little pug face again
I wish human slop was up to the challenge, but AI slop is the dominant force in that battle.
1
sorentwo
Oban Core Team
This is a ludicrous position. Any use of if or cond is non-idiomatic? By that measure, every prominent package in the ecosystem and elixir itself aren’t idiomatic.
I personally strive for fewer branches, flat control flows, and avoid nested conditionals. There is still logical branching involved. Pushing all logic branches into functions, or pattern matches, doesn’t necessarily make your code clearer.
3
mudasobwa
Creator of Cure
I could not agree more. Although I never proposed that. What I meant, is logical branching is (usually, not always, and I stated this clearly in the quote you cited) a result of a bad design.
I love how Joe Armstrong reasoned about Erlang was just modelling the real world around us, and I strive to keep aligned with this approach. Ask yourself how often you take a decision in a form of a strict conditional operator?
Offtopic: I just recalled the oldie but goldie. A wife asks a developer to go to groshery and says, “Take a milk and if there are eggs, take a dozen.” In an hour the developer comes back with a dozen of milk cartons.
So yeah, we rarely do something like “if there is a summer, I go swimming, otherwise I go skying.” Just think about that.
1
smathy
How do we NOT do this all the time? If I can get a good deal, I’ll buy the fancier thing, else I’ll buy the regular one. If I finish mowing the lawn in time, I’ll spend some time playing with the dog before my next commitment. If I have some steak in the freezer, then I’ll have steak for dinner, else chicken.
I can’t see how your position can be interpreted to make it make sense? How is life not completely full of an either-or decisions based on conditions?
0