Mark, Funny that -- you suggest that adding another syntax for the same behaviour "might help with adoption".
I think the opposite is true. My friend has been learning iOS development and has found many things confusing. There is the lambda syntax in Swift, and then the trailing lambda syntax (Scala does a similar thing, much like Ruby blocks). There is the already peculiar method signature that includes parameter names (a hold-over from Objective-C), but then there are exceptions to the rule as you go deeper. So many variations to keep straight and so many things to learn all at once. What is the real benefit of this complexity? No. I think Go's simplicity is what will help with adoption -- especially as brand new developers come online. Software development isn't writing poetry. The goal isn't words that look nice on a page and cause you to ponder what the author was feeling. Maybe the verbosity of Go isn't as "enjoyable" to read as your favourite language, but it is easy to understand. Nathan. https://yng.mn/programminggo On Wednesday, 15 August 2018 05:23:36 UTC-6, Mark Volkmann wrote: > > I realize I’m just another new person to Go asking for features that have > been discussed many times before and that are very unlikely to be changed. > But I’d like to consider a kind of middle ground that applies to many > potential features. > > I understand that many requests for syntax additions are rejected on two > grounds. One is that it is possible to abuse the feature, resulting in code > that is more difficult to understand. Another is that it makes the language > specification larger, adding to the list of things that new Go developers > must learn. > > I see many proposals that would reduce the amount of code to be typed > rejected on the basis that doing that alone is not a valid reason to add a > feature. For things that would not be used often, I agree with that. But I > want to discuss two features that I use often in other languages. > > The first is ternaries. What if only simple, non-nested ternaries were > supported? For example, color := temperature > 100 ? “red” : “blue”. This > seems so much more clear than the map[bool]:string trick that some have > proposed. Writing this with an if statement takes either 4 or 6 lines. This > comes up often enough in code to make a significant difference. I think > it’s hard to argue that this has the potential to make code harder to read > if they can’t be nested. > > The second is arrow functions. What if only functions that return the > result of a single expression were supported? For example, n => n * 2. > Compare this to func (n int) { return n * 2 }. The value of this is closely > tied to whether generics are added to the language at some point. > > Adding just a few things like these to the language might help with > adoption and that in itself is a worthwhile goal. I suspect many developers > that love Go aren’t currently using it on real projects. Getting more > developers to consider Go makes that more likely. > > --- > R. Mark Volkmann > Object Computing, Inc. > > On Aug 14, 2018, at 12:18 PM, Axel Wagner <axel.wa...@googlemail.com > <javascript:>> wrote: > > There is lots of discussion findable here: > https://groups.google.com/forum/#!searchin/golang-nuts/ternary%7Csort:date > There's a bit of discussion on the issue tracker: > https://github.com/golang/go/issues?utf8=%E2%9C%93&q=ternary+operator -- > in particular https://github.com/golang/go/issues/23248 > There's more discussion on the reddit: > > https://www.reddit.com/r/golang/comments/5dqpab/what_is_the_reasoning_behind_go_not_having_a/ > > > On Tue, Aug 14, 2018 at 6:43 PM Mark Volkmann <r.mark....@gmail.com > <javascript:>> 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...@googlegroups.com <javascript:>. >> 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.
