Time keeps on slippin’

Well, that was a quick month.

So what’s happened? I’m a married father with a baby, so family eats up a lot of time. And there’s that full-time employment thing I do most of the week. And a secret project I can’t tell you much about but that you’re gonna love (psst, that link’s not a link yet :-P). And yard work, and chores around the house; with spring comes mowing and mulch and weeds. We also had our basement flood when the big rainstorm came through last week, and pumping out that water and cleaning up afterwards was just loads of fun.

But you probably don’t care about all that; what most of you in reader-land care about is Smile, this suddenly-notorious little programming language I’ve spent so much of the last decade-plus thinking about and working on. So let’s talk about that.

I’ve been busily shoring up the implementation of the interpreter, trying to knock out bugs and fix issues, getting it to the point where it at least parses and executes the whole language correctly, and is a full implementation of both the core language and the base-level libraries. I’ve also been writing documentation, lots and lots of documentation, so that when you do get your hands on a copy of it, you won’t just throw your hands up in disgust and confusion, and you’ll be able to learn it and try demos and look up answers when you don’t understand things. This has been a lot of work, to put it mildly, and there’s a lot more to go.

I’m pleased to say that my friend Ben at work has joined me with helping test the interpreter, proofreading the documentation, and writing sample programs. It’s really neat to see other people making Smile do cool things, and his involvement has helped a lot to knock out problems before they really become problems. He made a neat little Smile program the other day that cranked out the Mandelbrot set as ASCII art, and some variant on it will definitely have to be one of the standard sample programs.

Ben’s also been a great victim guinea pig volunteer to see if my grand experiment is viable, my experiment to see if it’s possible to have a functional, minimalist language that is comfortable for “ordinary” programmers to work in, my experiment to see if someone who knows programming well but who doesn’t know Lisp or Smalltalk can feel comfortable in a functional language that is really a refined mashup of the both of them, their parentheses and brackets crammed into a blender and left on the purée setting for about 15 years. He’s been enjoying himself a lot, and still has yet to grok how deep the cons-cell rabbit hole really goes, which I think is a good thing because it implies my experiment may have succeeded, at least with one user.

To make my life just a little more entertaining, I’ve been dogfooding the interpreter. The Smile website is built using it. Not PHP, not Perl, not Ruby, not Python, but Smile itself is going to drive the Smile website from the get-go. Initially, the interpreter is just plain too slow to generate pages in real-time, so programs written in Smile generate the static HTML for it in advance. But dogfooding has helped make sure stuff works as expected, and I’ve knocked out a lot of bugs in the interpreter this way. Not all of them yet, but a lot.

(Also, don’t expect to see a lot when you click that link for the Smile website. There’s actually quite a lot there, but it’s all at URLs that are hidden from public view. All will become accessible in good time.)

I’ve also learned from this that Smile is really really good at building websites; the programs are half of what I’d write in Ruby, and a quarter of what I’d write in PHP, and really easy to read and write. I suppose it makes sense that it’s good at websites, since my day job involves building websites, but there’s not much in Smile specific to the web: I started on the principle that Smile should be really good at managing complex data structures and really good at munging strings, and those two abilities just translate well to the needs of websites. Smile may not catch on anywhere else, but I’m itching to have a faster interpreter so I can at least rebuild some of my websites in it (like maybe this one). I do have a lot of plans for how to make the interpreter fast instead of its current dead-turtle-stuck-in-molasses-in-January, but I can’t really start optimizing it until I’ve finished at least one full implementation, so the public can begin learning about and playing with my shiny toy.

On that note, I know there are those of you who want to give Smile a spin, but I don’t want to open it to the world until it’s refined and ready. Its concepts are weird, and some parts of it use untried, new techniques. The grammar is LL(3) with lexical hacks, complex precedence rules, and some semantic heuristics, and probably would have been more easily expressed as a PEG, but it is what it is. The variable-declaration and operator parsing rules are unlike anything I’ve ever seen before in any language, including Smalltalk from which they ostensibly derived. (That all may sound really scary, but you don’t have to know any of that to use it: Those fancy words just mean that the language is really good at knowing what you meant without you having to spell out many details.) Because of all that newness, it’s important that I get all the details nailed to the floor and documented, so that would-be early adopters don’t get a sour taste from it and discard it: I want to get it out there, but I don’t want the years of hard work to go to waste and people to poo-poo the new language concepts just because there’s some random bug in the first public release of the interpreter.

So, well, anyway: Lots of bug fixes, lots of implementation work, lots of documentation work, lots of testing, and lots more to go before a public release. But we’re getting there, slowly.