[derekp7]

Because sometimes the clever code may be easier to understand by an experienced developer even if it is less accessible to a less experienced developer. Non-coding example: "Two plus Three times Five" is easy to understand, because you don't need to know math symbols. But to anyone who knows math, "2 + 3 * 5" is easier/quicker to read.

For a coding example, in Javascript you have things like arrow functions that make the code more concise. But that is also harder to read for someone who hasn't picked up on them yet (which may have been the case when they were first introduced).

[tejtm]

It is ambiguous,

"Two plus Three times Five" as a sentence reads and is naturally processed from left to right for a result of " is twenty-five".

But to anyone who knows math (precedence), "2 + 3 * 5 = 17"

[ghaff]

Yeah. That's a trivial case but I'd still probably use parentheses). For more complex precedence operations I definitely would.

[jaywalk]

The order of operations doesn't change because the equation is written out in English versus mathematical notation.

[perl4ever]

"There is no ambiguity because my context is the only context"

I learned a few years back that lawyers will give you a bunch of "ands" and "ors" in an expression without any concept of precedence. That doesn't necessarily mean left to right works, either.

[foobar2021]

How do you say and/or spell out parentheses?

[elzbardico]

Easy: Take two plus five and multiply it by six

[lamontcg]

That's watered down and overly simplified.

We can have an argument over ternary operators and new users and I'm going to argue that they're part of the common vernacular of computer science and everyone needs to sit down and learn them.

But nested ternaries three levels deep are horrendous. Stick with one level and simple expressions and keep it readable (assuming the background of just understanding the operator). Don't overuse it.

Similarly lambda functions are part of the vernacular, everyone is going to need to learn that necessary amount of complexity. But at some point nested lambda functions containing lambda functions are going to get difficult to read and reason about.

[lamplovin]

I agree with you on language syntax choices, but as far as the articles examples are concerned it seemed like the "clever" solutions to them were more about OO architecture choices via abstraction for example. In which case, if it's not a codebase that you have experience in, then those architecture choices can get very confusing if not properly documented