Monday, February 1, 2010

iPad? uPad?

The question is, will I get an iPad?

Do I want one? Yes. Will I get one? Maybe. I absolutely refuse to get into the stupid details, like the aspect ratio; I'll give you a much abbreviate, and (I believe) different perspectives on the pros and cons of the iPad.

Pros:
- Verified apps

Cons:
- Separate data plan, even if you have an iPhone

In some ways, this is the perfect tool for the academic computer scientist traveler (i.e., me). I go to conferences and meetings with sponsors, collaborators, etc. I don't want to travel with enough power to do my work, as that requires a lot of disk space, memory, and processor. I need connectivity and ssh and a long battery life. The ability to edit documents locally is useful, too; I don't know that I want or need Word, but we do a lot of our writing in LaTeX, so just the ability to read, edit, and comment on PDFs is probably sufficient.

However, the one problem is that I like to work while I'm on an airplane. I actually think it's conducive to decent programming. My friend at Apple said, "it's a good thing that most planes have wireless." Huh? I travel a fair bit, and have never been on a plane with wireless. (NB: I use the wrong airlines.) I can pay for access, but it would need to be decent. I don't just want to browse the web. Actually, what I want to do is very, very low-bandwidth (programming, etc., on remote servers). I would need my organization's VPN to work, too.

So if I'm on a plane, I can't really get any work done with the iPad, except maybe reading and editing papers. Right now, that's not sufficient.

Once I get to the conference, it would be ideal for taking notes, keeping up with email, etc., so perhaps, perhaps, perhaps.

More Python Woes

So I had a bug: I had a method on a class that had lost its indent (I love that academic/APA style allows one to avoid assigning credit or blame).

The error I got was that the interpreter couldn't find the attribute. Attribute? It's not an attribute, it's a method. I knew it wasn't a method signature problem, as I had checked the name, and if you have a mismatch in arguments, then you get a different error.

However, the method was clearly a member of a class, but the "compiler" didn't notice that it referred to self, even though it was a top-level function (not physically in the class). Why doesn't the compilation routine notice these kinds of errors? I really do like compilers, because I make mistakes. I'll take this chance to tell a favorite anecdote.

I spent a great deal of time, as an undergraduate, in the UPL (Undergraduate Projects Lab) in the CS department at the University of Wisconsin, run by Professor Barton Miller. One day, there was a heated debate about preferred debuggers between some acolyte programmers. The acolytes asked the guru-in-residence (one of three great programmers I know), whom we'll call "Mitch" (because that's his name), "Mitch, what's the best debugger?" Mitch replied, "I don't write bugs. I got over that."

Now, you're ready to call this either braggadocio or just plain bull, but there's a codicil anecdote. A few years later, I was talking to Mitch, and he was in a bad mood. I asked him what was wrong, and he replied, "I wrote a bug."

Anyway, I write bugs. I'm a decent programmer, perhaps even good, certainly not in the stratosphere. There are three programmers I put on a pedestal, but many, many better and more diligent than I am. So I like things that catch my bugs. Python does not do that.

You might argue, at this point, that it's a minor detail, and that if I were a better programmer, or more versed with/experienced in python, I wouldn't have had this problem (which admittedly, once I figured it out, was easy to solve). You are right on the latter count, but I would argue that it's a major detail. Yes, a detail, but an important one.

In the OO world, we deal with classes, objects, methods, and attributes. These are the quanta of our product. For a language to not notice that a method does not belong to a class, well, that's a static analysis issue, and it should be done. One of the lovely things about java is that it does an excellent job with static analysis (for the most part) at compile-time. You cannot have a method that doesn't belong to a class (love the valid use of double negatives). If you want a method to operate on the class, rather than an object, you have to specify that explicitly, with the static keyword. Arguments and variables are checked; you can't access an object variable in a class (static) method.