penitent, turbulent, multiplex!

Metal music lost me for a while there.

I remember being at Ozzfest in 2006, where the lineup basically consisted of 43 grindcore bands, Disturbed (puke), and SOAD (ruled). Oh, and SYL, who I’d seen like about 5 times already. At that point, I remember thinking, ‘who is listening to this crap?’, and looking to other avenues to boost my adrenaline during workouts.

Despite metal’s tendency to overtaxonimize (power-norweigian-black-ambient-mathcore anyone?), I find that there are two sorts of audiences in metal — those who are attracted to technicality, and those who are attracted to bands who really sound like they mean it. If you listen to Megadeth, for example, and you look at Rust in Peace and then at United Abominations, both audiences will gush about Rust in Peace. It was a technically stunning album when they wrote it, but it also sounded like they were pissed as hell for REAL. UA, on the other hand, had a huge group of people (audience #1) who were saying OMG TEH MEGADETHZ ARE BACK!1!!! but the rest of us (audience #2) who actually like bands to sound like they believe what they’re playing were not impressed.

This is why extreme metal has caused me to snore through the last decade. It’s because I’m in audience #2. If you listen to grindcore, usually it’s some technically ridiculous assault for 36 seconds, and then 1.5 minutes of a slow chugging riff while the singer shrieks the stupidest lyrics in the world into the mic. Newer death metal was basically blast-beat soup while the vox were gargled razorblades that was completely unintelligible. Thrash, as far as I can tell, degenerated into teenagers wailing about orcs. And so on. Black metal was occasionally the only saving grace. (Immortal, despite their goofiness, sounds TRULY PISSED OFF on their later albums. And yes, I know they’re technically not black metal. Get over it.)

ANYHOW. The point I am trying to get at is that things are coming around. Old bands sound like they mean it again. (Slayer, Fear Factory anyone? Well, Slayer only temporarily dropped off the planet with God Hates Us All. The rest of it ruled.) The lyrics and arrangements are just as stupid as ever, but they’re done as if they MEAN IT. And now I’m starting to stumble over stuff in the small-label space that is doing this in spades.

Hayaino Daisuki is the best example of this I’ve found in a while. They went extreme without going grindcore or death. Picture At the Gates played at 12 times the speed. That’s the gist of it. It sounds like the Gothenberg sound mixed slightly with modern melodic death, but you can barely tell because it’s SO DAMN FAST. But where speed generally causes bands to sound LESS brutal, here it just makes them sound insane. And thankfully, there are essentially no blast beats, which are possibly the most boring freaking rhythm that was ever invented (sorry Benante, but it wasn’t your fault anyhow. I blame the Aryans.)

So the gist of this is, freaking awesome. GET IT. Their entire discography (a whopping 8 songs) is availalble on hydrahead’s online store for 4 dollars total. (http://www.hydrahead.com/store/). Oh, and before you get all excited, don’t be fooled by their ‘band photo’ of the four drunk girls. HK is very male, they just throw that image around as a gimmick.

HK also shares most of its members with another Hydrahead-signed band called Gridlink, but I haven’t listened much to them. More on that as it happens.

Also, if you like raging at all, download the Hydrahead Sampler and check out Song 27 by The Austerity Program. Imagine Sweating Bullets at 1000x the insanity quotient as covered by Atari Teenage Riot, you’ve come close. Unfortunately the rest of the Austerity Program’s discography didn’t do much to inspire me, but this is one of their newer tracks so I’m excited to see where they run with it.

“Here, it would seem, is nothing but hate and strife, weariness and bitter envy to fret away our strength, and at last, if we come so far, sorrowful age and death, and thereafter we know not what. Little of good do we find to our hands, and much of evil; nor know I for what ill-doing these burdens are laid upon us.

Yet must we needs breathe such an air as is blown about us, clasping at this happiness which is given, though we may not hold it. At the worst, the game will soon be played, and others will stand where we have stood, and strive as we have striven, and fail as we have failed, and so on, till man has worked out his doom, and the Gods cease from their wrath, or Ragnarok come upon them, and they too are lost in the jaws of grey wolf Fenrir.”

In day-to-day conversation with other developers, a lot of points of debate tend to surface fairly often. A handful that I’ve run into recently:

1. XML should/shouldn’t be used as a data storage format
2. The best/most maintainable way to approach concurrency for performance is X
3. The best/most maintainable way to approach concurrency for responsiveness is X
4. Object-oriented programming is better than / worse than / the same thing as functional/straightline programming

And so on.

One of the few things that graduate school taught me is that a lot of problems that identify as “new” have actually been treated rather thoroughly somewhere back in the annals of time. It’s somewhat embarassing to have to learn this lesson as a software engineer, I think, since we’re a pretty young field as far as intellectual disciplines go.

I suspect that our ignorance of the past is because a lot of the good discussions surrounding them are in the primary literature, which for some reason tends to bring out a stubborn streak in many of the practitioners I know. I think that by suggesting articles from academic journals, some might feel that I’m being snooty, stuck up, or otherwise just showing off my education. I haven’t quite figured that one out yet. But it happens.

However, I feel like people are missing out. There’s some really good stuff out there. For example:

• To address point 1, the aptly-named Michael Stonebraker wrote a great paper on why XML is a terrible data storage format. (Thanks to Rachel Pottinger, my data management professor and supervisor.)
• When researching point 2, I came across a bunch of wild algorithms from the early 80s for parallelizing problems that appear inherently sequential, like searching linked lists. These were written for the Lisp machines, which had hundreds of 1-bit “processors”.
• When talking about point 3 in an operating systems course, we read a pair of papers (here and here)that each put forth reasons why events or threads were more appropriate for this task.
• Point 4 has been discussed cogently in some very old books, many of which I babble about incessantly (the Structure and Interpretation of Computer Programs, and Object-Oriented Software Construction).

It seems counterintuitive to me that so many current problems could have been so well addressed such a long time ago, but I guess it’s the nature of academia to predict (or invent) problems long before they actually become a pain point. The result of this is summed up nicely by Michael Stonebraker in the paper I linked above:

Most current researchers were not around for many of the previous eras, and have limited (if any) understanding of what was previously learned. There is an old adage that he who does not understand history is condemned to repeat it. By presenting ‘ancient history’, we hope to allow future researchers to avoid replaying history.

I think this one goes without saying in almost any discipline. Having a mentor — someone who is wiser than you in some aspect of what you are doing, and hearing out their suggestions — will always stretch your brain. Of course, it can take a while to find someone you click with and who also has the time for you.

While you’re hunting for a mentor, you can get the next-best thing by reading the writings and the code of “famous” software engineers. Books like Programmers at Work and Beautiful Code are great for this sort of thing. And tons of very clever people write open-source software that you can peruse.

While seeking a mentor is a somewhat obvious way to improve, inverting that relationship by looking for a mentee — even when you’re very green yourself — is, in my opinion, a great way to improve as well. Einstein’s old adage of “You do not understand something unless you can explain it to a six-year-old” comes into play here.

I’ve had quite a few opportunities to teach intro-level computer science and software engineering courses, and these experiences clarified a whole bunch of things for me in a hurry. As I sought explanations and examples that would click well with an entire class, I started to learn what methods of organizing programs in the small would communicate well across a broad audience. I try to carry those lessons over into “real-world” projects, so that other developers can (hopefully) make the appropriate modifications to work I’ve done regardless of their skill level.

Plus, working with people who are just starting their journey is refreshing. Their optimism and the breadth of (often strange) approaches that they take to problems that to us are old hat is a lot of fun.

So, get out there! Give, take, interact. Humans are the interesting part of this craft, after all.

I’ve worked my way through roughly 30 more exercises in SICP, and decided it was time to clean house. The exercises to these solutions and supporting libraries have been posted on the SICP project page.

The exercises in this chapter are interesting because they are so varied. They don’t really get more difficult, they just exercise a whole grab bag of different things that the authors are trying to show you. (The ones that the authors warn you are challenging are usually suffixed by “The answer to this would be worth a Ph.D/Turing prize/etc”. I haven’t been attempting those ones.)

Enjoy.