To everyone who made my year the amazing and wonderful year it was, thank you so much!

Check out my post on the Mozy Blog.

I'm looking at Go to see what people are currently doing with programming languages to try and make parallel computing easier. I've only spent two days with Go, but here are my most salient impressions.

• This isn't news, but Go is warty. It feels incredibly inconsistent across almost all aspects of the language. It kinda seems like the language design strategy was to respond to problems with tweaks instead of reconsidering the design. I read countless posts about this initial reaction when Go was first launched, so I won't belabor the point.
• Goroutines are a nice idea, but as far as I can tell are simply lightweight threads, maybe more like fibers (who knows if they swap around). They have this explanation saying "goroutines are different than all these other things like coroutines and threads!" but their argument wasn't compelling. The go keyword seems to be equivalent to forking a command to the background in bash (like with &, admittedly in the same address space), but with no job control. You can't say you want to rejoin, wait, block, nothing. To provide constructs to mimic that, Go gives you:
• Channels. First-order channels are actually a pretty sweet idea, and certainly the thing I was most excited about (message-passing FTW!). Certainly they got stuff right: any type can be passed across a channel, including other channels. That's pretty sweet. And they do the obvious thing where writing to a channel blocks your goroutine until there's space in the buffer, and reading from a channel blocks until there's stuff to read; but there's a huge caveat that just sort of kills it for me: channels are forever. Once you make a channel, as long as you have any reference to it, it is assumed to be open. Even if no one is writing to the channel you're reading from, your read will block indefinitely. So, that sucks. My suggestion for fixing this problem in a minute.
• The defer keyword is pretty cool. I'm not sure I'm sold on its complete replacement of destructors, but I do like the idea. Basically - you can schedule an operation to run at the end of a function call, LIFO. Because this gives you most of the features people typically use destructors for, objects in Go don't have destructors.
• The thing I'm far and away most sold on is Go's implementation of interfaces. Go does not have class hierarchies; instead, Go does what amounts to static duck typing. You provide an interface, which is a list of object methods, and if the object you have has implementations of all of the same method signatures, it is considered an object that implements that interface. So, that's pretty sweet for dependency injection and flexibility, without having to worry about inheritance trees (or even multiple inheritance) or any other complications class hierarchies give you, to much the same end.
• Now, this is just speculation from my light reading, but it appears you can add methods to library objects in your own code. That's something the Scala designers have always been proud of: basically unsealed method sets on an object. The syntax for adding an object method is done after the object's definition much like a regular function, and a few of the code examples even have code that adds new methods to built-in types. It's unclear to me if you have to typedef the built-in type to some new typename to make use of this behavior though. Either way, if I understand correctly, that's pretty sweet. Being able to add your own methods to objects of some other package definitely eases friction between library developers and library users.
• It appears you can assign variables of many types the nil value. This is terrible and gross. Unfortunately, this means that object methods need to check to make sure the object they were called on is not nil it seems (much of the tutorial code involves nil checks in method definitions).

So, let's talk about how to fix the channel issue I mentioned up above. I think the knee-jerk reaction to the idea of a channel is to make channels full duplex. This makes some sense in an IPC context (certainly TCP), but the more I think about it, the less sense I think it makes inside of a process. Most of the channel idioms I've seen so far in Go code don't use the bidirectional nature of channels. Channels seem to be used to either write only or read only. So, if we exploit that, then we can very naturally introduce the concept of closing a channel. Instead of make(chan int) (or equivalent) returning just the new channel, it should instead return the input side and the output side of the channel separately. Then, specific sides of the channel can be force-closed or closed when garbage collected, and the other side of the channel can then throw an error. Note that while I realize you can close any single direction of a channel without requiring the two objects instead of one, having a specific channel-in object and a channel-out object allows most of this channel closing maintenance to be handled by the garbage collector.

Allowing for closing channels, or signaling that a channel is over ("I've generated all the data I can, cap'n!") allows for idioms that indefinitely compute some string of values, but only until it's no longer needed. Conversely, you could make channels that return a limited amount of data, and the reader could easily ascertain that the data stream has ended. Right now, if you create a goroutine that continuously fills or reads from a channel, it will do so until the program ends, at which point it is forcibly terminated. Of course, it is currently possible to work around this by providing another control channel to the goroutine, but that seems (like much of the rest of the language) kind of hacky. If they did this right you could simulate lazy lists or delayed computations in a nicely abstracted and parallel way.

I suppose the suggestion of a channel that you're reading from or writing to closing and throwing an error brings up the whole issue of exceptions. Go doesn't have exceptions, and instead sticks with the C idiom of return values indicating error status. Luckily, Go provides multiple return value support so you can do things like rv, ok = call(), and then check the value of ok for success; however, I really think exception throwing would be useful here, mainly in simplifying boiler-plate code. It's not like you can't implement exceptions with goroutines or something.

Anyway, that's my impression. I really wish Go wasn't so warty, because it seems like it could be real cool. On the other hand, I appreciate how much work it leaves to do in this field :).

I have to write this down before I forget more of it.

I just woke up from watching this amazing Michael Bay/Christopher Guest collaborative summer blockbuster. The only bit of background I remember is that there are these aliens living among us disguised as humans. The main character of the show was this one who looked like one of my professors from the University of Minnesota named Jeremy Rose. Most of the dream has completely faded by now, but I remember some of the final scene.

The Jeremy Rose alien, who I guess was named George Lazlo, just narrowly avoided being destroyed by the evil alien who was hunting him. He did this by turning his 1960s car into a large robot suit and throwing the evil alien somewhere. I don't really remember what happened to the evil alien. Anyway, the Jeremy Rose looking alien is standing there and is negotiating a peace treaty with the local authorities and decides to turn himself in because he has just discovered he is both the last of his kind and the last of the Methodists. So he says, "I, George Lazlo, as the last [some crazy alien race name] and the last Methodist, resolve to live peacefully hence forward," and then he works out details for returning the scrappy band of college friends he made to their familes.

The movie closed with him living in a field with his dog looking at the sky.

I woke up thinking, "this is a fantastic movie! I love how he was so dedicated to being a Methodist," and then it all started to fade and I realized in horror that it wasn't a real movie.

Dear Christopher Guest and Michael Bay, please figure out the rest of the movie as I dreamed it and make it. Please. The Last Methodist. Instant summer blockbuster.

"Let us consider persons at one extreme end of the range of tolerance for dissonance, that is, persons for whom dissonance is especially painful. One might expect that in such extreme instances a person would act so as to avoid the occurrence of dissonance. Thus, for example, he would undoubtedly have experienced the unpleasantness that exists following a decision since there is almost always dissonance. If such a person, for whom dissonance is extremely painful, attempts to avoid the occurrence of dissonance, one would expect to observe that he tried to avoid making decisions or even becomes incapable of making decisions. At this extreme, of course, it becomes a pathological affair...One would also expect that such a person would react very vigorously to the introduction of dissonance into his cognition. This must follow if, indeed, the inability to make decisions is a reaction to fear of dissonance. There is at least one kind of situation where a person cannot avoid dissonance unless he makes an absolute recluse out of himself. That is, occasionally people discuss things, have disagreements, and voice their disagreements. Since the knowledge that someone like oneself holds one opinion is dissonant with holding a contrary opinion, a person for whom dissonance is extremely unpleasant would be expected to react very vigorously to the expression of disagreement from others. He might argue vigorously, be dogmatic, be stubborn, and the like. This syndrome of inability to make decisions, of being very 'decided' and 'one-sided' about issues, and of reacting vigorously in the face of disagreement from others, is one which would be consistent with an interpretation that the person has such low tolerance for dissonance that he has learned to react in anticipation of it...There are other, milder ways of reacting in anticipation of dissonance in order to avoid it. There are persons who, in avoiding post-decision dissonance, make decisions without making them. This can be done sometimes by assuming a passive role with respect to the environment so that, at least in some instances, decisions get made because the ground, so to speak, has moved under one's feet. Thus the decision is made but the person is not responsible for it...such avoidance of dissonance should exist only for persons who have very low tolerance for dissonance coupled with relatively inefficient mechanisms for reducing dissonance once it occurs."

From A Theory of Cognitive Dissonance by Leon Festinger.

I don't know anyone like that. That sounds completely unusual.

I'm posting my slide deck here.

Update: the Game of Life simulator I used for the examples was called Golly (packaged with Ubuntu 8.10), and comes with many of the sample patterns I showed. The basic patterns I showed can be found on the Game of Life's Wikipedia page and Mathworld entry.

The Turing machine pattern came with Golly, but is fully described by its author, Paul Rendell, on his website. Additionally, a similar page can be found for Paul Chapman's Universal Minsky Register Machine (with Golly-supported pattern files).

The Wikipedia is also quite thorough with its discussion of Rule 110 universality, though NKS may have a potentially more accessible discussion (if you can handle it).

Initially, I was planning on delaying posting this article until I wrote the tool I describe near the bottom. Then I realized that neither would ever happen, and so I decided I should cut my losses and just post the article.

If you're like me, you keep hearing about Twitter. Also, if you're like me, you're reading this and thinking "oh, no, not another thing to read about Twitter." Even more, if you're like how I was earlier this week, you'd be thinking "great, JT has sold out now, too."

It's true, I think I've figured it out. And it involved a paradigm shift in how I think about it.

For the entire history of Twitter, my attitude has been "stay off my lawn!" Here's a product that is solely devoted to 140 character status updates? Worthless. And they can't keep it running? Freaking amateur hour. What a joke. Like, I don't get it. The status that I have up there already is my status. Why would I want to change it? There is this huge psychological barrier preventing me from changing my status. It's my status, it didn't change. It's how I'm feeling. Furthermore, what a bunch of noise following other people's statuses. I just didn't get why this is cool. Why in the world would I want my status to be a "retweet" of someone else's?

Well, this week, I decided this was no longer something to take lightly. Since my job is dependent on my ability to learn new technology and adapt quickly, I started to get concerned about how I was just not getting it, and I needed to figure it out. I've had a Twitter account since April 2007. I've had 7 updates since then. It just wasn't interesting to me. But that's two years of me not getting an (evidently) groundbreaking new communication medium. Uh oh. Is this just a personality thing? I mean, clearly I'm not getting something; John Mayer chose Twitter over Jennifer Aniston.¹ Somehow some engineer figured out the magical, albeit totally confusing, formula to appeal to the rest of the social world? Maybe extroverts like updating their status? Maybe the impermanence of the Twitter status has some allure to others that I find lacking?

It turns out, the trick is that Twitter is not a status update website. I mean, it may have been initially, but it's been co-opted for something altogether entirely different.

Twitter is the world's largest chatroom.

Imagine for a minute that you have a chatroom interface. On the bottom is where you type your messages. The main area is where you can see things you've said, and what others have said. Pretty standard. On the right, though, is traditionally a list of users in the room, and you can see the messages that any of them type in your main message box. This does not scale to the size of the internet. Imagine being in a crowded room and everyone had a microphone connected to the speaker system. Yeah, that doesn't work with auditoriums full of people. Or internets.

Instead, in large rooms, typically there is a sphere of communication to which you are privy. Loud people you can hear from far away, and most of your friends are all sort of clustered around you. You can hear things some other people say, and some people can hear what you say. But not everyone can hear everyone.

This is Twitter. Same chat room interface, but instead of just a list of everyone in the room, there's two lists: people you can hear, and people who can hear you. Want to take something you heard and make sure everyone who can hear you heard it? That's a retweet. The things you say? Those are your twitter statuses. Your followers? People who can hear you. The people you follow? People you can hear. It's a perfect analogy, and the perfect way to design a large scale chatroom.

Except Twitter isn't perfect. They designed it for what I initially thought it was for, though everyone uses it for this other thing. So it's slow. It gets overwhelmed. There's much higher latency than a typical chatroom. And, as far as I know, no one has actually made the interface I've described.

So, I think my next project will be this Twitter interface, and who knows, maybe I'll start using Twitter. It shouldn't be too hard, just some Javascript on top of Twitter APIs. Further down the road, a better idea would be to design a better-Twitter: an internet scale chatroom like the one Twitter is being used for, only designed for that purpose.

So, now that I get it, I might not be so crusty and curmudgeonly about current uses of Twitter. Yay.

^1. Not entirely true. I mean, it looked over anyway. John wasn't interested.

First, a bit about how hard drives work.

A hard drive is simply a circular disk (or a collection of them), kind of like a CD, except the data is stored magnetically instead of optically. To read the magnetic data, a little arm with a magnet on the end sticks out over the disk while the disk spins. The little arm reads data off the disk as the disk spin past.

The disk is moving very fast (common disks spin at 7,200 rpm, or about 86 miles per hour at the edge of a 3.5" disk). The arm is also very close to the disk (the head of the arm is 3-7 millionths of an inch away from the disk in modern drives, floating on a pocket of air). Scaled up, hard drives move at speeds similar to an airplane traveling nearly 16 times the speed of sound (mach 16) a width of a human hair (18 micrometers) above the ground!

So, as you can imagine, the worst thing that could possibly happen to a hard drive is for this drive head to crash into the disk, destroying your ability to read the data and scratching up the disk platter. I suppose it's worse if you shoot the drive with a shotgun.

But only barely.

It's very hard for hard drive manufacturers to make disks that don't crash when they're dropped while spinning. They try, but it's just hard to do. Recent laptop drives have gone as far as putting motion detection in so the drive head can be locked away from the disk platter if the drive detects that it's falling. Laptop makers generally recommend that you keep your laptop off (thereby locking the disk head) during any traveling. I sort of think that's silly though. What's the point of a laptop?

Calamity!

So, this week, my sister's laptop suffered an untimely and completely accidental calamity. As the laptop hit the ground, I thought, "boy, it's a good thing it's off."

It wasn't.

Then I thought, "boy, it's a good thing her brother works for a backup company and backed up all her homework for her."

I didn't.

I mean, I work for Mozy, but I'm one of those crazy Linux guys, and Mozy currently doesn't have a Linux client. As a result, I don't use Mozy on my own laptop, and therefore often forget to recommend it to others. I'm a big fan of the adage "practice what you preach;" in this case, I argue software companies should eat their own dogfood and use their own products. Whoops! I guess I'm the odd man out here. I am totally practicing some of the things I'm preaching already: building incredibly distributed, fault tolerant, relational metadata management systems to increase performance for Mozy's backend is fun! But I haven't been practicing or preaching "Back the F:\ up!".

Well, this week, that changed. Be safe, use Mozy.

Yes, I seriously dreamed this.

Dr. Weil's advice was to wear white, not to avoid the raptors, but to assist doctors in quickly locating the inevitable flesh wounds.