The coolness of my new Centro just keeps kicking me in the ass. Just now I needed to make a vet appointment for my cat. So I googled the vet clinic using the Centro's browser, and noticed that the clinic phone number was a link. With my old phone, I'd have to write it down, add it to my address book, then call it. But just for the hell of it, I clicked the link -- and the Centro not only dialed the number, but added it to the contact list with all the clinic info filled out correctly. That. Fucking. Rocks.

Ok, I'm easily impressed. But this is what technology is supposed to be all about, and seeing so much LAME tech in the world often gets me down. The Centro is... refreshing.

I'm a little annoyed that there's no way to lock both the touchscreen and the keyboard while on a call; but I'm treating that (very minor) issue as an opportunity to learn PalmOS programming.

I also wish I could justify the $40/month cost of the "Phone as Modem" feature, so I could connect to the internet from any old place. But I'd only use that, like, three times a year, so probably not cost-effective. Though it occurs to me that if I could establish an IP connection to the phone from my laptop, writing a little PalmOS app to tunnel connections through the phone (basically using it as a NAT router) might be easy.

While I'm on Spolsky, who thinks that CS programs ought to teach students things that will actually open their minds and broaden their ideas of computation, I'm reminded of one mind-broadening experience I had recently: Chapter 3 of SICP: http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-24.html#%_sec_3.5
This chapter discusses "streams", which are essentially just lazy lists. The notion that any recursive algorithm can be represented as a stream defined in terms of itself took a little getting used to. The section on sequence accelerators blew my mind.

I think SICP is a great book, in part because of stuff like streams, but also because of its whole organization: it takes the reader from a very high-level model of computation (the Scheme language), and ends up at the low level of simulation of a virtual machine (the explicit-control evaluator). This is quite different from a lot of CS texts which begin by talking about machine organization, and end up discussing some half-assed high-level language like Pascal.

I got every question right on Joel Spolsky's freshman UPenn CS exam: http://www.joelonsoftware.com/articles/TestYourself.html.

Now why didn't Google want to hire me? Oh yeah, my brain turned to oatmeal the minute I walked into the interview room :-( It's been six months, and I still have horrible flashbacks to that day. Beautiful corporate campus, amazing lunch... brain-dead interviewee. For example, when asked to write a function to remove duplicates from a list, I gave the "obvious [O(n^2)] recursive solution" -- what the heck was I thinking? Ever heard of hashtables, dufus?

Oh well, maybe I'll try again this year.

I had a very interesting experience last night: just for the hell of it, I decided to try writing a quine (http://en.wikipedia.org/wiki/Quine) in Scheme. It took just a few minutes for me to think of a reasonable approach, and it worked the first time under DrScheme (http://www.plt-scheme.org/):

((lambda (x) (print `(,x ',x))) '(lambda (x) (print `(,x ',x))))

This week I've engaged in a silly thread about quining on comp.lang.forth (archived here http://groups.google.com/group/comp.lang.forth/browse_thread/thread/ba6fe1a735c3dca6/8bee19a004b7cbcd#8bee19a004b7cbcd), in which I argue pointlessly with another poster about the exact definition of "quine". I think what bothers my correspondent about my "context-specific" quines is that it is the context, rather than the quine itself, which contains the knowledge about how to reproduce the quine's source. My position was that that is true of all quines, to the extent that they depend on external tools (such as a runtime library) in order to run. However, in a "context-specific" quine, the self-referentiality is trivial, since it is built in to the runtime environment. The Scheme quine above does not share that characteristic, although it's hard to see exactly where the dividing line is.

I recently investigated version-control systems for personal use. I didn't spend a lot of time on any particular one, just enough to absorb the general ideas (or at least, I think so). I knew I wanted to step away from CVS, but I didn't know where to go. Simplicity was my strongest desire, although I do also have some need to manage changes both at home and at a client site.

The systems I looked at:

* subversion : http://subversion.tigris.org
* arch : http://wiki.gnuarch.org
* darcs : http://www.darcs.net

Executive summary: I'm using darcs. Read the flipside for my reasons.

I've abandoned Pomo (see below) in favor of Lisp. See why on the other side:

This is my promised post on standards.

In my experiece the best stuff is designed by very small groups, ideally one or two people. Any group larger than that seems to wind up in the Swamp of Design by Committee. This explains why Python, C, and Scheme are great languages, and why the IT standards designed to support our nation's roadway automation (http://www.ntcip.org) are such a mess (http://www.kneuro.net/jk_old/traffic/).

Of course, small groups aren't a gaurantee that you'll end up with good stuff, but large groups invariably get it wrong, in my experience. Often, this is because various interests are at odds and exerting pressure on the standard in different directions; and in other cases, it seems to be more about ego.

In the couple of committees I've sat on, all related to traffic-control-device standards, there were a small number of individuals who usually got what they wanted; and technical merit was not always the deciding factor. There was definitely a pecking order among the more vocal committee members, and then there were also some individuals that stayed more or less on the sidelines and simply voted on whatever issue the others had brought to the table. The folks on the sidelines were often the ones with the best technical arguments, but it was difficult for them to get their views a fair shake, because they were often technical people (programmers, mainly), whose social skills tended to be overshadowed by the more management-oriented types. In one case, this dynamic resulted in a simple and elegant 30-page version 1.0 standard being expanded to more than 200 pages in version 2, with little practical increase in supported functionality. This was largely because the strong voices insisted that the standard had to be structured in a particular way, while at the same time many different individuals wanted to get particular features included.

Ego is a great thing; without it, nothing would get done. But it seems to work best in small quantities. An individual with the drive to build something useful, beautiful, or popular, can produce a cohesive whole. What should have been done in the above case, in my opinion, is that the governing organization should have tasked one or two individuals with the production of a coherent standard; the role of the committee would be merely to approve or reject that standard, not to micro-manage the language of the standard itself.

Doesn't everyone want to design a programming language? Maybe not; it seems a thankless task in the long run. Look at poor Bjarne Stroustrup.

But I'm thinking about giving it a whirl, anyway. I've tried to come to terms with Common Lisp (too many practical problems) and Scheme (too verbose, no macros), but I always seem to end up doing most things in Python. Python is, as Paul Graham has mentioned, one of the Lispiest of the current crop of "scripting" languages, yet it still lacks things that Lisp hackers avow are integral to the spiritual core of Lisp. The possibility of insane power lurking just out of reach is like an itch that I can't quite scratch. What I want is essentially Python, with Python's standard library and all that it implies; but with more regular syntax, and real, Lisp-style macros (probably not hygienic ones). My name for this beastie is _Pomo_:
a pun on "postmodernism", or, if you prefer, an acronym: Python On Macro Opiates.

So I'm thinking about implementing Pomo as a thin wrapper around Python. I would give it I-expressions (like S-expressions, but expressed via indentation) for traditional Python feel, yet would allow S-expressions when they were convenient. I'd provide defmacro, backquote, comma, and comma-at, and provide all of this as a Python module that can be used to parse Pomo code and turn it into Python, expanding macros as necessary.

This really sounds like fun...

I've spent the past, oh, four hours or so, in the middle of the freakin' night, absolutely captivated by Steve Yegge's rants: http://www.cabochon.com/~stevey/blog-rants/

Later.

I've been doing a lot of thinking recently about abstraction and how to achieve abstractions that can be easily tested. This is an important issue in software development, because making code easy to test is really the only way to ensure that the code will actually be tested.

I spent many years writing C++ code and doing ad-hoc testing. During those years, the code I wrote tended to have this kind of organization. That is, the application consisted of some code that implemented a tower of abstractions which interacted with one another in a layer-oriented way. For example, the top abstraction layer might be "Score", which implements an abstract interface to musical compositions; the middle layer might be "Instrument", which "Score" uses to play itself on a particular instrument; and the low level might be "MIDILayer", which handles pushing MIDI messages out to physical instruments in order to play the score. "Score" might instantiate a number of "Instruments" to play itself, and each "Instrument" would use the "MIDILayer" to send appropriate messages over the MIDI bus.

The problem with this is that, unless you are very careful about the design of the interfaces between layers, it can be extremely hard to test the "Score" class without working implementations of "Instrument" and "MIDILayer". And "working" can often mean that "Score" only works if the lower layers are fully configured for real-life operation. In some cases it may be reasonable to implement fake layers that mimic the behavior of the real layers, but on the other hand, it may not be possible. If, for example, one of the layers is a network-transport layer that uses socket handles in its public interface, or something like that, then implementing a dummy interface is probably going to be a real pain. You may say that's a stupid way to design an interface, and you'd be right; but if you aren't thinking about testing, those kinds of interfaces are all too easy to stumble into.

Within the past couple of years, I've begun doing quite a bit of test-driven development. When I need some new functionality, I try to write test code that exercises that functionality, before I start implementing it. That usually works really well, and it seems to lead to code that is considerably simpler. I have also noticed that the organization of my code tends to come out more like this. That is, the application consists of some code that instantiates some other things (typically implemented in a number of separate libraries), and wires them together. In terms of the musical example, a "Score" might create lists of "InstrumentCommands" to be executed by "Instruments", without ever itself actually touching an "Instrument". An "Instrument" might then execute "InstrumentCommands" and reply with a list of "InstrumentResults", which the application would hand over to the "Score" for processing.

In my experience, test-driven development tends to lead naturally to this "broad" (as opposed to "tall") abstraction heirarchy, because code organized in this way is a lot easier to test. You don't need to know about "Instruments" or "MIDILayer" in order to exercise a "Score" instance; all you have to do is understand "Score". This reduces the amount of stuff the programmer has to think about when writing tests, which makes test-writing a lot less complicated. But really the causation is (at least ideally) reversed: you end up with simple abstractions because you want to start by writing simple tests.

As I mentioned above, the tower of abstraction is amenable to testing, but only if the interfaces are designed with testing in mind. Likewise, the "broad" abstraction heirarchy, which already consists of easily-tested interfaces, can be safely transformed into a tower, by letting "Score" directly talk to the "Instrument" instances created by the application, etc. Once the application creates the appropriate instances of the "Score", "Instrument", and "MIDILayer" interfaces -- which could just as easily be the real deal or hollow stubs for testing, or anything in between -- those instances can call one another without caring about how they came into existence. This is essentially the "factory" pattern described in Design Patterns, which encapsulates what is possibly the most important principle of OO design: code that depends upon some interface should use the interface, but not create instances of it. That way, it's simple to use a different implementation of the interface if you need to. And test-driven development leads naturally to an architecture that embodies that pattern.

The other aspect of testability, though, is that ideally interfaces will be "narrow" in the sense that they are expressed in terms of the simplest entities that it's practical to express them with. [More later...]