Archives For September 2016

golangIn 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 main

import "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.

1000px-wave-svgBack on 14 July I wrote a post titled “no more java“, in which I swore off the use of Java for everything new and to “walk away from any Java programming opportunity.”

It turns out that there is, practically speaking, no way for me to do that. As much as I despise Oracle, the use of the language throughout the last 21+ years of my software engineering career (Java officially turned 20 in 2015) isn’t something I can just blithely walk away from. As I came to discover over the last 60 days, while there are a lot of very good programming languages besides Java, there are some things for which Java is the better fit, warts and all.

That’s not to say I didn’t find the other languages I looked at as less than Java. I found them all quite compelling in their own rights. The languages I did go back and look into included Python, C-Ruby, JavaScript (via node.js), the latest stable version of C++ (C++14 via gcc and clang), Google Go (up to 1.7) , and Rust (up to 1.11). Notable by its absence is Swift. I chose not to dive into Swift because it’s still only on one platform (OS X, soon to be called macOS) and because it’s still in a state of flux as it transitions to Swift 3.

All those languages I did look deeply into were quite compelling in their own rights and offered powerful solutions for different classes of problems. And while they tended to overlap some features and capabilities of Java, they could never replace Java for the types of software problems I like to work on. And please note, when I speak of the languages I also speak of the development, build, test, and deployment tools that wrap a language and help make it a powerful problem solver.

I don’t consider my two months looking elsewhere a waste of time; far from it. It was an eye-opening trek into languages I would have never taken otherwise, as well as a deeper dive into some languages I’d had considerable experience with before, such as Python and Ruby (in fact, working with Python 3.5 was almost like re-learning the language, as the last version I’d touched was 2.4). With Java I’d grown a bit stale in my thinking, which is never a good thing. Looking at other programming languages fosters opportunities to expand perspectives and offers alternative solutions to tough problems for which Java might not be the best fit. It also illustrate ways to weave these “new-ish” solutions back into new and existing Java solutions.

And finally, by taking two months away from my Java work, I discovered when I came back that tough problems I couldn’t quite solve before were suddenly solvable, some of them quite easily so. I really needed a break away from Java.

So it’s back to Java, or more precisely, the Java Virtual Machine (JVM). For with the JVM I also have Scala, Groovy, Gradle, and JRuby, not just Java 8. I’m using the Actor pattern¬†Futures and Promises and the Parallel Collections Library supported by Scala for modeling and simulation, while using Groovy and JRuby to solve unique problems while calling down into the Java libraries, especially for UI bits. And finally I’m getting the hang of using Gradle as my primary build, test, and deployment framework. I am so tired of Ant and I’m no fan of Maven either.

I need to do this again, at least once/year, to maintain a clear mindset and fresh perspective. I look forward to my next walk-about through the programming language landscape.

placing a private call

Andy, over at blog.atmtx.com, has redesigned his blog, and in the process gone down a different path with sharing his photography. One of his entries, “Deep Blacks: Checking Status“, reminded me of a similar set of photos I took in Japan while riding a train to Sapporo Japan in 2013. I’ve had my own work buried for so long that I actually appreciate it again. All of these were taken with the original Olympus OM-D E-M5 and the M.Zuiko 12-50mm zoom, a lens that the photographic paperback intellectuals tends to look down on for no good reason.

This photo fits in with Andy’s observation that the use of cell phones on trains is carefully controlled. This gaijin was standing in the section between cars in order to place his smart phone call so as not to disturb the other passengers, who were sitting quietly.

on the train to saporo with friends