Great Minds Think Different

So I’ve actually been pretty heavily involved in iPhone development since the SDK was released to developers. I’ve taught a class on iPhone development and worked on an iPhone app for Apple. However, my debut into the App Store has waited until today.

The App Store is a potentially great idea gone a bit wrong. There’s definitely some excellent work in there, but it’s often swamped by an ocean of 99-cent garbage. And what’s worse, a developer can make a good bit of money by writing one of these 99-cent garbage apps, like a fart noise app or a flashlight.

So being the cynic and lover of money that I am, I decided to get in on that. I decided that one weekend, I would sit down and crank out some piece of crap in a few hours and sell it for 99 cents.

I wrote Tap The Dot in 3 hours and 14 minutes; I timed myself. It’s a game, for a rather loose definition of the word “game”. The basic gameplay mechanic is this: the app puts a dot on screen. You tap it. Then the app puts another dot on screen. You tap it. Repeat.

It’s now available on the App Store for 99 cents:

Tap The Dot

My initial aim is to recoup the cost of the iPhone Developer Program ($99). If I make more than that, then joy for me. Stay tuned.

VMware Fusion 2.0 Beta 1 is out.

You can now see what I spent most of my summer in 2007 working on.

Before:

Now:

Designing and implementing the window in the second screenshot was my intern project at VMware. It doesn’t look like much, but some of the hardest work I did was messing around in the back end to make it possible to, for example, display the power state and guest OS name in the list. (Long story.)

It feels really weird to have what is probably the most challenging and significant programming work I’d done until then out in the wild¹. That it’s such a highly visible element of Fusion’s UI is just ridiculous. You can’t avoid seeing it. This is a watershed moment in my life as a software developer.

Of course this isn’t the flagship feature of Fusion 2.0; the major changes are multi-mon support in Unity, experimental DirectX 9 Shader Model 2 support, the inclusion of VMware Importer, and seamless printing from Windows guests.

Congrats to the Fusion team on the release!

¹ The current holder of the “most challenging and significant” record goes to what appears as “P3″ in those screenshots – a small operating system kernel.

So maybe at some point I will have something I can actually write¹ about. I.e., a releasable piece of software. Won’t that be exciting.

1. I refuse to use the word “blog” as a verb.

The next time you resize a window on your computer, please spare a moment to think of the frustration of the programmer who implemented the resizing logic, and how that programmer’s efforts are what made possible a seamless window-resizing experience for you.

Seriously, a lot of shit happens when you resize a window. If there are custom-written controls inside there that don’t get fucked up when the window resizes, some programmer spent an awful lot of time on something that most people won’t notice. I speak from experience.

It really is rather galling to know that the harder you work on something, the less people will notice it. That is the conundrum of 90% of UI programming.

I’ve been bothered by something for a while. I use Adium, and I have it display a Growl notification whenever I get an IM and Adium is in the background. The Growl notification contains the name of the contact that the IM came from, and the first line of the message itself. Sometimes I don’t want that, such as when there are people reading my screen and the IM contains something I’d rather those people didn’t see. Unfortunately, there’s no option to stop Adium from displaying the contents of the IM in the Growl notification.

There are two possible solutions to this.

1. File a bug report or feature request with the Adium developers.
2. Download all 200 megs of the Adium source, modify it myself, build it and feel all proud of myself for running a custom build of an open source app.

Guess which one I chose.

I slept badly that night, knowing that I’m turning into one of those people.

I have a job for which I’m supposed to learn Lisp. My employer has said to me, many times, that many people find Lisp daunting at first, but gradually get used to it and come to love it as they learn it. In all of the Lisp books I’ve read, in the introductions, the authors usually devote an entire section to expounding on the virtues of Lisp. So Lisp definitely has its devoted proponents, which baffles me.

It’s pretty clear why most Lisp books seem to infatuated with the language. It’s not just because they’re books about Lisp (it’s perfectly possible for a book about a language to be completely dispassionate — witness K&R, which actually points out design flaws in C on occasion). Here’s the argument: first of all, new books about Lisp are no longer being written, simply because even if it ever was a mainstream implementation language, it’s been soundly eclipsed by C and C++ and their ilk. Lisp is now only used in niche markets like artificial intelligence research and cognitive modeling (two related fields). Therefore, Lisp books currently in existence are generally old. Therefore, they are from an age when there were few or no compelling alternatives to Lisp as an implementation language. Lisp is a very old programming language — among those in which new programs are still written, only Fortran is older. Lisp itself is from an age of strictly procedural programming languages. In a context like that, it’s easy to understand why lots of Lisp books tout Lisp as a “productivity-multiplying” language. In fact, the book from which I’ve learned the most about Lisp (wittily entitled “Lisp”), cites the following as a reason why any computer programmer worth his salt should learn Lisp:

Lisp facilitates procedure abstraction and data abstraction. By hiding the details of implementation from places where they’re not needed, Lisp makes it easier to think about the overall structure of a program.

In response to that, all I’m going to do is point at Java. I hate to use Java as a shining example of anything other than suck, but there it is, a language that’s actually gotten pretty widespread (more so than Lisp, at any rate) which makes procedure and data abstraction darn near mandatory.

Abstraction is the core of what programming language designers aim to do nowadays. Maybe the emphasis on abstraction is in fact due to Lisp (I can’t deny that Lisp has been heavily influential on programming language design), but that doesn’t change the fact that there are more modern, more readable, faster and better-designed languages nowadays that all facilitate abstraction just as well as Lisp. So that’s certainly no longer a reason to learn Lisp.

Back to what I was saying, the reason that such a high proportion of Lisp books seem to argue that if you’re going to learn a programming language, Lisp had darn well better be it, is that there was a time when, in fact, Lisp was the sensible choice if you had to choose one language to learn. I offer my condolences to any programmer who learned the craft during that time.

Still, though, it’s undeniable that Lisp has properties shared by no other programming language today. I can’t think of any language, even a niche one, that does symbol manipulation to the same degree that Lisp does. I’m sure they exist, but I don’t know of any other languages that allow you to selectively specify symbols that shouldn’t be evaluated. In any language that supports closures, selective evaluation can be faked, but it’s not part of their syntax. Lisp can be procedural, functional, or a primitive type of object-oriented. Lisp source code is equivalent to data that Lisp programs operate on (i.e. source code is made up of Lisp lists); this makes Lisp a sort of mind-bending meta-language over a meta-language. Of course that’s not at all useful in practice (yes, it makes it stupidly easy to write a Lisp interpreter in Lisp but it’s not much harder to write one in a better language), and it comes with the crippling downside that Lisp source code is extremely hard to read. What I’m saying is that I agree that Lisp has a laundry list of features, some of which no other programming language has, and which do not all appear together in any other language. This may sound like several points in favor of Lisp, until you realize that few, if any, of those features are at all useful or productivity-enhancing.

So why are the fields of artificial intelligence and cognitive modeling so enamored with Lisp? Certainly not because Lisp is an easy language to learn. Nor, in my opinion, does it have any features or peculiarities that make it particularly well-suited to those areas. The only option left, I think, is that code in those areas started being written back in the days when Lisp was in vogue, what with its primitive object-orientedness in the face of the rigid sequentiality of languages like ALGOL and Fortran. Back then, computing was still an endeavor restricted to academia — commercial software was not being written in earnest. This is why commercial software for the mass market didn’t become similarly locked in to Lisp by tradition. Nowadays, I really believe there’s no particular reason to write code for AI research or cognitive modeling in Lisp. Any reason there originally was (Lisp is the best language available, Lisp does abstraction, etc.) has been completely obsoleted. It’s the status quo — if you’re writing AI or modeling code, you do it in Lisp because that’s just how it’s done. And, of course, there’s so much legacy code in Lisp that it’s kind of foolish to try moving it all to another language, and of course code in a new language would be unable to interface with older Lisp code. The fact that there’s such a large AI and modeling code base in Lisp means that it’s pretty much mandatory for a researcher in either area to learn Lisp — in a sort of throwback to the old days, if you’ve got to choose one language to learn, make it Lisp. And because the situation just propagates itself thus, there’s no reason for a researcher to learn any other language.

So there you have it, my cogent argument as to why Lisp, an outdated and, by many standards, inferior language continues to be used in some areas and promoted for rather baffling reasons. I say cogent to distinguish it from any irate diatribes I may have posted or may post, probably centering around the fact that Lisp syntax contains way, way, way too many parentheses.

I’ve discovered recently that Python is awesome.

It clearly inherits from Lisp, but it does what Lisp was meant to do in a non-stupid way. It clearly inherits from Perl, but it does what Perl was meant to do in a non-stupid way. In trying to be the language-that-can-do-everything, it does not introduce stupidities or hoops that you have to jump through. Its syntax is super-clean and legible even to someone who doesn’t know the language. It’s readily extensible. You can even do GUI programming in it.

In short, Python has the highest awesomeness-to-stupidity ratio of any language I can think of. Even Objective-C has its own stupidities, most notably the brace syntax ([someObject doStuff:@"BLOP" withThis:[otherThing gimmeTheDoohickey]]) and the fact that it makes you name the parameters without actually giving you the benefits of named parameters (Python has real named parameters, BTW). Objective-C’s syntax is unfortunately reminiscent of Lisp’s, except it’s marginally more self-documenting because of the pseudo-named parameters.

Python does have its stupidities, though. Most notably, there’s no way you can have it enforce a static type discipline, which is just what you need sometimes to prevent yourself from making stupid errors. Objective-C, for all its emphasis on weak, dynamic typing, can enforce static types if you want it to. But since Python has no way of declaring variables other than just assigning to names pulled out of thin air, you can’t type variables. However, Python programs can die if you try to make them do something that doesn’t typecheck, but there are no syntactic cues. I believe strong typing requires static typing, since dynamic typing gives you the false sense of security that you can do whatever you want (like in Perl or Objective-C).

There are also times when the scoping-by-indentation gets on my nerves, but that’s what helps keep the syntax clean (as well as the lack of gratuitous punctuation like in Perl).

But where Python truly wins is in being a functional language without compromising OO and imperative capabilities. It has higher-order functions (that aren’t quite true higher-order functions, but good enough for anyone except the most hardcore theorist) without any of the idiocy that goes with C’s function pointers or Objective-C’s selectors or Perl’s code references. The scripts I just wrote in Python (which made me realize how awesome Python was, when I was able to write these incredibly clean, elegant scripts starting from barely any knowledge of Python) use higher-order functions all over the place — passing around lists of predicates, creating predicates from thin air, and it’s great.

The way those scripts are written seems, to my untrained eye, to be sort of Lisp-esque. Since I’m supposed to be learning Lisp for the same employer, I’m hoping that Python might turn out to be a sort of gateway language into Lisp. But seriously, don’t get me started on all the myriad ways in which Lisp sucks.