And that was a year

Alan

My son turns one year old tomorrow. Boggles the mind. Feels like he was born yesterday, or last week or something. This should explain pretty well where I’ve been lately. He’s a cute kid, and incredibly photogenic and well-behaved. My wife and I are really lucky.

But, yes, he’s turning one, and my wife wishes he was still a cuddly tiny ball of joy, and instead he’s now a giggling toddler. This weekend, we’ll have everybody and their brother’s uncle’s cousin’s nephew’s former roommate dropping by for his birthday party. Gifts have already started filling the hall, and I’m getting this weird feeling that I don’t own the house anymore, even though my name’s on the mortgage. The place is gonna be a madhouse, but the kidlet’s gonna have an incredible first birthday party.

SpaceMonger

Sales of SpaceMonger 3 are continuing nicely, courtesy of my friends at EdgeRunner. It’s really nice to be able to sit back and think about the algorithms instead of the business model. Some time between SM 3.0 and whatever the next really major version is (3.5? 4.0? I’ll leave that to EdgeRunner’s branding gurus), I’d really like to rebuild SM’s scanner from the ground up. The original design was decent, but I’ve had a better model in my head for years that would make its already-quick scanning even faster. The new design uses crazy stuff like lock-free queues, and functors as messages, and sector-ordered scanning to avoid head seeks, and would be awesome, and that would open up a lot of interesting possibilities for the future for things like persistent scans and automatic background scans — if I could find the time to code all that.

Those features are something I’ve wanted to do for years, really: The biggest issue that SM (and all its competitors) has is that you have to wait for it to collect your data. Unlike the competition, as soon as SM’s collected the data you can see it and start working with it (I spent nearly a year of my life deriving that instant-treemaping algorithm!). But you still have to wait, and waiting’s annoying. Human time is too precious to spend it waiting. I have a lot of really neat ideas about how to cut down the wait time, and maybe with any luck I’ll finally get a chance to build them.

That said, I have a one-year-old kid.

So I’ve spent a total of like four hours out of the past three months coding. Nearly all the rest of my time is either work or family. Or, in some cases, both. I’m glad EdgeRunner is covering the service and support; they’ve done a good job when I couldn’t be available. So it might be a while before I can build that new high-speed scanner for SM, but it’s on my list of “really great things I’d do if I had insane gobs of time.”

Smile

I did manage to get an evening to continue working on Smile. I lurvs my little programming language. It’s such a pretty thing. It’s simple and elegant, very minimal in a Lispy Smalltalky kind of way, dirt-simple to understand, and scales startlingly well. Back in June/July, I converted over a lot of the functions and methods I’d originally written in C# into pure Smile. It’s interesting that the language has grown strong enough that you can implement a lot of its own primitives inside it.

That said, the current interpreter is craptacular, and that (and documentation) is the main reason I haven’t shared Smile with the rest of the world yet: I don’t want people getting a bad impression of Smile just because the first interpreter is — let’s say “clunky.” Like any good Lisp, Smile has an [eval] function at its core, and that first implementation of [eval] is — very literal. It’s a very traditional Lisp [eval], simple and recursive, designed for the needs and structure of Smile, but still recognizable as a derivative of McCarthy’s original: It recursively walks the expression tree, a node at a time, reducing the expressions and applying parameters to functions until nothing is left, and then the program’s done. That’s fine for a proof-of-concept, but it’s slow enough to make Ruby seem like a speed demon. And it means that a recursive Smile function can blow out the stack after only a few thousand recursions, which is Not Good.

So I’ve been spending a bit of time reengineering it, doing it a bit more cleverly this time. The goal is to JIT-compile the S-expressions (cons cells) down to a pseudo-byte-code, with proper tail-recursion support, and ideally with some automatic type proofs to optimize functions by pre-realizing their types where possible — and if you know what all that means, you know it boils down to a long-winded version of “do a lot of nasty math to make it go a lot faster.”

And that said, because Smile is actually a Lisp (ssh, don’t tell!), I still have to try hard to keep the power intact: I want a future version of the language to support some kind of first-class macros (non-hygienic; hygienic macros seem really overrated), which Paul Graham rightly argues are a core of what distinguishes Lisp from everything else. And I’ve been seriously looking at call-with-current-continuation, which I think is the greatest thing that has yet to hit mainstream languages. Call/cc continues to amaze me at all the things it can do and can be: Non-local gotos, shared multithreading, coroutines, try/catch exception mechanics, loop escapes, callback simplification, promises, and so much more. Other languages are working really hard to add those features piecemeal (I’m lookin’ at you, JavaScript), but I’d really rather see call/cc implemented natively so you can do the rest of it as libraries. And yes, I know that has nasty implications for the stack, but if we stuck only to language features that are easy to implement, we’d all still be coding in Fortran 60. The two of those features together — macros and call/cc — impose severe restrictions on the compiler/interpreter/whatever, but I don’t want to be stuck in the future such that they can’t be added, because they definitely belong. Smile’s all about bringing Lisp Scheme Smalltalk Self a lot of theoretical computer-science power down to the masses in an easy-to-use package, and if I can’t have the great features that make the computer-science languages powerful, to a certain extent, it defeats the point.

Hah, look at all those rambly words up there. You totally didn’t read that wall of text, did you?

tl;dr: Work-in-progress is a work-in-progress. Kinda sums up my life, really.

And if I add these ten words, there’re 1,111 of them.