On Tue, Aug 14, 2018 at 6:43 PM Mark Volkmann <r.mark.volkm...@gmail.com>
wrote:
> I’m new to Go and I imagine the idea of adding a ternary operator to Go
> has been discussed many times. Rather than repeat that, can someone point
> me to a discussion about why Go doesn’t add this? I’m struggling to
> understand why it is desirable to write code like this:
>
> var color
> if temperature > 100 {
> color = “red”
> } else {
> color = “blue”
> }
>
> Instead of this:
>
> var color = temperature > 100 ? “red” : “blue”
>
>
I think the idea is that of a trade-off. Most people desire more expressive
power, and it isn't a dismissal of the idea at all. However, it is
important to note what you gain by trading off such an expression level
construction, rather than just looking at what kind of demise it brings to
programs. Leaving features out of a language can have a benefit as well
because it allows you to explore different design paths.
The main benefit is that there are simpler semantics of expressions, since
there is no selection operator in expressions. This avoids "clever
programmers" who write incomprehensible code structure, hurting any
newcomer to that part of the code base. You may argue that people shouldn't
write bad code like this, but there is a definite basis in Go for keeping
the language simple: it doesn't provide a whole lot of abstraction features
in general.
The secondary benefit is that it limits boolean switches to just the
statement syntactical group. This is somewhat aligned with the notion that
the operators ++ and -- are at the statement level as well. Thus, to make
control-flow decisions, one must use statements, and never expressions.
This alters program design because it is entirely different code which
flows "naturally" when writing.
So long story short: it isn't at all desirable to write code like that. But
on the other hand, it isn't desirable to have a language which is harder to
read, or harder to teach either. Adding ternary operators could be
considered---after all the cognitive load of them isn't that high---but it
was ultimately decided against.
A good approach here would be to look at languages which have that
operator, index all the code in them and start looking at metrics:
* How often is the operator used?
* Given N experienced programmers, can they easily read the semantics for
typical examples?
* Given N inexperienced programmers, does the same hold?
* Are there any situations in common use where the ternary operator adds
expressive power so the alternative is ugly or hard to follow?
Running proper double-blind experiments on reading comprehension for
programs is not something we've done a lot of. Sadly.
If you desire expression level operators to the point where you cannot live
without them, you might enjoy functional languages. One of their defining
features are that everything is an expression, and they don't distinguish
between the statement and expression modality in syntax (which also removes
them from the Algol base of languages). Hence, there are only "ternary"
operators, by design.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
