Re: [go-nuts] Re: Ternary ... again
Normally the FooBar is full of other fields, necessitating the single field
patch.
On Sat, Aug 18, 2018, 1:17 PM Tim Peoples wrote:
> Regarding your issues with the following...
>
>
>> I've lost count of the times I've had to change:
>>
>> return FooBar{
>> Field: blah,
>> }
>>
>> To:
>>
>> var foo FooBar
>> if someCond {
>> foo.Field = blah
>> } else {
>> foo.Field = bar
>> }
>> return foo
>>
>
> ...I hardly consider that to be idiomatic Go. A more go-like approach
> would be to follow the guideline to "return early" and write it more like
> this:
>
> if someCond {
> return FooBar{Field: blah}
> }
>
> return FooBar{Field: bar}
>
>
> ...which (IMHO) is markedly more readable than a ternary expression.
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/MrpkS4epn_E/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
--
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.
Re: [go-nuts] Re: Ternary ... again
Regarding your issues with the following...
> I've lost count of the times I've had to change:
>
> return FooBar{
> Field: blah,
> }
>
> To:
>
> var foo FooBar
> if someCond {
> foo.Field = blah
> } else {
> foo.Field = bar
> }
> return foo
>
...I hardly consider that to be idiomatic Go. A more go-like approach
would be to follow the guideline to "return early" and write it more like
this:
if someCond {
return FooBar{Field: blah}
}
return FooBar{Field: bar}
...which (IMHO) is markedly more readable than a ternary expression.
--
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.
Re: [go-nuts] Re: Ternary ... again
On Friday, August 17, 2018 at 5:56:05 PM UTC+8, Liam wrote:
>
> People have a wide range of perceptive and cognitive abilities. People
> also have difficulty imagining the very different abilities that others
> possess.
>
>
I find constant vertical scanning and scrolling to be distracting and thus
> inefficient. So I won't use a tool that adds line breaks to my code, and
> I'd benefit from a one-line switch.
>
> My apology for shoving everyone into drinking tea hardly, forgotten to
realize there are coffee lovers in the room too.
This is a good compromise, less cryptic than ?:
>
> v = if t a; else b // else can be on next line
> v = if (t) a; else b // parens isolate the test if required
>
> I'm willing to compromise only as far as this pattern, standing on tea
sides for coffee folks:
v = b ; if (t) { v = a }
v = b ; if (t) { a }
v = b ; if t { a }
v = b ; if t { v = a }
Here are the tests, based on comparing the readability, between the pattern
vs. the Ternary:
// Oneline
v := "blue"; if data == nil { v = "red" }
v := data == nil ? "red" : "blue"
v := (data == nil) ? "red" : "blue"
// multiple lines
status:= "blue"; if data == nil { status = "red" }
latitude := device.gps("lat"); if data == nil { latitude := "000.0" }
longitude := device.gps("long"); if data == nil { latitude := "000.0" }
status:= data == nil ? "blue" : "red"
latitude := data == nil ? device.gps("lat") : "000.0"
longitude := data == nil ? device.gps("long") : "000.0"
// nested conditions oneline
v := "blue"; if (data == nil && (device == nil || wifi == nil)) { v = "red"
}
v := data == (data == nil && (device == nil || wifi == nil)) ? "red" :
"blue"
// nested conditions multiple lines
status:= "blue"; if (data == nil && (bluetooth == nil ||
wifi == nil)) { status = "red" }
latitude := device.gps("lat"); if (data == nil || accuracy < 30) {
latitude := "000.0" }
longitude := device.gps("long"); if (data == nil || accuracy < 30) {
latitude := "000.0" }
status:= (data == nil && (bluetooth == nil || wifi == nil) ? "blue" :
"red"
latitude := (data == nil || device.gps.accuracy() < 30) ? device.gps(
"lat") : "000.0"
longitude := (data == nil || device.gps.accuracy() < 30) ? device.gps(
"long") : "000.0"
Rationale:
1. Maintain clarity between control path and data path.
As I said earlier, I still see it is a costly feature vs vertical only
source codes. I just can't see the value pursuing such direction. There
must be a strong solid reason the developers who developed go did not
implement such feature at the first place. Will I use it? No. If the core
developers agreed to pursue, I can't object either but I do my part raising
my past experience with that scary magical "?".
> Note that go fmt allows this clumsy construct
>
> if err = pkg.ActionItem(); err != nil { // which op is tested?
>return err
> }
>
> While exploding this clear one
>
> err = pkg.ActionItem()
> if err != nil { return err }
>
>
because this is clearer?
err := pkg.ActionItem()
if err != nil {
return err
}
As far as I understand, to simplify, the above, line can be re-written to:
if err = pkg.ActionItem(); err != nil {
return err
}
Which is a clear 2 lines statement, error checking only. Anyway, I use the
former. Again, I'm a tea folk. It's not a rule.
--
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.
Re: [go-nuts] Re: Ternary ... again
People have a wide range of perceptive and cognitive abilities. People also
have difficulty imagining the very different abilities that others possess.
I find constant vertical scanning and scrolling to be distracting and thus
inefficient. So I won't use a tool that adds line breaks to my code, and
I'd benefit from a one-line switch.
This is a good compromise, less cryptic than ?:
v = if t a; else b // else can be on next line
v = if (t) a; else b // parens isolate the test if required
And maybe that implies
v = switch t; case 1 a; case 2 b
Note that go fmt allows this clumsy construct
if err = pkg.ActionItem(); err != nil { // which op is tested?
return err
}
While exploding this clear one
err = pkg.ActionItem()
if err != nil { return err }
On Thu, Aug 16, 2018, 9:08 PM 'Kean Ho Chew' via golang-nuts <
golang-nuts@googlegroups.com> wrote:
> On Friday, August 17, 2018 at 8:53:15 AM UTC+8, Liam wrote:
>>
>> I find that one-concept-per-line, yielding more compact functions, is
>> easier to focus on, as it reduces vertical eye scanning and scrolling.
>>
>> A single-line if stmnt and my switch example demonstrate
>> one-concept-per-line.
>>
>> The thing is, what is cost with the current if else expression that worth
> more to introduce another possible complications? Like my previous email
> and other developers had implied, LOC doesn't matter. In the end, the
> compiler knows what to do.
>
> It's okay to do vertical eye scanning (we're doing it anyway while we're
> coding/reviewing). When ternary logic is abused, we need to do vertical +
> horizontal scrolling.
>
--
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.
Re: [go-nuts] Re: Ternary ... again
Ah, very nice! Tho I can't tell from scanning the readme which features are
different than go fmt.
On Fri, Aug 17, 2018, 1:17 AM Matthias B. wrote:
> On Thu, 16 Aug 2018 16:54:35 -0700
> Liam Breck wrote:
>
> > Indeed, the problem is largely go fmt, I already raised this, but no
> > one picked up on it:
> >
> > I use this one-liner:
> >
> > v := a; if t { v = b }
> >
> > This is not compatible with go fmt, but that tool's effects are
> > undocumented (see issue 18790
> > which was declined), and
> > it has no switches to disable/enable features.
>
> Now THAT is something I can help you with:
>
> https://github.com/mbenkmann/goformat
>
> has the option "inlineblocks=keep" which should give you what you want.
> And if it doesn't, you're welcome to contribute more switches.
>
> MSB
>
--
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.
Re: [go-nuts] Re: Ternary ... again
On Thu, 16 Aug 2018 16:54:35 -0700
Liam Breck wrote:
> Indeed, the problem is largely go fmt, I already raised this, but no
> one picked up on it:
>
> I use this one-liner:
>
> v := a; if t { v = b }
>
> This is not compatible with go fmt, but that tool's effects are
> undocumented (see issue 18790
> which was declined), and
> it has no switches to disable/enable features.
Now THAT is something I can help you with:
https://github.com/mbenkmann/goformat
has the option "inlineblocks=keep" which should give you what you want.
And if it doesn't, you're welcome to contribute more switches.
MSB
--
Brains are the thing most fairly distributed on this world
because everyone thinks he's got more than anyone else.
--
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.
[go-nuts] Re: Ternary ... again
I disagree with the argument that a simple ternary could become unwieldy as a reason not to introduce it to a language. People should be trusted (just as they are now with other constructs) to use a more suitable construct or to refactor when a given one fails to scale. The fact that the Guilded Rose kata can be written with all it's nasty if/else nesting in Go, means regardless of whether a ternary expression is introduced or not, people will still write bad code. RE the suggestion that a ternary wouldn't scale when new temperatures are required, use a switch. RE the suggestion that Go already has ternary operators (with an example using `map`), this is far less readable than the ternary operator in most other languages and way less efficient. RE the suggestion that a default case followed by an if statement can be used instead, I think that in the case of the ternary, the values are so intrinsically linked, that having a variable set across multiple lines is less readable. -- 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.
Re: [go-nuts] Re: Ternary ... again
On Friday, August 17, 2018 at 8:53:15 AM UTC+8, Liam wrote:
>
> I find that one-concept-per-line, yielding more compact functions, is
> easier to focus on, as it reduces vertical eye scanning and scrolling.
>
> A single-line if stmnt and my switch example demonstrate
> one-concept-per-line.
>
> The thing is, what is cost with the current if else expression that worth
more to introduce another possible complications? Like my previous email
and other developers had implied, LOC doesn't matter. In the end, the
compiler knows what to do.
It's okay to do vertical eye scanning (we're doing it anyway while we're
coding/reviewing). When ternary logic is abused, we need to do vertical +
horizontal scrolling. Let's fuzzy-logic the proposal:
Scenario:
1. We use the temperature and color to build a display.
2. We roll in updates (yellow & orange) in 2 years time.
3, We measure the number of possible steps with +1 and sum them up to
weight its cost. Any sub-possible actions (e.g. number of replies in a
forums) are ignored.
CASE I - Ternary
---
1. On first build: (+1)
*color := temperature > 100 ? "red" : "blue"*
2. Implement Upgrades with yellow & orange, assigned to fresh developer:
2.1 search for the code (+1)
2.2 no idea what is ternary operator, google and learn (+1)
2.3 realize how it works, upgrade it with: (+1)
* color := temperature > 100 ? "red" : (temperature > 75 ? "yellow" :
(temperature > 50 ? "orange" : "blue") )*
2.4 submit to upstream. Got rejected by reviewer and request to change into
using if else and/or switch cases. (+1)
2.5 if the developer went frustrated because 2.4 wasted his/her hours of
research: raise a forum and go SPARTA (+1)
2.6 consensus achieved, implement: (+1)
* color := "blue" *
* if temperature > 100 {*
* color = "red"*
* } else if temperature > 75 {*
* color = "yellow"*
* } else if temperature > 50 {*
* color = "orange"*
* }*
2.7) Submit for review. (+1)
2.8) Reviewed and accepted (+1)
Total weight: +9
Total weight if the developer is not short-fused: +8
--
CASE II - Using if else statement
1. On first build: (+1)
* color := "blue" *
* if temperature > 100 {*
* color = "red"*
* }*
2. Implement upgrades with yellow & orange, assigned to fresh developer:
2.1 search for the code (+1)
2.2 Understood it is a nested if else statement. Add yellow and orange
conditions: (+1)
* color := "blue" *
* if temperature > 100 {*
* color = "red"*
* } else if temperature > 75 {*
* color = "yellow"*
* } else if temperature > 50 {*
* color = "orange"*
* }*
2.3 Submit to upstream for review. (+1)
2.4 Accepted. (+1)
Total weight: +5
--
Compare both processes:
CASE I (Ternary) - cost [8-9) points, possible forum discussion
CASE II (If Else) - cost [5] points
If we use time as the currency and learning curve as a metric, Case II is
cheaper than Case I since it is a fixed cost (notice the bracket). This
also means it's easier to transfer project from one person to another
(because it not hard to learn).
Also, new comer is not necessary referring to new developer. It can also
means season developer taking over a project he/she not familiar with. It
can also means maintainer trying to learn a new patch as well.
My point is, wouldn't it be expensive to implement ternary just for the
sake of saving a few lines of codes, which doesn't carry out any
significant computational performances?
-- BETWEEN --
temperature > 100 ? "red" : "blue"
-- VS ---
color := "blue"
if temperature > 100 {
color = "red"
}
---
I find the latter is easier to understand because it uses standard coding
comprehension and without needing to research with google; which is a hell
for new comer since trying to search "?" towards "ternary operations"
without bugging a senior for the first time is scary googling experience.
p/s: I'm sorry if I'm harsh but I must be straight about protecting the
simplicity of this language that I greatly fell in love with after dealing
magics and horrors across Ruby, Python, C, C++, POSIX, etc. Go is
beautifully crafted from learning to development; to process, and to
release and distribution management standpoints. It's simple to understand,
to learn, and to use.
go fmt aspires to produce an odd sort of poetry, which I find inefficient.
> It's especially bad in GitHub commits.
>
> Go fmt standardizes code and facilitate self-learning, so that the new
comer doesn't need to wonder around asking basic questions about
formatting, how to write this and that etc. This encourages them to talks
more about "problem", "algorithm" or "solution" to solve a problem, not
mingling with the language itself in the conversation with the seasoned
veterans. It is odd because it is the first language that provides such
tool to scrutinize codes for free, out of the box.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving email
Re: [go-nuts] Re: Ternary ... again
Yep, the problem is due largely to gofmt. Ternary operator is easily
misused and hard to read if it is nested. That's why i prefer if
expression(without needing to add a new operator and even if it was deep
nested in the worst case, its complexity would equal a deep nested if
statement,its readability would no worse than if statement).
在 2018年8月17日星期五 UTC+8上午6:30:41，Matthias B.写道：
>
> On Wed, 15 Aug 2018 07:46:51 -0700 (PDT)
> Hoo Luu > wrote:
>
> > 在 2018年8月15日星期三 UTC+8上午12:43:37，Mark Volkmann写道:
> >
> > > var color = temperature > 100 ? “red” : “blue”
> >
> >
> > Although this feature will not be accepted, we could just talk about
> > it. I prefer 'if-expression' to ternary.
> >
> > var color = if temperature > 100 { "red" } else { "blue" }
> >
> > vs. current if statement syntax:
> >
> > var color
> > if temperature > 100 {
> > color = "red"
> > } else {
> > color = "blue"
> > }
> >
>
> I get the impression that the real issue here is that gofmt will break
>
> if temperature > 100 { color = "red" } else { color = "blue" }
>
> over multiple lines and that what the people asking for a ternary
> operator really want is a one-liner. So ask yourselves, if gofmt were
> to format your ternary operator (or the above suggested if-expression)
> identical to the if statement, i.e. across the same number of lines,
> would you still want it?
>
> var color =
> if temperature > 100 {
> "red"
> } else {
> "blue"
> }
>
>
> var color =
> temperature > 100 ?
> "red"
> :
> "blue"
>
>
> If you would NOT use these, your real issue is with gofmt, not the Go
> language.
>
>
> MSB
>
> --
> To understand recursion you must first understand recursion.
>
>
--
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.
Re: [go-nuts] Re: Ternary ... again
I find that one-concept-per-line, yielding more compact functions, is
easier to focus on, as it reduces vertical eye scanning and scrolling.
A single-line if stmnt and my switch example demonstrate
one-concept-per-line.
go fmt aspires to produce an odd sort of poetry, which I find inefficient.
It's especially bad in GitHub commits.
Providing a small menu of recommended project-wide formats, and allowing
maintainers to tailor one for their needs would be most helpful. As is, I
eschew it.
On Thu, Aug 16, 2018, 5:18 PM Christopher Nielsen
wrote:
> How is a ternary more readable? I've found that they make code more
> complex and unreadable, in both C and the proposed go, and the one-liner
> you provide is equally or more unreadable than the more verbose if
> statement.
>
> On Thu, Aug 16, 2018, 16:55 Liam Breck wrote:
>
>> Indeed, the problem is largely go fmt, I already raised this, but no one
>> picked up on it:
>>
>> I use this one-liner:
>>
>> v := a; if t { v = b }
>>
>> This is not compatible with go fmt, but that tool's effects are
>> undocumented (see issue 18790
>> which
>> was declined), and it has no switches to disable/enable features. A
>> syntax-aware sed is a good idea, but sadly go fmt destroys useful
>> constructs. Other examples:
>>
>> err := fn()
>> if err != nil { return err }
>>
>> switch v {
>> case 1: pkg.one()
>> case 2: pkg.two()
>> case 3: pkg.thrice()
>> }
>>
>> On Thu, Aug 16, 2018, 3:30 PM Matthias B. wrote:
>>
>>> On Wed, 15 Aug 2018 07:46:51 -0700 (PDT)
>>> Hoo Luu wrote:
>>>
>>> > 在 2018年8月15日星期三 UTC+8上午12:43:37，Mark Volkmann写道:
>>> >
>>> > > var color = temperature > 100 ? “red” : “blue”
>>> >
>>> >
>>> > Although this feature will not be accepted, we could just talk about
>>> > it. I prefer 'if-expression' to ternary.
>>> >
>>> > var color = if temperature > 100 { "red" } else { "blue" }
>>> >
>>> > vs. current if statement syntax:
>>> >
>>> > var color
>>> > if temperature > 100 {
>>> > color = "red"
>>> > } else {
>>> > color = "blue"
>>> > }
>>> >
>>>
>>> I get the impression that the real issue here is that gofmt will break
>>>
>>> if temperature > 100 { color = "red" } else { color = "blue" }
>>>
>>> over multiple lines and that what the people asking for a ternary
>>> operator really want is a one-liner. So ask yourselves, if gofmt were
>>> to format your ternary operator (or the above suggested if-expression)
>>> identical to the if statement, i.e. across the same number of lines,
>>> would you still want it?
>>>
>>> var color =
>>> if temperature > 100 {
>>> "red"
>>> } else {
>>> "blue"
>>> }
>>>
>>>
>>> var color =
>>> temperature > 100 ?
>>> "red"
>>> :
>>> "blue"
>>>
>>>
>>> If you would NOT use these, your real issue is with gofmt, not the Go
>>> language.
>>>
>>>
>>> MSB
>>>
>>>
>>> --
>> 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.
>>
>
--
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.
Re: [go-nuts] Re: Ternary ... again
How is a ternary more readable? I've found that they make code more complex
and unreadable, in both C and the proposed go, and the one-liner you
provide is equally or more unreadable than the more verbose if statement.
On Thu, Aug 16, 2018, 16:55 Liam Breck wrote:
> Indeed, the problem is largely go fmt, I already raised this, but no one
> picked up on it:
>
> I use this one-liner:
>
> v := a; if t { v = b }
>
> This is not compatible with go fmt, but that tool's effects are
> undocumented (see issue 18790
> which
> was declined), and it has no switches to disable/enable features. A
> syntax-aware sed is a good idea, but sadly go fmt destroys useful
> constructs. Other examples:
>
> err := fn()
> if err != nil { return err }
>
> switch v {
> case 1: pkg.one()
> case 2: pkg.two()
> case 3: pkg.thrice()
> }
>
> On Thu, Aug 16, 2018, 3:30 PM Matthias B. wrote:
>
>> On Wed, 15 Aug 2018 07:46:51 -0700 (PDT)
>> Hoo Luu wrote:
>>
>> > 在 2018年8月15日星期三 UTC+8上午12:43:37，Mark Volkmann写道:
>> >
>> > > var color = temperature > 100 ? “red” : “blue”
>> >
>> >
>> > Although this feature will not be accepted, we could just talk about
>> > it. I prefer 'if-expression' to ternary.
>> >
>> > var color = if temperature > 100 { "red" } else { "blue" }
>> >
>> > vs. current if statement syntax:
>> >
>> > var color
>> > if temperature > 100 {
>> > color = "red"
>> > } else {
>> > color = "blue"
>> > }
>> >
>>
>> I get the impression that the real issue here is that gofmt will break
>>
>> if temperature > 100 { color = "red" } else { color = "blue" }
>>
>> over multiple lines and that what the people asking for a ternary
>> operator really want is a one-liner. So ask yourselves, if gofmt were
>> to format your ternary operator (or the above suggested if-expression)
>> identical to the if statement, i.e. across the same number of lines,
>> would you still want it?
>>
>> var color =
>> if temperature > 100 {
>> "red"
>> } else {
>> "blue"
>> }
>>
>>
>> var color =
>> temperature > 100 ?
>> "red"
>> :
>> "blue"
>>
>>
>> If you would NOT use these, your real issue is with gofmt, not the Go
>> language.
>>
>>
>> MSB
>>
>>
>> --
> 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.
>
--
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.
Re: [go-nuts] Re: Ternary ... again
Indeed, the problem is largely go fmt, I already raised this, but no one
picked up on it:
I use this one-liner:
v := a; if t { v = b }
This is not compatible with go fmt, but that tool's effects are
undocumented (see issue 18790 which
was declined), and it has no switches to disable/enable features. A
syntax-aware sed is a good idea, but sadly go fmt destroys useful
constructs. Other examples:
err := fn()
if err != nil { return err }
switch v {
case 1: pkg.one()
case 2: pkg.two()
case 3: pkg.thrice()
}
On Thu, Aug 16, 2018, 3:30 PM Matthias B. wrote:
> On Wed, 15 Aug 2018 07:46:51 -0700 (PDT)
> Hoo Luu wrote:
>
> > 在 2018年8月15日星期三 UTC+8上午12:43:37，Mark Volkmann写道:
> >
> > > var color = temperature > 100 ? “red” : “blue”
> >
> >
> > Although this feature will not be accepted, we could just talk about
> > it. I prefer 'if-expression' to ternary.
> >
> > var color = if temperature > 100 { "red" } else { "blue" }
> >
> > vs. current if statement syntax:
> >
> > var color
> > if temperature > 100 {
> > color = "red"
> > } else {
> > color = "blue"
> > }
> >
>
> I get the impression that the real issue here is that gofmt will break
>
> if temperature > 100 { color = "red" } else { color = "blue" }
>
> over multiple lines and that what the people asking for a ternary
> operator really want is a one-liner. So ask yourselves, if gofmt were
> to format your ternary operator (or the above suggested if-expression)
> identical to the if statement, i.e. across the same number of lines,
> would you still want it?
>
> var color =
> if temperature > 100 {
> "red"
> } else {
> "blue"
> }
>
>
> var color =
> temperature > 100 ?
> "red"
> :
> "blue"
>
>
> If you would NOT use these, your real issue is with gofmt, not the Go
> language.
>
>
> MSB
>
>
>
--
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.
Re: [go-nuts] Re: Ternary ... again
On Wed, 15 Aug 2018 07:46:51 -0700 (PDT)
Hoo Luu wrote:
> 在 2018年8月15日星期三 UTC+8上午12:43:37，Mark Volkmann写道:
>
> > var color = temperature > 100 ? “red” : “blue”
>
>
> Although this feature will not be accepted, we could just talk about
> it. I prefer 'if-expression' to ternary.
>
> var color = if temperature > 100 { "red" } else { "blue" }
>
> vs. current if statement syntax:
>
> var color
> if temperature > 100 {
> color = "red"
> } else {
> color = "blue"
> }
>
I get the impression that the real issue here is that gofmt will break
if temperature > 100 { color = "red" } else { color = "blue" }
over multiple lines and that what the people asking for a ternary
operator really want is a one-liner. So ask yourselves, if gofmt were
to format your ternary operator (or the above suggested if-expression)
identical to the if statement, i.e. across the same number of lines,
would you still want it?
var color =
if temperature > 100 {
"red"
} else {
"blue"
}
var color =
temperature > 100 ?
"red"
:
"blue"
If you would NOT use these, your real issue is with gofmt, not the Go
language.
MSB
--
To understand recursion you must first understand recursion.
--
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.
[go-nuts] Re: Ternary ... again
color := colorFor(temperature)
func colorFor(temperature int) string {
if temperature > 100 {
return "red"
}
return "blue"
}
On Thursday, 16 August 2018 18:01:20 UTC+2, Haddock wrote:
>
>
> var color
>> if temperature > 100 {
>> color = “red”
>> } else {
>> color = “blue”
>> }
>>
>
> IMHO, it could be argued about whether adding something like this would be
> useful:
>
> color := if temperature > 100 {
> return “red”
> } else {
> return “blue”
> }
>
--
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.
[go-nuts] Re: Ternary ... again
If you think this discussion is taking a lot of time have a look at the same discussion for Kotlin in their user group: https://discuss.kotlinlang.org/t/ternary-operator/2116/95 -- 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.
[go-nuts] Re: Ternary ... again
> var color
> if temperature > 100 {
> color = “red”
> } else {
> color = “blue”
> }
>
IMHO, it could be argued about whether adding something like this would be
useful:
color := if temperature > 100 {
return “red”
} else {
return “blue”
}
--
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.
Re: [go-nuts] Re: Ternary ... again
On Thursday, August 16, 2018 at 11:59:00 AM UTC+3, Axel Wagner wrote:
>
> func either(c bool, a, b func() string) string {
> if c {
> return a()
> }
> return b()
> }
>
> func thunk(s string) func() string {
> return func() string { return s }
> }
>
> fmt.Printf("color is %s", either(temperature > 100, thunk("red"),
> thunk("blue"))
>
> ;)
>
I know you are trolling and don't actually write such code, but for those
who don't notice: if thunk() had side-effects, you would be in trouble.
--
Giulio
--
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.
Re: [go-nuts] Re: Ternary ... again
func either(c bool, a, b func() string) string {
if c {
return a()
}
return b()
}
func thunk(s string) func() string {
return func() string { return s }
}
fmt.Printf("color is %s", either(temperature > 100, thunk("red"),
thunk("blue"))
;)
On Thu, Aug 16, 2018 at 10:53 AM roger peppe wrote:
> In my experience, this is rarely a real pain, and where it is, a
> simple function can help out.
>
> func either(condition bool, a, b string) string {
> if condition {
> return a
> }
> return b
> }
>
> fmt.Printf("color is %s", either(temperature>100, "red", "blue"))
>
> The runtime cost for simple cases is exactly the same as if it had
> been built into the language. (If you wish to rely on the lazy
> evaluation of the values with respect to the condition, I suspect that
> an if statement would be more appropriate anyway.
>
> On 16 August 2018 at 09:11, 'Axel Wagner' via golang-nuts
> wrote:
> > Hi Sam. A couple small responses inline.
> >
> > On Thu, Aug 16, 2018 at 8:13 AM Sam Vilain wrote:
> >>
> >> To me the biggest reason to want a ternary operator is to make it easier
> >> on the reader of the code. If there's anything that go and python have
> in
> >> common, it's that both languages are designed to be easy to read (though
> >> with notable differences in emphasis about what makes it easy), and also
> >> relatively easy to tell whether code is correct.
> >
> >
> > I am not particularly familiar with the design process of Python. But
> > judging from the result, I find that very hard to believe, TBQH. I find
> both
> > of these things - reading Python and telling whether Python code is
> correct
> > - to be very hard things to do. ISTM that if two processes claim to
> optimize
> > for the same thing but achieve such different results, then either they
> > weren't optimizing for the same thing, or one of the two failed. I'm
> > uncomfortable claiming the latter, so I'd personally argue the former:
> That
> > it may be worth considering that we should use different words for what
> > Python aims for and what Go aims for (not that I have good suggestions).
> >
> >> With a ternary, it's very clear that after the statement, the assignment
> >> has occurred.
> >>
> >> result = test ? "a" : "b"
> >>
> >> With an `if' statement, you have to read a bit more:
> >>
> >> var result string
> >> if test {
> >> result = "a"
> >> } else {
> >> result = "b"
> >> }
> >>
> >> In most cases the analysis is very simple to tell that both code
> branches
> >> assign to `result'. But there's a problem with this. This is only
> easy to
> >> see if someone doesn't then come along and insert extra code into those
> nice
> >> welcoming code blocks:
> >>
> >> var result string
> >> if test {
> >> result = "a"
> >> // insert code here
> >> funcCall()
> >> } else {
> >> // insert other code here
> >> funcCall2()
> >> result = "b"
> >> }
> >>
> >> As a result, as the code is modified, the condition that 'result has a
> >> value' is not held and you end up with the zero value instead of
> something
> >> you expected.
> >
> >
> > I don't understand what you mean. Your code seems fine, what am I
> > overlooking?
> >
> > On a larger point: I don't believe this to be a good argument. I'd argue
> > that if the logic of the latter is what you want, you will get there,
> > ternary expression or not. I'd argue that in practice, if you started
> with a
> > ternary expression, people would just remove that and write the code you
> > ended up with anyway. Because they want that logic and writing that
> > conditional statement is the way to achieve that logic.
> >
> > But I'm not clairvoyant, so who knows what would happen in actual
> practice.
> >
> >>
> >>
> >> Of course it's not as bad as in python or C because there is a separate
> >> `=' and `:=' operator, but as you can see above, this doesn't always
> come
> >> into play. If you're assigning more than just an immediate constant,
> you
> >> probably don't want to start with `:=' and then re-assign based on the
> >> conditional.
> >>
> >> It also gets much more complicated to follow for cases where you might
> >> want to use a nested or chained ternary expression, or a more
> complicated
> >> value construction which has many ternaries within it.
> >>
> >> I've lost count of the times I've had to change:
> >>
> >> return FooBar{
> >> Field: blah,
> >> }
> >>
> >> To:
> >>
> >> var foo FooBar
> >> if someCond {
> >> foo.Field = blah
> >> } else {
> >> foo.Field = bar
> >> }
> >> return foo
> >>
> >> In my experience code is clearer and easier to read if it does *not*
> >> contain re-assignments and branches, and temporary variables used only
> once.
> >> With a ternary operator, you can code like that for cases where it makes
> >> sense. I would much rather write:
> >>
> >> return FooBar{
> >> Field: someCond ? blah : bar,
> >> }
> >>
> >> my 2¢,
> >> Sam
> >>
> >>
> >> On Wed, Aug 15,
Re: [go-nuts] Re: Ternary ... again
In my experience, this is rarely a real pain, and where it is, a
simple function can help out.
func either(condition bool, a, b string) string {
if condition {
return a
}
return b
}
fmt.Printf("color is %s", either(temperature>100, "red", "blue"))
The runtime cost for simple cases is exactly the same as if it had
been built into the language. (If you wish to rely on the lazy
evaluation of the values with respect to the condition, I suspect that
an if statement would be more appropriate anyway.
On 16 August 2018 at 09:11, 'Axel Wagner' via golang-nuts
wrote:
> Hi Sam. A couple small responses inline.
>
> On Thu, Aug 16, 2018 at 8:13 AM Sam Vilain wrote:
>>
>> To me the biggest reason to want a ternary operator is to make it easier
>> on the reader of the code. If there's anything that go and python have in
>> common, it's that both languages are designed to be easy to read (though
>> with notable differences in emphasis about what makes it easy), and also
>> relatively easy to tell whether code is correct.
>
>
> I am not particularly familiar with the design process of Python. But
> judging from the result, I find that very hard to believe, TBQH. I find both
> of these things - reading Python and telling whether Python code is correct
> - to be very hard things to do. ISTM that if two processes claim to optimize
> for the same thing but achieve such different results, then either they
> weren't optimizing for the same thing, or one of the two failed. I'm
> uncomfortable claiming the latter, so I'd personally argue the former: That
> it may be worth considering that we should use different words for what
> Python aims for and what Go aims for (not that I have good suggestions).
>
>> With a ternary, it's very clear that after the statement, the assignment
>> has occurred.
>>
>> result = test ? "a" : "b"
>>
>> With an `if' statement, you have to read a bit more:
>>
>> var result string
>> if test {
>> result = "a"
>> } else {
>> result = "b"
>> }
>>
>> In most cases the analysis is very simple to tell that both code branches
>> assign to `result'. But there's a problem with this. This is only easy to
>> see if someone doesn't then come along and insert extra code into those nice
>> welcoming code blocks:
>>
>> var result string
>> if test {
>> result = "a"
>> // insert code here
>> funcCall()
>> } else {
>> // insert other code here
>> funcCall2()
>> result = "b"
>> }
>>
>> As a result, as the code is modified, the condition that 'result has a
>> value' is not held and you end up with the zero value instead of something
>> you expected.
>
>
> I don't understand what you mean. Your code seems fine, what am I
> overlooking?
>
> On a larger point: I don't believe this to be a good argument. I'd argue
> that if the logic of the latter is what you want, you will get there,
> ternary expression or not. I'd argue that in practice, if you started with a
> ternary expression, people would just remove that and write the code you
> ended up with anyway. Because they want that logic and writing that
> conditional statement is the way to achieve that logic.
>
> But I'm not clairvoyant, so who knows what would happen in actual practice.
>
>>
>>
>> Of course it's not as bad as in python or C because there is a separate
>> `=' and `:=' operator, but as you can see above, this doesn't always come
>> into play. If you're assigning more than just an immediate constant, you
>> probably don't want to start with `:=' and then re-assign based on the
>> conditional.
>>
>> It also gets much more complicated to follow for cases where you might
>> want to use a nested or chained ternary expression, or a more complicated
>> value construction which has many ternaries within it.
>>
>> I've lost count of the times I've had to change:
>>
>> return FooBar{
>> Field: blah,
>> }
>>
>> To:
>>
>> var foo FooBar
>> if someCond {
>> foo.Field = blah
>> } else {
>> foo.Field = bar
>> }
>> return foo
>>
>> In my experience code is clearer and easier to read if it does *not*
>> contain re-assignments and branches, and temporary variables used only once.
>> With a ternary operator, you can code like that for cases where it makes
>> sense. I would much rather write:
>>
>> return FooBar{
>> Field: someCond ? blah : bar,
>> }
>>
>> my 2¢,
>> Sam
>>
>>
>> On Wed, Aug 15, 2018 at 1:13 AM, 'Axel Wagner' via golang-nuts
>> wrote:
>>>
>>> In my opinion Python serves as a poor argument here. I tend to use Python
>>> as a example of a grab-bag language that adds any feature anyone considers
>>> useful - without considering the cost. An Anti-Go, if you will :)
>>> Gustavo Niemeyer actually wrote this up pretty well:
>>> https://blog.labix.org/2012/06/26/less-is-more-and-is-not-always-straightforward
>>>
>>> So, from my perspective, if you tell me "Python did not have ternary
>>> operators, but after long and hard discussions, they caved", what I'm
>>> hearing is "even Pyt
Re: [go-nuts] Re: Ternary ... again
Hi Sam. A couple small responses inline.
On Thu, Aug 16, 2018 at 8:13 AM Sam Vilain wrote:
> To me the biggest reason to want a ternary operator is to make it easier
> on the reader of the code. If there's anything that go and python have in
> common, it's that both languages are designed to be easy to read (though
> with notable differences in emphasis about what makes it easy), and also
> relatively easy to tell whether code is correct.
>
I am not particularly familiar with the design process of Python. But
judging from the result, I find that very hard to believe, TBQH. I find
both of these things - reading Python and telling whether Python code is
correct - to be very hard things to do. ISTM that if two processes claim to
optimize for the same thing but achieve such different results, then either
they weren't optimizing for the same thing, or one of the two failed. I'm
uncomfortable claiming the latter, so I'd personally argue the former: That
it may be worth considering that we should use different words for what
Python aims for and what Go aims for (not that I have good suggestions).
With a ternary, it's very clear that after the statement, the assignment
> has occurred.
>
> result = test ? "a" : "b"
>
> With an `if' statement, you have to read a bit more:
>
> var result string
> if test {
> result = "a"
> } else {
> result = "b"
> }
>
> In most cases the analysis is very simple to tell that both code branches
> assign to `result'. But there's a problem with this. This is only easy to
> see if someone doesn't then come along and insert extra code into those
> nice welcoming code blocks:
>
> var result string
> if test {
> result = "a"
> // insert code here
> funcCall()
> } else {
> // insert other code here
> funcCall2()
> result = "b"
> }
>
> As a result, as the code is modified, the condition that 'result has a
> value' is not held and you end up with the zero value instead of something
> you expected.
>
I don't understand what you mean. Your code seems fine, what am I
overlooking?
On a larger point: I don't believe this to be a good argument. I'd argue
that if the logic of the latter is what you want, you will get there,
ternary expression or not. I'd argue that in practice, if you started with
a ternary expression, people would just remove that and write the code you
ended up with anyway. Because they want that logic and writing that
conditional statement is the way to achieve that logic.
But I'm not clairvoyant, so who knows what would happen in actual practice.
>
> Of course it's not as bad as in python or C because there is a separate
> `=' and `:=' operator, but as you can see above, this doesn't always come
> into play. If you're assigning more than just an immediate constant, you
> probably don't want to start with `:=' and then re-assign based on the
> conditional.
>
> It also gets much more complicated to follow for cases where you might
> want to use a nested or chained ternary expression, or a more complicated
> value construction which has many ternaries within it.
>
> I've lost count of the times I've had to change:
>
> return FooBar{
> Field: blah,
> }
>
> To:
>
> var foo FooBar
> if someCond {
> foo.Field = blah
> } else {
> foo.Field = bar
> }
> return foo
>
> In my experience code is clearer and easier to read if it does *not*
> contain re-assignments and branches, and temporary variables used only
> once. With a ternary operator, you can code like that for cases where it
> makes sense. I would much rather write:
>
> return FooBar{
> Field: someCond ? blah : bar,
> }
>
> my 2¢,
> Sam
>
>
> On Wed, Aug 15, 2018 at 1:13 AM, 'Axel Wagner' via golang-nuts <
> golang-nuts@googlegroups.com> wrote:
>
>> In my opinion Python serves as a poor argument here. I tend to use Python
>> as a example of a grab-bag language that adds any feature anyone considers
>> useful - without considering the cost. An Anti-Go, if you will :)
>> Gustavo Niemeyer actually wrote this up pretty well:
>> https://blog.labix.org/2012/06/26/less-is-more-and-is-not-always-straightforward
>>
>> So, from my perspective, if you tell me "Python did not have ternary
>> operators, but after long and hard discussions, they caved", what I'm
>> hearing is "even *Python* didn't really need them". ;)
>>
>> (Disclaimer: This isn't meant as a dig at Python. I think Python is a
>> great language. But its design goals are very different from Go's)
>>
>> On Wed, Aug 15, 2018 at 8:33 AM Sam Vilain wrote:
>>
>>> I haven't seen all the discussion referenced, but I remember digging
>>> deep into the python language archives where Guido and others eventually
>>> relented and added ternaries (with the syntax "a if val else b"). I can't
>>> remember the argument which swung the consensus but the arguments against
>>> seem remarkably similar.
>>>
>>> Go does have a one-line ternary:
>>>
>>> var result = map[bool]string{false: "a", true: "b"}[test]
>>>
>>> It's less of a hack if you declare the
[go-nuts] Re: Ternary ... again
I long for a ternary which disallows embedded ternaries. I use this
one-liner, but not happily:
v := a; if t { v = b }
This is not compatible with go fmt, but that tool's effects are
undocumented (see issue 18790
which was declined), and it has no switches to disable/enable features. A
syntax-aware sed is a good idea, but sadly go fmt destroys useful
constructs. Other examples:
err := fn()
if err != nil { return err }
switch v {
case 1: pkg.one()
case 2: pkg.two()
case 3: pkg.thrice()
}
On Tuesday, August 14, 2018 at 9:43:37 AM UTC-7, Mark Volkmann 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”
>
> Is the ternary really so confusing that it justifies writing 6 lines of
> code instead of 1? I realize I could eliminate two lines like the
> following, but this isn’t a good idea if the values come from function
> calls since there would sometimes be needless function calls.
>
> var color = “blue”
> if temperature > 100 {
> color = “red”
> }
>
> ---
> R. Mark Volkmann
> Object Computing, Inc.
--
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.
Re: [go-nuts] Re: Ternary ... again
Looking back at the PEP ( https://www.python.org/dev/peps/pep-0308/ ), it
seems that the main argument was that people were working around the lack
of it in ways that led to subtle bugs using 'and' and 'or'. I seem to have
inadvertently demonstrated that it's possible to do this in an obfuscated
(and not 0-alloc) way in go, so in principle this same argument applies
:-). But unless my crazy ternary operator catches on (I assure you, I only
*very* rarely use it in real code), this argument can be considered moot.
To me the biggest reason to want a ternary operator is to make it easier on
the reader of the code. If there's anything that go and python have in
common, it's that both languages are designed to be easy to read (though
with notable differences in emphasis about what makes it easy), and also
relatively easy to tell whether code is correct.
With a ternary, it's very clear that after the statement, the assignment
has occurred.
result = test ? "a" : "b"
With an `if' statement, you have to read a bit more:
var result string
if test {
result = "a"
} else {
result = "b"
}
In most cases the analysis is very simple to tell that both code branches
assign to `result'. But there's a problem with this. This is only easy to
see if someone doesn't then come along and insert extra code into those
nice welcoming code blocks:
var result string
if test {
result = "a"
// insert code here
funcCall()
} else {
// insert other code here
funcCall2()
result = "b"
}
As a result, as the code is modified, the condition that 'result has a
value' is not held and you end up with the zero value instead of something
you expected.
Of course it's not as bad as in python or C because there is a separate `='
and `:=' operator, but as you can see above, this doesn't always come into
play. If you're assigning more than just an immediate constant, you
probably don't want to start with `:=' and then re-assign based on the
conditional.
It also gets much more complicated to follow for cases where you might want
to use a nested or chained ternary expression, or a more complicated value
construction which has many ternaries within it.
I've lost count of the times I've had to change:
return FooBar{
Field: blah,
}
To:
var foo FooBar
if someCond {
foo.Field = blah
} else {
foo.Field = bar
}
return foo
In my experience code is clearer and easier to read if it does *not*
contain re-assignments and branches, and temporary variables used only
once. With a ternary operator, you can code like that for cases where it
makes sense. I would much rather write:
return FooBar{
Field: someCond ? blah : bar,
}
my 2¢,
Sam
On Wed, Aug 15, 2018 at 1:13 AM, 'Axel Wagner' via golang-nuts <
golang-nuts@googlegroups.com> wrote:
> In my opinion Python serves as a poor argument here. I tend to use Python
> as a example of a grab-bag language that adds any feature anyone considers
> useful - without considering the cost. An Anti-Go, if you will :)
> Gustavo Niemeyer actually wrote this up pretty well:
> https://blog.labix.org/2012/06/26/less-is-more-and-
> is-not-always-straightforward
>
> So, from my perspective, if you tell me "Python did not have ternary
> operators, but after long and hard discussions, they caved", what I'm
> hearing is "even *Python* didn't really need them". ;)
>
> (Disclaimer: This isn't meant as a dig at Python. I think Python is a
> great language. But its design goals are very different from Go's)
>
> On Wed, Aug 15, 2018 at 8:33 AM Sam Vilain wrote:
>
>> I haven't seen all the discussion referenced, but I remember digging deep
>> into the python language archives where Guido and others eventually
>> relented and added ternaries (with the syntax "a if val else b"). I can't
>> remember the argument which swung the consensus but the arguments against
>> seem remarkably similar.
>>
>> Go does have a one-line ternary:
>>
>> var result = map[bool]string{false: "a", true: "b"}[test]
>>
>> It's less of a hack if you declare the lookup "table" separately.
>>
>> Sam
>>
>> On Aug 14, 2018 9:52 PM, Agniva De Sarker
>> wrote:
>>
>> Your answer is here - https://tip.golang.org/doc/
>> faq#Does_Go_have_a_ternary_form.
>>
>>
>> On Tuesday, 14 August 2018 22:13:37 UTC+5:30, Mark Volkmann 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”
>>
>> Is the ternary really so confusing that it justifies writing 6 lines of
>> code instead of 1? I realize I could eliminate two lines like the
>> following, but this isn’t a good idea if the values come from function
>> calls since there would someti
Re: [go-nuts] Re: Ternary ... again
Mark,
Some considerations that may be unclear when approaching Go and considering
anything familiar from other languages that is not in Go...
MAKING DECISIONS
Go's designers are experienced. with central roles in UNIX, C, GCC, Modula,
etc., and also across teams of various scales and diversities, from
small-all PhD Bell Labs teams to big more normally distributed background
teams in large companies. They all ended up at Google and saw the "horror"
of programming as usual at huge scale: many hour builds even with 10k CPUs,
long latent bugs despite testing and review regimentation, etc.
The result was a project to design a language and build approach that makes
it hard to abuse, stumble, or fail in precisely the ways that teams
commonly suffer problems. This is a little bit downplayed in the
conversations, but statements like "complex ternary expressions can be
confusing" really mean "we documented 18,327 cases of major bugs caused by
misunderstood nested ternaries." (This would also correspond to "we
documented 9M cases of bugs caused by misunderstood default casts in C++
with generics and overloaded operators." 😃)
These kinds of awarenesses lead to a "defensive programming" mindset about
casting, pointer math, increment as expression rather than operator, and
most everything that can sometimes make the Go team seem arbitrary. What is
not clear in this is that they miss these things too. Ken Thompson had the
idea for the ternary operator. It makes sense to him. His (odd but logical)
way of indenting if clauses and ternaries made it safe for him. But "good
for Turing-award winner Ken" is not the test for professional team
programming at scale. So when you hear these data-driven, career experience
based arguments for/against approaches know that it is not personal, it is
an analytic decision based on data.
The goal of those decisions was to make whole teams more productive, and
millions of Go users seem to bear these ideas out pretty well. You can see
this play out in discussions of "what should be different in Go2?" Not much
seems to be suggested, at least compared to each rev of C++.
MANAGING PAIN
Many new Go users complain about the verbosity of error handling. They feel
pain. It is often stated as "it was easier and prettier when it was magic
because of exceptions." The answer is always "embrace it. it is good for
you to be explicit about possible errors. it gives you a place to do
something smart rather than just fail. it is good for those who read your
code to know what can go wrong. it is good for people who use your code to
know what errors you can possibly have."
This may leave the new user doubtful, but nearly all who give it time come
to see it as good advice. I'm not sure that the deeper point comes across
as clearly as possible: the actual pain is probably not what you think it
is. As a developer, you might think the effort/cost/pain is "how long to
type it and get it to build and pass tests." But in truth, in teams, at
scale, the real pain is 1 people who read your API, 1000 people who
read your code, 100 people who maintain/port/tune/extend it. The time it
takes to type six lines instead of one is pretty small in this view,
especially if it is true that each of these readers-of-code comes to
understand it faster and more correctly. This is the real pain that needs
to be managed. It makes tricky, dense, APL-ish cleverness seem awful and
verbose but simple code rather nice.
Thoughts to consider,
Michael
On Wed, Aug 15, 2018 at 8:06 AM Tamás Gulácsi wrote:
>
>
> 2018. augusztus 15., szerda 16:46:51 UTC+2 időpontban Hoo Luu a következőt
> írta:
>>
>> 在 2018年8月15日星期三 UTC+8上午12:43:37，Mark Volkmann写道:
>>
>>> var color = temperature > 100 ? “red” : “blue”
>>
>>
>> Although this feature will not be accepted, we could just talk about it.
>> I prefer 'if-expression' to ternary.
>>
>> var color = if temperature > 100 { "red" } else { "blue" }
>>
>> vs. current if statement syntax:
>>
>> var color
>> if temperature > 100 {
>> color = "red"
>> } else {
>> color = "blue"
>> }
>>
>
> I prefer with nice clean unmissable "default vs. special"
>
> color := "blue"
> if temperature > 100 {
> color = "red"
> }
>
>
> --
> 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.
>
--
*Michael T. jonesmichael.jo...@gmail.com *
--
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.
[go-nuts] Re: Ternary ... again
2018. augusztus 15., szerda 16:46:51 UTC+2 időpontban Hoo Luu a következőt
írta:
>
> 在 2018年8月15日星期三 UTC+8上午12:43:37，Mark Volkmann写道:
>
>> var color = temperature > 100 ? “red” : “blue”
>
>
> Although this feature will not be accepted, we could just talk about it. I
> prefer 'if-expression' to ternary.
>
> var color = if temperature > 100 { "red" } else { "blue" }
>
> vs. current if statement syntax:
>
> var color
> if temperature > 100 {
> color = "red"
> } else {
> color = "blue"
> }
>
I prefer with nice clean unmissable "default vs. special"
color := "blue"
if temperature > 100 {
color = "red"
}
--
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.
[go-nuts] Re: Ternary ... again
2018. augusztus 15., szerda 16:46:51 UTC+2 időpontban Hoo Luu a következőt
írta:
>
> 在 2018年8月15日星期三 UTC+8上午12:43:37，Mark Volkmann写道:
>
>> var color = temperature > 100 ? “red” : “blue”
>
>
> Although this feature will not be accepted, we could just talk about it. I
> prefer 'if-expression' to ternary.
>
> var color = if temperature > 100 { "red" } else { "blue" }
>
> vs. current if statement syntax:
>
> var color
> if temperature > 100 {
> color = "red"
> } else {
> color = "blue"
> }
>
--
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.
[go-nuts] Re: Ternary ... again
在 2018年8月15日星期三 UTC+8上午12:43:37，Mark Volkmann写道:
> var color = temperature > 100 ? “red” : “blue”
Although this feature will not be accepted, we could just talk about it. I
prefer 'if-expression' to ternary.
var color = if temperature > 100 { "red" } else { "blue" }
vs. current if statement syntax:
var color
if temperature > 100 {
color = "red"
} else {
color = "blue"
}
--
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.
[go-nuts] Re: Ternary ... again
在 2018年8月15日星期三 UTC+8上午12:43:37，Mark Volkmann写道：
>
> var color = temperature > 100 ? “red” : “blue”
>
Although this feature will not be accepted, we could just talk about it. I
prefer 'if-expression' to ternary.
var color = if temperature > 100 { "red" } else { "blue" }
vs. current if statement syntax:
var color
if temperature > 100 {
color = red
} else {
color = blue
}
--
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.
Re: [go-nuts] Re: Ternary ... again
In my opinion Python serves as a poor argument here. I tend to use Python
as a example of a grab-bag language that adds any feature anyone considers
useful - without considering the cost. An Anti-Go, if you will :)
Gustavo Niemeyer actually wrote this up pretty well:
https://blog.labix.org/2012/06/26/less-is-more-and-is-not-always-straightforward
So, from my perspective, if you tell me "Python did not have ternary
operators, but after long and hard discussions, they caved", what I'm
hearing is "even *Python* didn't really need them". ;)
(Disclaimer: This isn't meant as a dig at Python. I think Python is a great
language. But its design goals are very different from Go's)
On Wed, Aug 15, 2018 at 8:33 AM Sam Vilain wrote:
> I haven't seen all the discussion referenced, but I remember digging deep
> into the python language archives where Guido and others eventually
> relented and added ternaries (with the syntax "a if val else b"). I can't
> remember the argument which swung the consensus but the arguments against
> seem remarkably similar.
>
> Go does have a one-line ternary:
>
> var result = map[bool]string{false: "a", true: "b"}[test]
>
> It's less of a hack if you declare the lookup "table" separately.
>
> Sam
>
> On Aug 14, 2018 9:52 PM, Agniva De Sarker
> wrote:
>
> Your answer is here -
> https://tip.golang.org/doc/faq#Does_Go_have_a_ternary_form.
>
>
> On Tuesday, 14 August 2018 22:13:37 UTC+5:30, Mark Volkmann 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”
>
> Is the ternary really so confusing that it justifies writing 6 lines of
> code instead of 1? I realize I could eliminate two lines like the
> following, but this isn’t a good idea if the values come from function
> calls since there would sometimes be needless function calls.
>
> var color = “blue”
> if temperature > 100 {
> color = “red”
> }
>
> ---
> R. Mark Volkmann
> Object Computing, Inc.
>
> --
> 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.
>
>
> --
> 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.
>
--
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.
Re: [go-nuts] Re: Ternary ... again
I haven't seen all the discussion referenced, but I remember digging deep into the python language archives where Guido and others eventually relented and added ternaries (with the syntax "a if val else b"). I can't remember the argument which swung the consensus but the arguments against seem remarkably similar.Go does have a one-line ternary:var result = map[bool]string{false: "a", true: "b"}[test]It's less of a hack if you declare the lookup "table" separately.SamOn Aug 14, 2018 9:52 PM, Agniva De Sarker wrote:Your answer is here - https://tip.golang.org/doc/faq#Does_Go_have_a_ternary_form.On Tuesday, 14 August 2018 22:13:37 UTC+5:30, Mark Volkmann 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”
Is the ternary really so confusing that it justifies writing 6 lines of code instead of 1? I realize I could eliminate two lines like the following, but this isn’t a good idea if the values come from function calls since there would sometimes be needless function calls.
var color = “blue”
if temperature > 100 {
color = “red”
}
---
R. Mark Volkmann
Object Computing, Inc.
--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
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.
[go-nuts] Re: Ternary ... again
Your answer is here
- https://tip.golang.org/doc/faq#Does_Go_have_a_ternary_form.
On Tuesday, 14 August 2018 22:13:37 UTC+5:30, Mark Volkmann 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”
>
> Is the ternary really so confusing that it justifies writing 6 lines of
> code instead of 1? I realize I could eliminate two lines like the
> following, but this isn’t a good idea if the values come from function
> calls since there would sometimes be needless function calls.
>
> var color = “blue”
> if temperature > 100 {
> color = “red”
> }
>
> ---
> R. Mark Volkmann
> Object Computing, Inc.
--
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.
