It's abstract to think about how one will someday be old and feeble, but as I was filtering over some spam a moment ago, it occurred to me that someday, my children will have to take away my email because I won't be able to properly process Mr. Al-Amin Dagash's email titled REQUEST FOR A LEGITIMATE BUSINESS PARTNERSHIP. Now that's a sobering thought.

I've said several times that XML Namespaces are simple, but I don't have a good proof document. So here it is.

Around about 1998, I was talking to my electronic music teacher and ethused about the day that would come when we could put, say, everything Mozart ever did on a single cube, holding my fingers up in the air separated by about an inch. "You know, not everything Mozart did was great." "No, I get it, I just mean him as someone who put out a lot of stuff. Everything the Beatles ever did would work, too.

The generation gap just isn't what it used to be. A couple of weeks ago I watched this video, a weird lip-sync riff on Star Wars. Fine. A moment's amusement, sure, and on I click. Two days later I went to a birthday party with my kids, and as the older kids were running around I hear one of the 12-year-olds murmuring the lyrics of this song to himself.

In the last few years, there's a really good metric for "movie will be bad" that I've noticed: If Subway gets the license for their kids meals, it's not going to be a very good movie. I first noticed this when Subway got the Brave movie license. By then Pixar had repeatedly fooled me with trailers that didn't seem all that great, but turned into fantastic movies, so even though the Brave trailers didn't wow me, I was open-minded about it.

So, as previous posts show, I like Go well enough. But as a computer-language polyglot, "Go programmer" is not part of my identity, and I try for a balanced view. It is very human to go overboard in both praise and criticism, both easy to find online.

I open with this because this post will take a, ahh, let's say nuanced position on Go, in that it is going to agree a bit with both sides. Go's type system is weak and there are cases where you can only accomplish something via interface{}, reflection, copy/paste, or code generation... but in a rush to talk about what Go doesn't have, what it does have is too often neglected. When using a tool to solve problems what matters is whether there exists a good solution with that tool, not whether a direct port of a good solution from some other tool works. There certainly are real problems that lack good solutions in Go, but that set of problems is smaller than is sometimes supposed.

Some languages provide many power tools, and it is easy to use a bit of one and a bit of another without ever using any individual tool very deeply. Go provides you only a few tools, so you should use each fully.

If your Go code is a horrible copy/paste disaster, you must figure out whether it is because you are not using tools fully, or if you are missing tools. If you are missing tools, use another tool set. I do not consider that any sort of "concession", because I'm not too interested in whether you use Go; I'm interested in showing people how to fully use tools. All of these techniques will work in other languages as well, with varying degrees of convenience.

Not too long ago, flying could be a relatively pleasant experience, but executives focused on cutting costs have stripped away everything flyers associated with luxury or even dignity. Food, baggage handling, boarding in a logical manner: Things once taken for granted now must be paid for or done without. Flights are more crowded than they’ve been since World War II, when they were carrying troops. And on a recent Ryanair flight, I discovered that not even water was free.

It is impossible to deeply understand a solution before you have the problem. Let me give you an example that probably all my readers can relate to: Mathematics education. Do you remember first seeing the quadratic equation and wondering why you should care? Or even if you were a math nerd like me, can you understand why someone would be asking themselves that at that point? The problem is that the students have not had the problem.

I've read a lot of programming blogs, and if you're reading this, you probably have too. So let me tell you up-front this is not your usual security rant that boils down to "just try harder!" Let's talk about smart, experienced programmers who are trying to write secure code, even if they are not security "experts" per se. This is an important set of people, because there is more security-related software in the world to write than can be written by security experts.

In a perfect world, setting that as the target audience would conclude this essay. As your browser's scrollbar shows in the full view, this essay continues on for quite a while. Alas, decades of experience and a trained reasonably high intelligence are not sufficient to write secure software in the current coding environment.

That's also the highest amount of qualifications that can be feasibly brought to bear at any reasonable scale, so in practice that's equivalent to saying it's impossible to write secure software in the current coding environment.

Let's talk about why it's so hard. My thesis is simple:

We write insecure software because our coding environment makes it easier to write insecure software than secure software.

But exploring what it fully means can lead some surprising places. Please join me on a journey as I try to show you why that is not trivially true, but in fact, profoundly true. We do not occasionally pick up insecure tools, like a broken encryption routine or misusing a web framework; we are fish swimming in an ocean of insecurity, oblivious to how steeped in it we are.

I thought I'd use Prime Music to explore some classical I hadn't gotten around to yet. You know... Mozart, some stuff by Beethoven I haven't heard yet, Bach, MC Hammer... you know, the classics.