Pants is a simple, stackless, dynamically typed, compiled, multiparadigm, statically but optionally hygienically dynamically scoped (holy adverbs), garbage-collected, continuation-based language. MLIA.

More information on the official Pants website.

Project links

pants-lang.org Official site

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've wanted to put this up for a while, but I persuaded myself that at some point I would clean it up, write documentation, and add more features. However, neither is happened, so I'm cutting my losses and just uploading this project.

Project links

GitHub page More information in the README

In 2008, some groundbreaking research was presented in the Proceedings of the National Acadamy of Sciences. This research suggested that not only was our understanding of fluid intelligence being somehow fixed at birth wrong, fluid intelligence and working memory share many of the same cognitive structures, and can be improved with simple memory games.

One such game, the so-called dual n-back continuous performance task, is simple, straightforward, and can be implemented for Android in a weekend, with time to spare for skiing. :)

This is my first Android application, and moreover, my first non-academic Java application, so it sucks hardcore, and it sucks more than just the standard amount of suck that Java brings into the equation. But it seems to work okay.

This is also my first GitHub submission, and it appears GitHub has decided to hate my mime-types, so you may have to right-click and select "save as" to download the APK or something screwy. Who knows.

This app requires Android 1.6 or newer due to the use of the built-in voice synthesis API for the auditory memory task.

Project links	Dependencies
GitHub README Android Package Releases DualNBack-1.0.apk Dropbox got the mime-type right. Yay!	Android 1.6 or newer for teh voice-synthesizing kthx

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).

So, I took Paul Johnston's Javascript implementation and made a simple webform. Trivial, I know. But I took out unnecessary HMAC calculation code, so it should be relatively easy to examine the source if you're worried about using something secure. The webdesign is, hah, optimized for mobile devices.

Project links

SHA1 Webform