3 ms·

I don't think this is a good example of proving the point that Go is difficult to read. Isn't it expected to internalize the semantics of basic language primiti

by feffe 6y ago

I don't think this is a good example of proving the point that Go is difficult to read. Isn't it expected to internalize the semantics of basic language primitives when learning a new language, or does people just jump in guessing what different language constructs do? IMHO you learn this the first week when reading up on the language features. range returns index and elements by value. The last example does what you asks of it, it's like complaining something is not returned by reference when it's not. Your mistake. Perhaps some linter could give warnings for it.

simiones 6y ago
I don't think you can truly internalize the varying semantics of which operations return lvalues and which return rvalues. At least, I haven't yet been able to in ~2 years of Go programming, and it's a constant source of bugs when it comes up. The lack of any kind of syntactic difference between vastly different semantic operations is at the very least a major impediment to readability. After all, lvalues vs rvalues are one of the biggest complexities of C's semantics, and they have been transplanted as-is into Go. As a much more minor gripe, I'd also argue that the choice of making the iteration variable a copy of the array/slice value instead of a reference to it is the least useful choice. I expect it has been done because of the choice to make map access be an rvalue unlike array access which is an lvalue, which in turn would have given different semantics to slice iteration vs map iteration. Why they chose to have different semantics for map access vs array access, but to have the same semantics for map iteration vs array iteration is also a question I have no answer to.
- marcosdumay 6y ago
  > and they have been transplanted as-is into Go Hum... I don't think anything can return an lvalue in C. Your first paragraph is not a huge concern when programming in C, declarations create lvalues, and that's it. I imagine you are thinking about C++, and yes, it's a constant source of problems there... So, Go made the concept much more complex than on the source.
  - simiones 6y ago
    I think Go has exactly C's semantics here. The following is valid syntax with the same semantics in both: array[i] = 9 *pointer = 9 array[i].fieldName = 9 (*pointer).fieldName = 9 structValue.fieldName = 9 pointer->fieldName = 9 // Go equivalent: pointer.fieldName = 9 // you can also create a pointer to any of these lvalues // in either language with & Go has some additional syntax in map[key], but that behaves more strangely (it's an lvalue in that you can assign to it - map[key] = value - but you can't create a pointer to it - &(map[key]) is invalid syntax).
  - simiones 6y ago
    > I don't think anything can return an lvalue in C. Btw, I was curious to check , here is an example of a function returning an lvalue: struct test { int a; } global; struct test* foo() { return &global; } int main (int argc, char**argv) { printf("%d", global.a); //wil print 0 foo()->a = 9; //or (*(foo())).a = 9; printf("%d", global.a); //will print 9 }
pizza234 6y ago
I think this is actually a very good example of the inverse relationship between logical complexity and language complexity. A language that has implicit copy/move semantics is easier to write (since it's less constrained), and more difficult to read (since in order to understand the code, one needs to know the rules). A language that has explicit copy/move semantics, is more difficult to write (since the rules will need to be adhered to), but easier to read (because the constraints are explicit). Although I don't program in Golang, another example that pops into my mind is that slices may refer to old versions of an array. This makes working with arrays easier when writing (as in "typing"), but more difficult when reading (as in understanding/designing), because one needs to track an array references (slices). (correct me if I'm wrong on this). In this perspective, I do think that a language that is simpler to write can be more difficult to read, and this is one (two) case where this principle applies. (note that I don't imply with that one philosophy is inherently better than the other) EDIT: added slices case.

by feffe 6y ago

simiones 6y ago

I don't think you can truly internalize the varying semantics of which operations return lvalues and which return rvalues. At least, I haven't yet been able to in ~2 years of Go programming, and it's a constant source of bugs when it comes up. The lack of any kind of syntactic difference between vastly different semantic operations is at the very least a major impediment to readability. After all, lvalues vs rvalues are one of the biggest complexities of C's semantics, and they have been transplanted as-is into Go. As a much more minor gripe, I'd also argue that the choice of making the iteration variable a copy of the array/slice value instead of a reference to it is the least useful choice. I expect it has been done because of the choice to make map access be an rvalue unlike array access which is an lvalue, which in turn would have given different semantics to slice iteration vs map iteration. Why they chose to have different semantics for map access vs array access, but to have the same semantics for map iteration vs array iteration is also a question I have no answer to.

marcosdumay 6y ago
> and they have been transplanted as-is into Go Hum... I don't think anything can return an lvalue in C. Your first paragraph is not a huge concern when programming in C, declarations create lvalues, and that's it. I imagine you are thinking about C++, and yes, it's a constant source of problems there... So, Go made the concept much more complex than on the source.
- simiones 6y ago
  I think Go has exactly C's semantics here. The following is valid syntax with the same semantics in both: array[i] = 9 *pointer = 9 array[i].fieldName = 9 (*pointer).fieldName = 9 structValue.fieldName = 9 pointer->fieldName = 9 // Go equivalent: pointer.fieldName = 9 // you can also create a pointer to any of these lvalues // in either language with & Go has some additional syntax in map[key], but that behaves more strangely (it's an lvalue in that you can assign to it - map[key] = value - but you can't create a pointer to it - &(map[key]) is invalid syntax).
- simiones 6y ago
  > I don't think anything can return an lvalue in C. Btw, I was curious to check , here is an example of a function returning an lvalue: struct test { int a; } global; struct test* foo() { return &global; } int main (int argc, char**argv) { printf("%d", global.a); //wil print 0 foo()->a = 9; //or (*(foo())).a = 9; printf("%d", global.a); //will print 9 }

pizza234 6y ago

I think this is actually a very good example of the inverse relationship between logical complexity and language complexity. A language that has implicit copy/move semantics is easier to write (since it's less constrained), and more difficult to read (since in order to understand the code, one needs to know the rules). A language that has explicit copy/move semantics, is more difficult to write (since the rules will need to be adhered to), but easier to read (because the constraints are explicit). Although I don't program in Golang, another example that pops into my mind is that slices may refer to old versions of an array. This makes working with arrays easier when writing (as in "typing"), but more difficult when reading (as in understanding/designing), because one needs to track an array references (slices). (correct me if I'm wrong on this). In this perspective, I do think that a language that is simpler to write can be more difficult to read, and this is one (two) case where this principle applies. (note that I don't imply with that one philosophy is inherently better than the other) EDIT: added slices case.