3 ms·

It also confuses ease of reading with density of meaning. It presents the simplistic idea that the less dense statement is always the easiest to read, which mig

by orclev 10y ago

It also confuses ease of reading with density of meaning. It presents the simplistic idea that the less dense statement is always the easiest to read, which might be true in isolation but it's almost always false in the larger context. It's pretty easy to prove this, simply ask yourself, would you rather read a quicksort implementation in C or assembly? C is certainly more dense in meaning, but it's also much easier to read precisely because of that denseness. I'm not a fan of Scala by any means, I think it suffers from a lot of the same problems C++ has, but I'd still take it over Go any day. In an effort to be easy to learn Go rejects any non-trivial concepts in the language leading to a language that makes expressing complicated concepts complex and trivial concepts verbose. Go is a language predicated on the idea that C is very nearly the pinnacle of language design, if only it hadn't included those complicated pointer things, and the only thing that really held it back was insufficient tooling. It rejects modern languages as unnecessarily complicated, and instead stipulates that instead of a complex language, it's your code that should be complex.

fauigerzigerk 10y ago
>It also confuses ease of reading with density of meaning He says more about that later and I find that part more interesting: "Go code is explicit and the Scala code requires context to understand." I believe he is saying that in order to understand a particular Scala expression you need more information from outside the immediate local context than in Go, i.e. information only available in type definitions. I haven't thought about it enough to say whether or not I agree, but I think it is a very interesting hypothesis. If it turns out to be true, it would support the claim that Go works better than more type centric languages whenever developers are less familiar with the codebase, irrespective of language proficiency. I find it annoying that familiarity with the language and familiarity with the codebase keep getting conflated in these debates. They are completely seperate issues.
- orclev 10y ago
  Just to muddy the waters a bit, you also need to add in familiarity with standard libraries and conventions. To use an example that hopefully a sufficiently large chunk of the readership is at least passingly familiar with, if you're familiar with the Java Spring framework and its conventions then understanding an annotated piece of code is usually fairly trivial. Without that understanding however it's going to be utterly confusing as none of the code would seem to bear any relation to the rest. Programming is in many ways the act of artfully layering abstractions to concisely express a complicated concept. If you are unfamiliar with, or do not understand some of those abstractions you're obviously not going to fully understand the concept being expressed. Part of the advantage to a strong type system is that you only need to learn a particular abstraction once. Once you learn how a particular type (or set of inter-related types) functions, anytime you see that type used from then on you immediately understand something about the system its being used in. This is in contrast to a weakly typed system where the only thing you know for sure is how the author encoded his expectation of the system at a given point (this is important, you don't know what the author intended just from the code as the author could have made a mistake). In a weakly typed system it's left as an exercise for the reader to try to divine the expected behavior from clues left in the code. This is of course not even touching on the case when the runtime behavior deviates from the expected behavior in often quite significant fashion. Looked at from another perspective, strongly typed languages promote modularity and re-use of concepts, while weakly typed ones tend to favor explicit and single use concepts. That is, the abstractions in the strongly typed system are implicit, but often re-used across many code bases, while the abstractions in the weakly typed language will tend to be explicit and either re-used less often, or else customized for a particular use case to the extent that it's unsafe to make assumptions about the expected behavior of the abstraction.
dkarl 10y ago
It also confuses ease of reading with density of meaning. It presents the simplistic idea that the less dense statement is always the easiest to read, which might be true in isolation but it's almost always false in the larger context. This is my experience with Go in a nutshell. You start out pleased by how easy it is to read the code. You end up frustrated by how much damn code you have to wade through to understand a relatively simple system. Perhaps the fantasy is that Go forces programmers to write simple, elegant systems. In reality, of course, the effect is much smaller than hoped. Go is much easier to get right than C, so programmers have no fear of writing vast reams of code. This is not such a problem for the original author, whose understanding of the system precedes the implementation, but anyone else reading the code has to refine meaning from very meager ore.

by orclev 10y ago

fauigerzigerk 10y ago

>It also confuses ease of reading with density of meaning He says more about that later and I find that part more interesting: "Go code is explicit and the Scala code requires context to understand." I believe he is saying that in order to understand a particular Scala expression you need more information from outside the immediate local context than in Go, i.e. information only available in type definitions. I haven't thought about it enough to say whether or not I agree, but I think it is a very interesting hypothesis. If it turns out to be true, it would support the claim that Go works better than more type centric languages whenever developers are less familiar with the codebase, irrespective of language proficiency. I find it annoying that familiarity with the language and familiarity with the codebase keep getting conflated in these debates. They are completely seperate issues.

orclev 10y ago
Just to muddy the waters a bit, you also need to add in familiarity with standard libraries and conventions. To use an example that hopefully a sufficiently large chunk of the readership is at least passingly familiar with, if you're familiar with the Java Spring framework and its conventions then understanding an annotated piece of code is usually fairly trivial. Without that understanding however it's going to be utterly confusing as none of the code would seem to bear any relation to the rest. Programming is in many ways the act of artfully layering abstractions to concisely express a complicated concept. If you are unfamiliar with, or do not understand some of those abstractions you're obviously not going to fully understand the concept being expressed. Part of the advantage to a strong type system is that you only need to learn a particular abstraction once. Once you learn how a particular type (or set of inter-related types) functions, anytime you see that type used from then on you immediately understand something about the system its being used in. This is in contrast to a weakly typed system where the only thing you know for sure is how the author encoded his expectation of the system at a given point (this is important, you don't know what the author intended just from the code as the author could have made a mistake). In a weakly typed system it's left as an exercise for the reader to try to divine the expected behavior from clues left in the code. This is of course not even touching on the case when the runtime behavior deviates from the expected behavior in often quite significant fashion. Looked at from another perspective, strongly typed languages promote modularity and re-use of concepts, while weakly typed ones tend to favor explicit and single use concepts. That is, the abstractions in the strongly typed system are implicit, but often re-used across many code bases, while the abstractions in the weakly typed language will tend to be explicit and either re-used less often, or else customized for a particular use case to the extent that it's unsafe to make assumptions about the expected behavior of the abstraction.

dkarl 10y ago

It also confuses ease of reading with density of meaning. It presents the simplistic idea that the less dense statement is always the easiest to read, which might be true in isolation but it's almost always false in the larger context. This is my experience with Go in a nutshell. You start out pleased by how easy it is to read the code. You end up frustrated by how much damn code you have to wade through to understand a relatively simple system. Perhaps the fantasy is that Go forces programmers to write simple, elegant systems. In reality, of course, the effect is much smaller than hoped. Go is much easier to get right than C, so programmers have no fear of writing vast reams of code. This is not such a problem for the original author, whose understanding of the system precedes the implementation, but anyone else reading the code has to refine meaning from very meager ore.