Tao of the Machine

First impressions

The SGI box arrived today. I haven't been able to do much yet. I really need a separate monitor for it; this one kind of works, but I need it for the Windows box, and it doesn't has the so-called "sync on green" feature. This was known and expected, by the way. Someday I'll pick up a cheap monitor somewhere.

The good:

I don't know yet. Well, the computer looks pretty. :-)

The bad:

Apparently it's not possible to make a direct DSL connection with PPPoE. All the system seems to know about is PPP for modem or ISDN. Both require a phone line; I want to use the Ethernet card. Once the SGI has its own monitor, I will try to share the DSL connection between Windows and SGI, like I did with the Mac. That better work, because a network connection is the only way I will be able to store things (considering I have no zip drive, CD burner, floppy drive...).

There's more. The CD-ROM doesn't open by itself; pressing the little button does nothing. You have to select 'eject' in the OS. Also, it doesn't seem to read other CD-ROMs well... it chops off names to 8x3. Of course, all this could be because I don't know what the hell I'm doing. :)

The ugly:

The OS looks *old*. It looks like somebody took Windows 3.1 and changed some stuff around. Nothing like this. I can't really judge though until I have a better monitor, the current one displays everything in green. :-) I don't mind really, but I thought SGI machines were known for their excellent graphical capabilities. Then why does it look like Win3.1 with 16 colors? Something to figure out.

I consider this kind of wrestling with a new system to be normal. Even if nothing else works, I can still use it to learn some Unix stuff.

The unknown:

Pretty much everything else. I don't know the Irix version (presumably 6.5.x); I don't know what software is on it; etc. Time for me to collect lots of IRIX info on the Net. If anybody has any pointers, other than the obvious (sgi.com etc), I'd be most grateful.

IDEs and editors

Kasia Trapszo: Ode to Windows programmers. Looks like somebody had to develop on Windows and didn't like it. :-) Interestingly, the programming environment that she worked with is Delphi 7, on Windows 2000. That's what I use, *if* I use Delphi, which is not a lot these days.

For Python, I now use a homebrew editor, called Charm. Lately I've been wondering about the drawbacks of using IDEs. One obvious problem is that you're "locked in"; as soon as you are in an environment that doesn't have this IDE, you're in trouble, because nothing works like you're used to.

It is also against the Unix philosophy. Now, this philosophy is not holy scripture, especially not on Windows. ;-) Yet important things can be learned from the Unix model. IDEs violate "small is beautiful" and "make each program do one thing well", by attempting to integrate editor, GUI builder, compiler, linker, debugger, you name it. Charm doesn't go that far, but I've been wondering if it would not be better to use a pure editor again (e.g. vi). Charm requires wxPython (and Wax) and doesn't run everywhere; vim pretty much does. Using an ubiquitous editor enables me to edit (source code) anywhere, with the key mappings and settings that I'm used to (assuming I can copy or move the .vimrc file). Using Charm pretty much restricts me to Windows.

I'm taking my own editor as an example here, but it's just as true, or more so, for other (commercial) IDEs, like Delphi, Komodo, Visual Studio, etc. What do I use on IRIX? None of the above, and probably not Charm either. But vim and emacs are available. The same is true when I'm on an old text-only Linux or DOS box.

It would be really nice if vim supported tabbed editing, though... the fact that it doesn't was actually one of the main reasons to write Charm. Or, I have to train myself to have fewer file open simultaneously... but this is of course a threat to my code's modularity. ;-)

Space cadet keyboard

I always thought of the PS2 controller as revolutionary and elegant, with its square, circle, triangle and cross. Elegant it still may be, but revolutionary it is not. Check out this so-called space cadet keyboard that came with old Lisp Machines. (See also here.)

A Lisp Machine seems like a cool thing to have. Maybe not so useful anno 2003, but still cool. Ebay, anyone? :-)

Update. [Chris Ryland] Also see this page.

New Firedrop macro: mkchar

Test test...

Die Ärzte, Curaçao, hasta mañana, meeëter, Português, København, Linköping, ½ + ¼ = ¾, Århus, © 2003, à la mode; fünfzehn, fleißig, ...

Special characters in HTML are nothing special. :-) However, I added a module to Firedrop that converts simple text to these HTML characters. For example, A: translates to Ä, C, to Ç, e' to é, etc. (Or rather, makechar("A:") translates to "Ä", etc.) This is inspired by vim, which has a similar feature; you can type, for example, A, backspace, and ' (apostrophe), and the resulting character will be Á. (Assuming your font supports it, of course.)

The makechars.py module (which allows for this mkchar macro) will be available in the next release of Firedrop.

Flavors

For a while I have been interested in a specific dialect of Lisp, called ZetaLisp, and the OO system that came with it, called Flavors. I couldn't find any detailed information about it on the Net, though... until today. Here's the old Lisp Machine manual (by Moon, Stallman and Weinreb); chapter 21 describes Flavors. (Note that this is the MIT Lisp Machine, not Symbolics.)

Interesting stuff here. I wonder if ZetaLisp implementations still exist (being available for modern systems, that is). Some remarks:

Design by contract is a concept usually associated with Eiffel... but this manual (from 1984) already talks about contracts.

The contract from ship to its callers only speaks about what happens if the caller calls these functions. The contract makes no guarantees at all about what would happen if the caller were to start poking around on his own using aref. A caller who does so is in error; he is depending on something that is not specified in the contract. [...] This example shows why the concept of a contract between a callee and a caller is important: the contract specifies the interface between the two modules.

ZetaLisp's attitude in this respect is much like Python:

Unlike some other languages that provide abstract types, Zetalisp makes no attempt to have the language automatically forbid constructs that circumvent the contract. This is intentional. One reason for this is that the Lisp Machine is an interactive system, and so it is important to be able to examine and alter internal state interactively (usually from a debugger).

Maybe all Lisps or Lispy OO systems do this -- I wouldn't know. Another feature, which may be common as well, is that defstruct seems to use some magic for attribute names:

(defstruct (ship :conc-name)
  x-position
  y-position
  x-velocity
  y-velocity
  mass)

(defun ship-speed (ship)
  (sqrt (+ (^ (ship-x-velocity ship) 2)
           (^ (ship-y-velocity ship) 2))))

After defining the ship object, ship-x-velocity and ship-y-velocity are suddenly defined as well. ¹) Again, maybe this is a common technique in Lisp, I don't know (yet), but it certainly isn't common in Python, so I mention it for the sake of comparison. (Then again, in Python you can abuse __getattr__ and __setattr__ for attribute magic...)

Read these documents. They're worth it. And they lack the arrogance that sadly is common among some modern Lisp proponents.

¹) I first thought this was part of the Flavors system, but it seems to be independent from it. Flavors would use the defflavor and defmethod constructs.

Exceptions vs status returns

Here's what some people write on the subject... Joel Spolsky, and Ned Batchelder.

I'm definitely in the "exceptions" camp. Status returns are not evil, and in some languages they are the only option (C, for example). The problem is that they don't play well with modularity. If you want to break up your code in lots of little pieces (modules, functions, objects, methods, you name it), then it's a pain if you have to pass status returns through lots of different layers. It doesn't make modularity impossible, but it certainly gets in the way.

Using status returns in a language that has exceptions is worse, though. You're setting yourself up for trouble. Imagine that I want to open a file in Python, but I want to use status returns rather than exceptions. That means I first have to catch all possible exceptions, then translate them to status codes (which I probably have to make up first), and return that. If you oversee an exception, your code becomes quite unreliable, because you won't catch it elsewhere.

Then again, there are large gray areas. When to use exceptions, and when to use status values? When you search for a character or substring in a string, and it's not found, is it better to raise an exception, or to return a value? Python has both (string.find and string.index). (Interestingly, for lists it only has index, which uses exceptions.)

In general, exceptions seem clearer, though. If I try to open a file that doesn't exist, the resulting exception will tell me exactly what's going on. With status returns, I first have to figure out what the status means. Exceptions also give you a choice when to handle the error. Maybe you want to handle it when you call the exception-producing code, or maybe you want to handle it somewhere else entirely. In GUIs, it's not uncommon to catch unhandled exceptions in the highest layer, then display the traceback in an error window.

Oh, and I also think that exceptions are not like gotos... they're more like come froms. <0.3 wink> Consider:

try:
    some_code()
except FooError:
    # if we're here, then we came from a place that
    # raised a FooError

Hmm, it's Intercal all over again...

Underrated games

(via Dutch Guy Speaking English) The 25 most underrated games.

I played some of these games. #23, Blood, is very good (although also very gory). It's DOS, so it doesn't play well on Win2K; I should give it a try with DosBox. As the review points out, it has ludicrous weapons, and well-designed levels. A bit like Rise of the Triad, although that wasn't as funny, and the opponents were less interesting (although I remember flying monks? :-).

#1, Ico, is excellent indeed. I like it; so does Jessi. :-) There are rumors about a sequel, we hope that it will be out soon.

#14, Zork Zero, seems interesting. Let's see if I can pick it up somewhere, someday.

#10, Wheel of Time, sounds fun when you read the review (using ter'angreal and all that), but I don't recall it being very good. One of my pet peeves is that I *hate* dark games. Dark in the literal sense, meaning, without very much light. :-) I can't see a damn thing, and cranking up the gamma rate doesn't help much if the world simply doesn't have much light to begin with. But maybe I should give it another try. I can be flexible, e.g. playing in the dark...

One underrated game that isn't on the list is Touche, aka the Adventures of the Fourth Musketeer (I think its full title was). It's a point-and-click adventure in the spirit of Monkey Island. Hmm, and Broken Sword for the GBA was good too... and Ultima Underworld... maybe I should do another week of game reviews.

Dear Mr. Sniper

I almost sent this letter to an Ebay user...

Almost. That guy will probably be pissed off already because he didn't get the item; I doubt he will be able to appreciate my remarks. So it seemed wiser not to send it. :-)

In other words, here's what happened: My bid on this SGI O2 stood for a few days, unchanged, and when I checked 35 seconds before the end of the auction, it was still the same. 2 minutes later I checked again, to discover that suddenly the item price had risen by $30, because of a sniping attempt. Fortunately, this still fell within the bounds of my maximum bid, so the item is still mine. Except, now I have to pay $30 extra, just because some [expletive deleted] had to bid for it at the last moment.

Personally, I find this bidding behavior highly unethical. I think it's in the same category as exploiting lag in an online game. Not everybody thinks so, though; there are lots of tools to help you do this. ("We snipe so you don't have to?") This is really an online phenomenon; real-life auctions don't have this problem.

One way to combat it would be to do away with visible starting and ending dates entirely. That way, you cannot intentionally wait till the last minute and then try to outbid the current high bidder. At some time the auction will end, but nobody can use this knowledge to their advantage (and their competitors' disadvantage) anymore. Fair. That's what an auction is all about.

But back to the SGI. I have a curious set of expectations about it:

• it is capable of eventually replacing my Windows box as my computer of choice for hacking. ¹)
• however, it will probably not do so anytime soon.
• in the meantime, I'll try to slowly learn about the machine and make it suitable for my purposes (e.g. attach it to a network, etc).
• my goal is to run at least C, Python and a Lisp dialect on it.
• i might have to get additional hardware, like a monitor.
• if nothing else, i can use it to sharpen my (admittedly lacking) Unix skills.

Hopefully it will be a less frustrating exercise than with the Mac. (Cheaper, so far. :-) SGI/IRIX occupies of course an even smaller niche than Mac OS X, but maybe that helps keeping my expectations low. It also is a hacking challenge: if something isn't available, it makes sense to write it. (Or maybe port it, but that seems a bit more painful.)

¹) Hacking in the Jargon file sense of the word, of course. I shouldn't even have to explain this. :)

Another reason

There is a good reason why I, as a programmer who mainly uses Python, the programming language where identation (which can be tabs or spaces, but mixing them, like some people used to, which was apparent from a survey in comp.lang.python, the official newsgroup (Usenet, that is, not one of those new-fangled web forums that pop up everywhere these days) for this language, is discouraged) is significant, for his daily work, don't use Lisp.

One quote to bind them all

As seen in the Python/Lisp thread in c.l.py... this quote pretty much summarizes the general attitude of a certain language's users. <0.1 wink>

Eight years to do TeX? How smart can he be? He should have used Lisp.

--Kenny Tilton, on Donald Knuth

(original post)

This is one of the reasons that holds me back from studying Lisp and using it more. Maybe I'll start using it for some tasks, but in secret. ;-)