4 ms·

That can happen. However, when you do not have the proper language features (e.g. pipe operator) then code can become much less readable because it is more verb

by adgasf 8y ago

That can happen. However, when you do not have the proper language features (e.g. pipe operator) then code can become much less readable because it is more verbose and the control flow is unclear. I think that simple languages only lead to more readable code when the problem domain is also simple.

laumars 8y ago
Not really no. The relationship between verbosity and readability of control flow isn't as clear cut as you describe. For example Java is often praised in threads regarding Go yet that is far more verbose. C++ has all the features you described yet is still more verbose (overall) and less readable than Go. Plus your post reads as if complex problems doesn't also decrease the readability in more descriptive languages but my experience is complex logic will be inherently harder to read regardless of the language. I suspect what is actually happening here is your familiarity with language X means you find it easier to read code in language X - and that has nothing to do with verbosity, "proper" language features or whatever else. Personally, however, after 30 years of development on well over a dozen different languages (even some I'd be embarrassed to admit to), Go has consistently been up there for me as one of the easiest to read.
- adgasf 8y ago
  I don't see exactly how my comment connects with yours, so I will just try to clarify / expand on it. * Java is often hard to read because it is verbose and lacks language features. For example, without operator overloading vector math does not read well. * C++ (14 upwards) can be made very readable or it can be made very unreadable because it has so many features. I don't think it is obvious that C++ is less readable than Go. Are we talking about the worst case? the best case? the average case? * The connection between control-flow clarity and verbosity is IMO due to features like the pipe operator and do-notation. These allow you to have code that reads linearly even when the execution is not. The alternative is something with many explicit function calls and nesting that jumps all over the place. Take a look at a Node.js program that uses async/await vs without and you will see what I mean. * A complex problem domain will lead to harder to read code than a simple domain, but this is not relevant. My point is that an implementation for a complex problem in a language with features to manage complexity will be more readable than an implementation for a complex problem in a simpler language. * It sounds like we have both extensively used multiple programming languages but reached different conclusions.
  - laumars 8y ago
    My point was for all the logical reasoning we equate to our choices it still ultimately boils down to a matter of personal taste. For example it sounds like you favour OOP where as I tend to favour a more functional approach? (disclaimer in case of knee jerk comments: I'm not calling Go a "functional language")
    - adgasf 8y ago
      I don't think this is just a matter of taste. Advanced features allow the programmer to express more complex things more directly and less verbosely. I agree that there are some things that are more taste driven (e.g. syntax). BTW, I actually favour FP also.
      - laumars 8y ago
        > I don't think this is just a matter of taste. Advanced features allow the programmer to express more complex things more directly and less verbosely. The fact that you and I disagree about how readable Go is should be evidence enough that it is a matter of taste. Otherwise we would be both agreeing that these facts lead the same outcome on readability rather than myself offering counterexamples to your points (and in fairness I don't disagree that you have well reasoned points even if I don't agree with your conclusion) Here's another contradiction: Perl is often joked as being "executable line noise" because it allows you to express things in any which way you like and is antithetical to the very concept of verbosity. Yet these are properties you argue in favour of readability. So rather than verbosity+features having a boolean outcome on readability, I'd argue it's really more of a spectrum where (1) verbosity and (2) flexible grammar / descriptive features are axis on a graph. Somewhere in the middle will be a cluster of languages people consider readable - with some individuals preferring languages that scores higher or lower on one axis than another. On the topic of verbosity, I've always thought the the language grouping (eg is it a higher or lower level language) gave a better approximation. For example Go does force some functions to be needlessly verbose however when taking your typical Go application and comparing it to the same thing writen in idiomatic Java or C# - languages I'd argue are in the same group - then Go doesn't actually come out all that badly at all. The problem Go has is the ugly areas of Go taints user perception for the other 90+% of the code (if it were as bad as some people express then I wouldn't waste my time with Go either).

by adgasf 8y ago

laumars 8y ago

Not really no. The relationship between verbosity and readability of control flow isn't as clear cut as you describe. For example Java is often praised in threads regarding Go yet that is far more verbose. C++ has all the features you described yet is still more verbose (overall) and less readable than Go. Plus your post reads as if complex problems doesn't also decrease the readability in more descriptive languages but my experience is complex logic will be inherently harder to read regardless of the language. I suspect what is actually happening here is your familiarity with language X means you find it easier to read code in language X - and that has nothing to do with verbosity, "proper" language features or whatever else. Personally, however, after 30 years of development on well over a dozen different languages (even some I'd be embarrassed to admit to), Go has consistently been up there for me as one of the easiest to read.

adgasf 8y ago
I don't see exactly how my comment connects with yours, so I will just try to clarify / expand on it. * Java is often hard to read because it is verbose and lacks language features. For example, without operator overloading vector math does not read well. * C++ (14 upwards) can be made very readable or it can be made very unreadable because it has so many features. I don't think it is obvious that C++ is less readable than Go. Are we talking about the worst case? the best case? the average case? * The connection between control-flow clarity and verbosity is IMO due to features like the pipe operator and do-notation. These allow you to have code that reads linearly even when the execution is not. The alternative is something with many explicit function calls and nesting that jumps all over the place. Take a look at a Node.js program that uses async/await vs without and you will see what I mean. * A complex problem domain will lead to harder to read code than a simple domain, but this is not relevant. My point is that an implementation for a complex problem in a language with features to manage complexity will be more readable than an implementation for a complex problem in a simpler language. * It sounds like we have both extensively used multiple programming languages but reached different conclusions.
- laumars 8y ago
  My point was for all the logical reasoning we equate to our choices it still ultimately boils down to a matter of personal taste. For example it sounds like you favour OOP where as I tend to favour a more functional approach? (disclaimer in case of knee jerk comments: I'm not calling Go a "functional language")
  - adgasf 8y ago
    I don't think this is just a matter of taste. Advanced features allow the programmer to express more complex things more directly and less verbosely. I agree that there are some things that are more taste driven (e.g. syntax). BTW, I actually favour FP also.
    - laumars 8y ago
      > I don't think this is just a matter of taste. Advanced features allow the programmer to express more complex things more directly and less verbosely. The fact that you and I disagree about how readable Go is should be evidence enough that it is a matter of taste. Otherwise we would be both agreeing that these facts lead the same outcome on readability rather than myself offering counterexamples to your points (and in fairness I don't disagree that you have well reasoned points even if I don't agree with your conclusion) Here's another contradiction: Perl is often joked as being "executable line noise" because it allows you to express things in any which way you like and is antithetical to the very concept of verbosity. Yet these are properties you argue in favour of readability. So rather than verbosity+features having a boolean outcome on readability, I'd argue it's really more of a spectrum where (1) verbosity and (2) flexible grammar / descriptive features are axis on a graph. Somewhere in the middle will be a cluster of languages people consider readable - with some individuals preferring languages that scores higher or lower on one axis than another. On the topic of verbosity, I've always thought the the language grouping (eg is it a higher or lower level language) gave a better approximation. For example Go does force some functions to be needlessly verbose however when taking your typical Go application and comparing it to the same thing writen in idiomatic Java or C# - languages I'd argue are in the same group - then Go doesn't actually come out all that badly at all. The problem Go has is the ugly areas of Go taints user perception for the other 90+% of the code (if it were as bad as some people express then I wouldn't waste my time with Go either).