4 ms·

This stuck out for me too. Sheer information density per character isn't something I value in a programming language. Being able to be clear and concise is cer

This stuck out for me too. Sheer information density per character isn't something I value in a programming language. Being able to be clear and concise is certainly desirable. But that's not in any way the same thing; orthogonal high level concepts (iterators jump to mind) are great ways to hide complexity while keeping code clear, but ten characters of line noise where every symbol has some subtle meaning will turn into a nightmare when you've got five hundred lines of noise to make sense out of. I'm not a huge fan of Go, but as a counter-example to what's in this post, you can really see the virtues of the keep-it-simple approach the Go language designers have taken.

zzzcpan 7y ago
Go relies on naming for everything, which pushes information density into naming where every symbol could have special meaning and special behavior too [1], but not consistent, universal or shaped and enforced by the compiler. It means more code to understand and write while less language syntax to learn. Other approach is to have more syntax, which can be more consistent, universal, flexible and therefore require less code to understand and write. Information density doesn't really change it's just syntax is more useful in more cases so it can replace a lot more specially crafted library functions. [1] https://golang.org/pkg/regexp/ https://golang.org/pkg/regexp/
- nrdvana 7y ago
  I hadn't thought about it that way before, but I like and agree with this analysis. While method names can contain all the information, it requires more words and you end up with a Java-style mess thatContainsTheWholeAlgorithmInTheName. The punctuation is almost like having a bunch of one-cahracter standard names that everyone understands without having to agree on standard conventions.
tluyben2 7y ago
> Sheer information density per character isn't something I value in a programming language Not that extreme but I find it undervalued in most mainstream languages; I value easy to understand and and descriptive for stuff I rarely use or need, but for things I use all the time, like map, fold, etcetc; why are those constructs not 1 char; it is not like I will forget the use or when someone reads it will not know the use of those functions.
raiph 7y ago
> Sheer information density per character isn't something I value in a programming language. That's a strawman. > Being able to be clear and concise is certainly desirable. That's obviously what the OP meant. Anything else would be silly. > orthogonal high level concepts Everything in the line the OP quoted as being an exemplar of flying over folks' heads if they don't know P6, and that "skipping a single symbol might drastically change your interpretation", is also an exemplar of clarity and concision of orthogonal high level concepts. > ten characters of line noise where every symbol has some subtle meaning will turn into a nightmare when you've got five hundred lines of noise to make sense out of. Where did "line noise" and "subtle meaning" suddenly come from other than prejudice? Perhaps you don't know that [op] means a prefix reduction in P6. But if I tell you that in the following it means "sum", and the result is 6, do you now understand? [+] 1, 2, 3 Boom, now you understand how to turn any infix operator into a reduction in P6. That's an orthogonal high level concept (any infix operator can be used inside the [op]) expressed in a clear and concise manner. All the rest of that line is equally simple. But it will fly over your head until you learn it. Your assumption that it's line noise and subtle based purely on not knowing the language is indistinguishable from ignorance and prejudice and coupled with the fact that the OP was making that precise point means your comments are indistinguishable from sheer bloody mindedness. > I'm not a huge fan of Go, but as a counter-example to what's in this post, you can really see the virtues of the keep-it-simple approach the Go language designers have taken. You can see the virtues of the keep-it-simple approach of English as a counter-example to what's in Devanagari if you can read English and can't read Devanagari. What does that tell us about a world in which there'll be more Indian devs than US devs in a few years?

zzzcpan 7y ago

Go relies on naming for everything, which pushes information density into naming where every symbol could have special meaning and special behavior too [1], but not consistent, universal or shaped and enforced by the compiler. It means more code to understand and write while less language syntax to learn. Other approach is to have more syntax, which can be more consistent, universal, flexible and therefore require less code to understand and write. Information density doesn't really change it's just syntax is more useful in more cases so it can replace a lot more specially crafted library functions. [1] https://golang.org/pkg/regexp/ https://golang.org/pkg/regexp/

nrdvana 7y ago
I hadn't thought about it that way before, but I like and agree with this analysis. While method names can contain all the information, it requires more words and you end up with a Java-style mess thatContainsTheWholeAlgorithmInTheName. The punctuation is almost like having a bunch of one-cahracter standard names that everyone understands without having to agree on standard conventions.

tluyben2 7y ago

> Sheer information density per character isn't something I value in a programming language Not that extreme but I find it undervalued in most mainstream languages; I value easy to understand and and descriptive for stuff I rarely use or need, but for things I use all the time, like map, fold, etcetc; why are those constructs not 1 char; it is not like I will forget the use or when someone reads it will not know the use of those functions.

raiph 7y ago

> Sheer information density per character isn't something I value in a programming language. That's a strawman. > Being able to be clear and concise is certainly desirable. That's obviously what the OP meant. Anything else would be silly. > orthogonal high level concepts Everything in the line the OP quoted as being an exemplar of flying over folks' heads if they don't know P6, and that "skipping a single symbol might drastically change your interpretation", is also an exemplar of clarity and concision of orthogonal high level concepts. > ten characters of line noise where every symbol has some subtle meaning will turn into a nightmare when you've got five hundred lines of noise to make sense out of. Where did "line noise" and "subtle meaning" suddenly come from other than prejudice? Perhaps you don't know that [op] means a prefix reduction in P6. But if I tell you that in the following it means "sum", and the result is 6, do you now understand? [+] 1, 2, 3 Boom, now you understand how to turn any infix operator into a reduction in P6. That's an orthogonal high level concept (any infix operator can be used inside the [op]) expressed in a clear and concise manner. All the rest of that line is equally simple. But it will fly over your head until you learn it. Your assumption that it's line noise and subtle based purely on not knowing the language is indistinguishable from ignorance and prejudice and coupled with the fact that the OP was making that precise point means your comments are indistinguishable from sheer bloody mindedness. > I'm not a huge fan of Go, but as a counter-example to what's in this post, you can really see the virtues of the keep-it-simple approach the Go language designers have taken. You can see the virtues of the keep-it-simple approach of English as a counter-example to what's in Devanagari if you can read English and can't read Devanagari. What does that tell us about a world in which there'll be more Indian devs than US devs in a few years?