21–30 of 187 posts
That was quite fun to read. The point about Go being too pedantic and thus hindering exploration is something I've felt too. Some of that pain was mitigated by the Sublime Text Go plugin that has shortcuts to add/remove imports.
Also he is spot on about the mascot.
That was quite fun to read. The point about Go being too pedantic and thus hindering exploration is something I've felt too. Some of that pain was mitigated by the Sublime Text Go plugin that has shortcuts to add/remove imports.
> It is possible, however, that the Go team has developed a set of secret signifiers to distinguish these constructions in everyday conversation and not told me about them.
or
> At first I wrote my methods on the values, which seemed like the normal, American thing to do.
Someone posted yesterday about how to pronounce hexadecimal numbers. It's funny because somedoby, somewhere has a lexicon for describing the different overloaded loop types. sidenone: i find overloading cheap or sort of a cheat. I understand it in the content of typed languages, but in something like JavaScript or PHP it fucking sucks.
no ternary is a smart move tho. makes code more readable for all skill levels.
return (data.name !== '' ?: 'New Data')
return (data.name if data.name else 'New Data')
if (data.name != '') {
return data.name
} else {
return 'New Data'
}
The single line version implies at the beginning that all the line does is return. The longer version requires you to read the whole paragraph to figure out what it does.
no ternary is a smart move tho. makes code more readable for all skill levels.
It's a balance between readability meaning 'short, and concise' and readability meaning 'very clear, even if that requires being overly verbose'. return (data.name !== '' ?: 'New Data') or Python style: return (data.name if data.name else 'New Data') vs: if (data.name != '') { return data.name } else { return 'New Data' } The former being much more concise, so that you can display (and grok, perhaps) a single functio…
In other words, Go represents a kind of Machiavellian power play, orchestrated by slow-and-careful programmers who are tired of suffering for the sins of fast-and-loose programmers. The Go documentation refers quite often to intolerable 45-minute build times suffered by the original designers, and I can’t help but imagine them sitting around and seething about all those unused imports from those “other” programmers,…
I think this is part of it, some of the hate comes from people that "know better" (possibly true for some, obviously the Go authors aren't omnipotent) than the Go language designers and are baffled that the language design ideas they know about aren't in the language. But I can tell you in my experience that this type of forceful "everything is a error, no warnings" and "it is done this way (formatting for instance)"…
Agreed. Go lacks many things, but the "zen" of Go is wonderful feature most people aren't aware of, or under appreciate.
I wouldn't use Go for everything, but I wouldn't dismiss it because it doesn't have a favorite language feature.
Earlier quoted context omitted.
I enjoyed that the author readily admits to his own faults concerning Go too: In this telling, the story of Go is really a tale of revenge, not just against slow builds, but against all kinds of sloppy programming. Which in my opinion is too bad, because I myself am a sloppy programmer. This really does seem to be the approach I see with the Go digest mailing list. What I don't understand though is the ease of import…
Go is developed inside Google where all dependencies are checked into their global version control repository. There are literally no versions inside the Google codebase - everything is compiled at head. If you want to upgrade a third party library then you are expected to globally upgrade every user of it .... simply bumping the version of a widely used library can thus turn into a multi-month promotion worthy proje…
The alternative is of course supporting dozens or hundreds of copies of a library and every possible commit hash of said library. I contracted at a python shop that had 81 versions of a single library in use all pinned at different versions. The reason I know this is that I had the great joy of dealing with upgrading all of them after a critical hole was not only discovered (the company knew about it for some time, but just didn't want to bother updating all those apps) but exploited... repeatedly.
> it's perhaps not surprising that you can import code from github .... but not specify which version you want. (unless that is now fixed?)
If by "fixed" you mean there are dozens of solutions to pin versions -- then yes. If you mean baked into the go tool, then no.
IMO, there are two different opposite directions in programming languages and tools approaches, 1) The artistic approach which is very flexible and requires creative thinking and deep understanding of the essence of computing. However, you can easily shoot yourself with it. Languages of this type are for code guru, knights and hackers. 2) The engineering approach which has rigid rules for efficiency and social cooper…
I thought the same thing. They are like the anti-Larry Wall.
no ternary is a smart move tho. makes code more readable for all skill levels.
It's a balance between readability meaning 'short, and concise' and readability meaning 'very clear, even if that requires being overly verbose'. return (data.name !== '' ?: 'New Data') or Python style: return (data.name if data.name else 'New Data') vs: if (data.name != '') { return data.name } else { return 'New Data' } The former being much more concise, so that you can display (and grok, perhaps) a single functio…
> if (data.name != "") {
> return data.name
> } else {
> return "New Data"
> }
if data.name != "" {
return data.name
}
return "New Data"
func name(ref int64) string {
data, ok := get(ref)
if !ok {
return "No Data"
}
if !data.valid {
return "Invalid Data"
}
if data.name == "" {
return "New Data"
}
return data.name
}
Earlier quoted context omitted.
It's a balance between readability meaning 'short, and concise' and readability meaning 'very clear, even if that requires being overly verbose'. return (data.name !== '' ?: 'New Data') or Python style: return (data.name if data.name else 'New Data') vs: if (data.name != '') { return data.name } else { return 'New Data' } The former being much more concise, so that you can display (and grok, perhaps) a single functio…
extra long functions promotes breaking them down into smaller functions.
The difference ends up being between a 5 line function, which does 5 simple things, and a 20 line function that does 5 simple things.
In my previous example, it was 1 line which returned either the name, or 'New Name', or else 5 lines to do the same.
In the end, not a big deal. A matter of taste, rather than judgement, I feel.
In other words, Go represents a kind of Machiavellian power play, orchestrated by slow-and-careful programmers who are tired of suffering for the sins of fast-and-loose programmers. The Go documentation refers quite often to intolerable 45-minute build times suffered by the original designers, and I can’t help but imagine them sitting around and seething about all those unused imports from those “other” programmers,…
Which is why Go has goto's and pointers. Got it. No, Go's adherents are just sloppy in a different way. I have many bad things to say about Haskell, but I admire Haskellers lack of sloppiness. I cannot say the same about Gophers.
You can dock a couple of points for pointers being allowed to be nil. You may want to give half-a-point back for the fact that a nil pointer can actually be a valid implementation of an object, and I actually use this quite a bit. But nil maps can be accidentally unpleasant.