Blog

The Turing Tar Pit

Or, why is the most frequently-asked question on every web programming framework mailing list, “How do I serve a static page?”

Alan J. Perlis’ epigram on programming #54: Beware of the Turing tar-pit in which everything is possible but nothing of interest is easy. Beware indeed. Abstraction isn’t free and the #1 sin of programming is premature generalization.

But that’s the fun of programming, isn’t it? Finding new abstractions, a more “elegant” solution. The rest is just implementing details. Who hasn’t invented a programming language or six on paper?

Zooming Interfaces

I really like the idea of Zooming Interfaces. I think they provide a better solution to having multiple documents/objects on the screen than the current overlapping-window pattern. The demo linked above has some pretty severe limitations, but even so I found it easier and more enjoyable to explore than a web site with a comparable number of documents on separate pages.

For a slightly wilder example, try Dasher, a keyboard replacement based on zooming letters. (The Java applet did not work for me on Firefox 1.5.0.6 on Windows.)

Ruminations on Planet Lisp

To clarify for some respondants to Voted Off the Planet: As far as I know, the decision to remove my blog from Planet Lisp was not made collectively by readers but solely by the site’s maintainer. As is apparent from comments on the announcement, some people approved of the decision and some did not, but those comments came after it had already been done. The emailed responses I’ve gotten have been uniformly positive — thank you to those people, and to anyone who is still reading.

I was never actually notified either when my blog was added or when it was dropped. I think that’s revealing: I was not being invited into the community, I was being tested. According to one person’s standards, I failed. That in itself does not surprise me. I was not ready for such a large and demanding audience. I only started this blog a few months ago, and I am definitely still feeling my way towards a writing style.

What did surprise me was the viciousness of the criticism, some of it from people who were clearly only skimming my posts anyway. E.g., I was “hassling” Planet Lisp by announcing “UFFI bindings to a C library.” Well, 1) It was CFFI, not UFFI; 2) only half of it is bindings, the rest re-implements bits of the Perl API in Lisp and translates data between the two; and 3) I said it was just for fun.

Or was the idea of embedding Perl code in Common Lisp just too heretical? ;)

But the lesson I can take from all this is that I still have a long way to go. So bear with me, gentle readers, as this page (hopefully) evolves into an interesting and enjoyable discussion.

Literally Literal

This is just an random idea that popped into my head. Tell me if I’m crazy.

Is there enough distinction between literals in code and values generated at runtime? In other words, what should be the difference between this:

x = "Hello, World!"

and this (syntax made up):

x = new String("Hello, World!")

In general, I understand literal values in code to be immutable, or at least it’s undefined what happens if you modify them. So should two identical literals be pointers to the same block of memory? Does this C code:

char x[] = "Hello!";
char y[] = "Hello!";
if (x == y) printf("True");
else printf("False");

print True? (I tried it, and the answer is no, it doesn’t.)

This gets more confusing when you can have object literals as in JavaScript:

myFriend = {
  name : "Bob",
  age : 32,
  friends : ["Jack", "Jill", "Joe"],
  talk : function(){alert("Hi, I'm "+myFriend.name)}
};

Is myFriend mutable? As it turns out, in JavaScript, the answer is yes. For an interpreted language embedded in web pages that makes sense. But what about a compiled language — is efficiency lost when values could be compiled in but aren’t because the compiler doesn’t know the value never changes? I suppose that’s the reason for all those annoying const declarations in C++, but is that a complete solution?

So my question is this: would it be worthwhile to have specific syntax for compile-time contants? C has preprocessor constants, but they’re text-based and don’t carry type information.

The Shape of Math

Consider the following simple bit of mathematical notation:

Fourth Root

the TeX code that draws it:

\sqrt[4]{\frac{x^2+1}{x-1}}

and the same thing in an S-expresion syntax like Common Lisp:

(exp (/ (+ (exp x 2) 1)) (- x 1)) (/ 1 4))

and in a typical function-call notation like Python:

pow((x**2+1)/(x-1), 1/4)

I know which one I’d prefer for doing my math homework. For a while I thought S-expressions were superior to conventional mathematical notation because they are more consistent, but that consistency is what makes it harder to read complex nested expressions like the one above. Splitting it up into multiple lines with more whitespace would help, but it wouldn’t solve the fundamental problem: linear code doesn’t have enough shape. I can look at the math and immediately, without thinking about it, say “that’s a fraction inside a radical.” Determining the same thing from S-expressions, function calls, or TeX requires me to mentally parse the code and build up the expression in my head. Maybe if I spent a lot more time reading code than I presently do I would achieve the same ease with code, but I can’t really believe that any programming language would ever be as easy to read as the math. As long as it’s linear (in some respect) code doesn’t provide enough visual information to engage the image-processing functions our brains excel at.

WriteRoom – Long Live the Console

Christian Neukirchen (A.K.A. Anarchaia) pointed out a Mac OS X app called WriteRoom (there’s a Windows twin called Dark Room). It’s a full-screen text editor with absolutely no word processing features. No bold, no italic, no paragraph formatting, just text. As the introduction says:

Walk into WriteRoom and your busy computer life fades away. The distractions of e-mail, the web, and your thousand desktop icons are gone. Only you and your text remain. This is a place where work gets done and procrastination has no place.

Very interesting, since what I dislike most about modern GUI apps is the “thousand icons” approach — every edge of the screen stuffed with row upon row of buttons, menus, icons, palletes, scrollbars, pop-up reminders, status messages, and clocks, all there to prove to you how incredibly feature-packed this amazing piece of software is. When I want to work on serious writing, I fire up Emacs full-screen. WYSIWYG is great for preparing a document for printing, but it’s incredibly distracting. In my day job I spend hours just removing formatting inadvertantly introduced when a writer hit CTRL instead of SHIFT.

What’s funny about WriteRoom is how much it looks like an old text terminal, green-on-black text and all. Maybe it really is true that everything comes back into fashion if you wait long enough.

Zeroth Post!

A Usenet posting sent me to a short article by Edsger W. Dijkstra titled Why numbering should start at zero.

Now, I have never used a programming language that wasn’t zero-indexed (like Fortran), but neither have I adopted the habit of numbering lists starting with zero.

I think the difficulty I have with zero-indexing is that in normal English we refer to items in a list by ordinals: “first, second, third, … nth.” But translated into Common Lisp, we get the slightly disorienting:

(first *list*) ≠(nth 1 *list*)

(that’s a not-equals sign for the Unicode-deprived)

Now, I understand that nth is zero-indexed, just like elt, and that’s consistent with how most other programming languages work. But then why don’t we have zeroth?

I guess the simple answer is that zeroth isn’t normally thought of as a real word, except occasionally to refer to something added to a sequence “before the first.” My Websters Collegiate doesn’t even define it. Of course, the copy I have is from 1973; Webster’s online does include zeroth. Has zeroth entered the English language because of computers?