Category: Uncategorized

waiting for dorian, day 7 – the new (un)normal

whbeebe

Dorian is still stalled over the northern Bahamas. It was the strongest storm to hit the Bahamas in history when it hit as a category 5. It’s now downgraded to a “mere” category 2. It’s killed at least five people, with the possibility of many more after the weather clears and the flood waters subside. We had some very minor rain bands come through Orlando this morning, but that was the extent of it. It’s now partly cloudy with the sun breaking in and out of the clouds. A typical summery day here in central Florida.

I’ve felt that Dorian was the strangest of the hurricanes that have come to Florida so far. I’ve never seen a hurricane park on top of a populated area. It could have easily been south Florida that Dorian decided to stall over, and if it had, south Florida and Miami-Dade would have been nearly scrubbed off the map when it finally moved on. The destruction would be immense, and he economic impact to Florida as well as the southeast would take a decade or more to mitigate. This is what I’m afraid the new normal due to climate change/global warming is delivering to us. Dorian marks the opening of what may very well be many more such catastrophic weather events.

Activity around the Atlantic, Gulf and Caribbean continues apace. The storm near Texas and Mexico is now organized into a depression; the circle indicates circulation due to organization. Tracking forecast indicates it will hit Mexico as a storm, but considering how Dorian has behaved, I’m wondering if our forecast models aren’t going to have to be revisited. The best any of us can do now is just watch the weather satellite photos so we know which way to head away from these things. The storm that originated off Africa is taking longer to organize.

golang considered harmful to simple-minded coders

whbeebe

In spite of my advanced years (I turn 63 in December) I do try to stay reasonably current while at the same time encouraging and supporting the younger generation. There are times, however, where I have to call bullshit on what is written by the youngsters.

I recently came across a BS article via the Hacker News app on my fabulous iPhone 6S+ titled “Golang landmines.” Hacker News is the Slashdot for the ADHD segment of today’s contemporary young white male twenty-something code slingers. HN is essentially a lot of links “curated” and presented in a very simplistic list on your device. I put the word “curated” in quotes because this article, like so many others I’ve encountered via HN, has weird error messages in the body of the article; when you see that, you know you have to follow the link to the original at the top of the article. Thus it was with this article.

As befits its contemporary hipness, this article is hosted on Github. It’s part of a Github conversation which I find rather amusing. I guess anywhere that will host content is a decent platform for publishing and the direct consumption of said publishing, even Github. Whatever… The “author” writes about three “easy to make mistakes” in Go. The problem is that those mistakes can be avoided by the Go tools if you’re half aware and actually pay attention to the warnings and error messages the Go compiler/interpreter emit with your code. For example, consider the following Go example.

package mainimport "fmt"func DoSomething(doit bool) (result string) {if doit {result := "doit is true"}return result}func main() {fmt.Printf(DoSomething(true) + "\n")}

This code snippet is a refinement of the “shadowing considered harmful to your sanity” example at the bottom of the article. The issue is the use of “:=” in line 7 instead of the regular assignment operator “=”. If you read the on-line documentation for Go (Short variable declarations) you’ll discover that “:=” is “shorthand for a regular variable declaration with initializer expressions but no types.” Further reading shows that:

Unlike regular variable declarations, a short variable declaration may redeclare variables provided they were originally declared earlier in the same block (or the parameter lists if the block is the function body) with the same type, and at least one of the non-blank variables is new. As a consequence, redeclaration can only appear in a multi-variable short declaration. Redeclaration does not introduce a new variable; it just assigns a new value to the original.

It isn’t like you haven’t been warned. With that in mind I don’t understand how that so-called code example worked in the first place. If you take my example above and save it in a file named “shadow.go” and either run it directly (go run …) or build it (go build …) you get the following error message:

./shadow.go:7: result declared and not used

at which point everything stops. Granted, it’s not the most helpful error message in the world, and the example from Github surely isn’t helpful in illustrating what’s wrong and where, but Go does attempt to keep you from doing The Wrong Thing, if obscurely. So my question stills stands; how did that code example in the Github article build or run to start with?

And my comment to the Go compiler team is; why in heaven’s name can’t you people come up with clearer error messages that reference the specific language violation you’re complaining about? A clear error message with a reference to the specification would be so much more helpful, especially to those starting to learn the language. I mean, Go is a fairly new language written by Google engineers who should know better.

That’s why the coding youngsters don’t want us old farts around. We point out their errors and in the process cause crippling embarrassment to the little snowflakes.

Update

I’ve been rather rudely asked what I would consider an “appropriate” Go error message. Here’s what my version of Go would emit with such an error:

./shadow.go:7: Use of short variable declaration hides 'result' first declared on line 5.

The error message is now more succinct as to where as well as why, tying directly back to the language specification. This helps aspiring Go programmers learn.