More T, Please

I should probably explain why I’m so fascinated with functional programming languages like Lisp. You should know that I’ve never really shipped a product using one, I just like to think that it’d be a nicer experience than shipping something written in C++ in one of today’s programming environments.

[I used to think that a registry of name-value pairs would be a good idea. That was years before my dealings with the horror, the utter, black, unutterable dispairing horror of the Windows registry. Likewise I could be utterly naive about using Lisp or something like it. But it’s nice to fantasize and criticise the existing crap. Onward.]

Programs as data. Languages like Java and C# have introspection (and C# has user-definable attributes), which allows the running program to dig into itself and make decisions (“Ah, I’ve got two inline wheels today, I’ve probably got bicycle-nature.”). But it’s not totally wonderful, the metaprotocol for getting at the information still reflects the baroque nature of the syntax.

It’s possible to generate code on-the-fly for incorporation into the running system, but this is generally seen as something dodgy. But there are situations where this is perfectly reasonable (most often in development, to foster quick turnaround).

When you want to do static manipulation of programs — and who doesn’t do this in a large project? — you’re up the creek. Parsers for C-like languages are pages and pages long (a good C++ parser is probably on the order of 50-100 pages). If you want to write tools that manipulate programs, you’ve got a lot to worry about.

[What kinds of things might you want to do? Well, query tools on programs: “Find me all local variables of type X,” since you’re about to change type X and you want to estimate your modification’s impact. This should be a really simple question to ask, but most development environments can’t handle it, or if they do, the answer gets stuffed as text into a dialog box somewhere, where another program can’t get at the data, thanks a lot.]

Macros that Make Sense. There are a lot of reasons to deprecate the standard C preprocessor, nearly all of them good. You can extract a lot of power from simple expansion and stringization, but you can’t do general purpose computation, and you can’t debug the expansions short of the moral equivalent of “printf debugging”.

The less we say about C++ templates, the better. I limit it to this: For some reason, my brain has associated templates and HP Lovecraft’s novella At the Mountains of Madness. Maybe I was reading a book on templates and some old Lovecraft the same day, once.

I look at Lisp-style macros, and I weep. They’re structured, they’re hygenic (meaning that you don’t have formal parameters tripping over each other), they’re trivial to write.

Post-Facto Modern Runtime. I have news: Lisp got un-slow in the 80s. You can reasonable expect its memory management to compete with Java or C#’s garbage collection, and decent compilers are available. [You probably can’t use straight Lisp for an embedded system … but if you’re using anything but C for a small target platform, you’re probably losing left-and-right anyway].

* * * *

I do have some criticisms.

You need a decent editor to help you indent your code (or else discipline). This is the most often voiced (or maybe just the first expressed) objection to the family of Lisp languages, that getting all of those parenthesis correct is a nightmare. I attribute this to “forced feeding” by most colleges: Exposure to Lisp as a problem set to be solved in some survey course, rather than as an environment for getting work done.

I honestly don’t know if CLOS is a great thing or not.

Memory footprints are probably not totally wonderful. They are comparable to Java or C#; not great for the masses, unless you take a stripped-down approach.

It can be hard to excise your application from the development environment, if you want to shrink-wrap it. (Smalltalk, my other favorite language, has this problem too). The boundary between application and tool is blurred, and again you need to have discipline. On the other hand, this is probably no worse than “DLL Hell” and the “Nightmare Installer from Heck” on Windows platforms.

* * * *

I would seriously consider a stripped-down Scheme (or something like it) as an embedded system scripting language, rather than “super emasculated mobile Java” (which is still probably 100K of stuff). Mark-and-sweep collection in a small heap has been demonstrated to work well, debuggers are pretty easy to write, and bringup time for such a system would be a fraction, probably a miniscule fraction, of the time to bring up a Java or C# system.

I guess the problem remains that most engineers just don’t like Lisp.

As the guys who did Viaweb said, “An advantage that your competition doesn’t understand is the best kind.”
[Somehow we’re back to Paul Graham again 🙂 ].

This entry was posted in Uncategorized. Bookmark the permalink.