4 ms·

Go is not the language for you if you care about mashing as much logic into a single line as you can. Also, I can count the number of times in my 15 years of p

by NateDad 12y ago

Go is not the language for you if you care about mashing as much logic into a single line as you can. Also, I can count the number of times in my 15 years of professional development experience that I've wanted to count down to zero using an unsigned int as the index... never. Which is not to say that the declarative isn't nice, just saying that the example of the infinite loop is not exactly compelling.

pcwalton 12y ago
> Go is not the language for you if you care about mashing as much logic into a single line as you can. The point here is that iterators can reduce bugs, independent of aesthetic concerns. > Also, I can count the number of times in my 15 years of professional development experience that I've wanted to count down to zero using an unsigned int as the index... never. I like to give that example because it was something I actually hit and a bug that I actually had to fix. In fact I just hit that again yesterday when iterating over a list in reverse order (painting order for CSS box-shadow).
- zzzcpan 12y ago
  > The point here is that iterators can reduce > bugs, independent of aesthetic concerns. Iterators can reduce bugs, really? This is a very flawed point. Bugs are not caused by lack of language features, they are caused by people. And people make mistakes independent of language features and sometimes because of language features causing cognitive overload or require them to make assumptions.
  - Dewie 12y ago
    The way I see it is that you can reduce bugs by increasing the level of abstraction, which in this case means to use things that are more straightforward and less flexible: the ultimate looping-construct is arguably the while-loop, by using a counter to index into the array (if you're working with an array, anyway). But with that flexibility comes more room for error: maybe your increment is wrong, maybe your while-condition is wrong, maybe you inadvertently change the index inside the loop without meaning to, etc. A step over that is to explicitly just say that you want to iterate over each element in the array. You don't get to choose how, but you probably wanted to iterate over it from start to finish anyway. The highest level is a function that encapsulates exactly what you want without having to bother with explicitly iterating over the collection yourself. Now you can't even mess up how you use each member of the array, because that is already handled by the function. A higher level of abstraction means less flexibility, which means fewer potential things that you can screw up. I don't see how that is a flawed point.
    - zzzcpan 12y ago
      Well, the way I see it has nothing to do with levels of abstractions or flexibility, but everything with reducing amount of brain power required to understand the program. Sometimes abstractions do help, other times they add unnecessary complexities and reduce people's brain power to understand the rest of the code and therefore make mistakes in it. This is all about psychology. Sorry, if I was rude, I'm just tired of pseudo-scientific language designs.
  - masklinn 12y ago
    > And people make mistakes independent of language features Unless language features prevent the existence of these bugs. Javascript will blindly let you concatenate a number and a string, Go will not. Therefore you can't make the mistake of unknowingly concatenating a number and a string in Go. Thanks to a language feature. Iterators prevent indexing mistakes (off-by-one errors, index overflow or overflow, wrong-variable use), therefore iterators can indeed reduce bugs.
    - zzzcpan 12y ago
      > Therefore you can't make the mistake of unknowingly > concatenating a number and a string in Go. Look at this another way: If you need to do that you now have to think about it and explicitly convert a number into a string. But while you are thinking about it you can make mistake of concatenating a number with a wrong string or make some other screw up, because your thinking power is now reduced.
      - masklinn 12y ago
        > If you need to do that you now have to think about it and explicitly convert a number into a string. You have to think about it either way, the feature precludes forgetting about it. > you can make mistake of concatenating a number with a wrong string or make some other screw up Which you can make in both cases. > because your thinking power is now reduced. Your thinking power is not reduced, it's increased: you don't have to wonder whether you should convert something to a string or it already is one, the compiler will tell you, so you can focus better on the actual work at hand.
        zzzcpan 12y ago
        No, if conversion is implicit you don't have to think which function to call, where to find it and which library to include. Quite significant cognitive overhead I'd say. Having separate concatenation operator with implicit conversion could reduce that overhead: a := "foo" ~ "bar" ~ 123 Instead of: import "strconv" a := "foo" + "bar" + strconv.Itoa(123) But this is not how Golang guys make decisions. And I'm fine with that nowadays as long as they don't claim to be right in that regard.

by NateDad 12y ago

pcwalton 12y ago

> Go is not the language for you if you care about mashing as much logic into a single line as you can. The point here is that iterators can reduce bugs, independent of aesthetic concerns. > Also, I can count the number of times in my 15 years of professional development experience that I've wanted to count down to zero using an unsigned int as the index... never. I like to give that example because it was something I actually hit and a bug that I actually had to fix. In fact I just hit that again yesterday when iterating over a list in reverse order (painting order for CSS box-shadow).

zzzcpan 12y ago
> The point here is that iterators can reduce > bugs, independent of aesthetic concerns. Iterators can reduce bugs, really? This is a very flawed point. Bugs are not caused by lack of language features, they are caused by people. And people make mistakes independent of language features and sometimes because of language features causing cognitive overload or require them to make assumptions.
- Dewie 12y ago
  The way I see it is that you can reduce bugs by increasing the level of abstraction, which in this case means to use things that are more straightforward and less flexible: the ultimate looping-construct is arguably the while-loop, by using a counter to index into the array (if you're working with an array, anyway). But with that flexibility comes more room for error: maybe your increment is wrong, maybe your while-condition is wrong, maybe you inadvertently change the index inside the loop without meaning to, etc. A step over that is to explicitly just say that you want to iterate over each element in the array. You don't get to choose how, but you probably wanted to iterate over it from start to finish anyway. The highest level is a function that encapsulates exactly what you want without having to bother with explicitly iterating over the collection yourself. Now you can't even mess up how you use each member of the array, because that is already handled by the function. A higher level of abstraction means less flexibility, which means fewer potential things that you can screw up. I don't see how that is a flawed point.
  - zzzcpan 12y ago
    Well, the way I see it has nothing to do with levels of abstractions or flexibility, but everything with reducing amount of brain power required to understand the program. Sometimes abstractions do help, other times they add unnecessary complexities and reduce people's brain power to understand the rest of the code and therefore make mistakes in it. This is all about psychology. Sorry, if I was rude, I'm just tired of pseudo-scientific language designs.
- masklinn 12y ago
  > And people make mistakes independent of language features Unless language features prevent the existence of these bugs. Javascript will blindly let you concatenate a number and a string, Go will not. Therefore you can't make the mistake of unknowingly concatenating a number and a string in Go. Thanks to a language feature. Iterators prevent indexing mistakes (off-by-one errors, index overflow or overflow, wrong-variable use), therefore iterators can indeed reduce bugs.
  - zzzcpan 12y ago
    > Therefore you can't make the mistake of unknowingly > concatenating a number and a string in Go. Look at this another way: If you need to do that you now have to think about it and explicitly convert a number into a string. But while you are thinking about it you can make mistake of concatenating a number with a wrong string or make some other screw up, because your thinking power is now reduced.
    - masklinn 12y ago
      > If you need to do that you now have to think about it and explicitly convert a number into a string. You have to think about it either way, the feature precludes forgetting about it. > you can make mistake of concatenating a number with a wrong string or make some other screw up Which you can make in both cases. > because your thinking power is now reduced. Your thinking power is not reduced, it's increased: you don't have to wonder whether you should convert something to a string or it already is one, the compiler will tell you, so you can focus better on the actual work at hand.
      - zzzcpan 12y ago
        No, if conversion is implicit you don't have to think which function to call, where to find it and which library to include. Quite significant cognitive overhead I'd say. Having separate concatenation operator with implicit conversion could reduce that overhead: a := "foo" ~ "bar" ~ 123 Instead of: import "strconv" a := "foo" + "bar" + strconv.Itoa(123) But this is not how Golang guys make decisions. And I'm fine with that nowadays as long as they don't claim to be right in that regard.