> why spend time to read 10 lines and figure out that it actually does what a simple ternary operation would accomplish??

Because when something is expressed in 10 lines explicitly, generally you can simply skim over the code to get an idea of what's going on without having to go into the details.

"Smart and clever" code, like using nested ternaries, demands you to focus and try to figure out what is going on.

> Because when something is expressed in 10 lines explicitly, generally you can simply skim over the code to get an idea of what's going on without having to go into the details.

Which is why important details get missed when reviewing verbose code.

These are both extremes and both bad. The 10 line switch statement to switch a variable is a high cognitive load for no good reason but so is a nested ternary under pretty much any circumstances, but especially with single character variables and magic numbers.

>On that same vein, if a ternary operation is going to throw someone for a loop, I've got some bad news about their career in programming.

You're right about someone having and issue if they can't understand this on it's own. What was the last application you worked in where that single line is all you had to understand to accomplish whatever task you were working on?

> What was the last application you worked in where that single line is all you had to understand to accomplish whatever task you were working on?

Exactly.

The bigger constructs expressed in functions, classes, etc, are where the attention should really be.

The smaller ideas expressed in single lines of code are, should be, insignificant in terms of cognitive load.

There are some exceptions to this, in particular very high performant code. We all know that "premature optimization...".

The bigger constructs are made out of these smaller pieces. Focusing on just the high level abstractions will end up with your application being difficult to fix when something lower level breaks and focusing on just the lower level code will cause your application to end up unscaleable or refactorable because of poor design.

It's a question of trade offs but you cant entirely ignore one or the other

This is what good function names and default code folding is for...

Because if the structure is different from what you're 'used' to, you spend ten times as much time reading (or as the original presentation coins, "decoding") that one line to understand what it means.

You don't read ten lines, you decode them. If it's ten simple lines, decoding them is easy. If it's a nested ternary, it's a lot more cognitive load - unless you're used to nested ternary expressions.

However, I'd say it's a fair assertion to make that most people aren't used to reading nested ternaries.

And I think that's what Go (and this presentation) is about; you shouldn't need to get used to a certain code style to be able to decode it. You should be able to open up a file and not be surprised. If I were to come across a nested ternary, my first reaction is a raised eyebrow and a "wtf?". The wtfs / hour is one of the metrics that Go language is based on.