I overheard an amusing comment in my team-room the other day, I think it might have been Kris Kemper who said it - “Anyone who knows Ruby On Rails has a half-done personal project that’s going nowhere”. How true. I have at-least three.

The thing is, in my mind I’m always envisioning these grand cathedrals, and even when I do start work on any one of them, I never seem to quite finish them. Or I don’t complete everything properly (or quite enough to be production-ready), and the application is never quite done.

I think it has to do with a lack of focus. I find myself thrashing between the hundreds of things that interest me, and I end up with a ton of unfinished work. I’m very much into lean software methods, and I know that all I’m doing by operating this way is creating a lot of inventory. I seem to be able to use lean and other workflow management techniques at work, but in the world of my personal projects, I seem to be at a loss.

Sometimes, it has to do with trying to get everything perfect. After all, since it is a personal project, I feel like I don’t have a delivery dead-line, so I can take the time to get it right. Which leads me down the rabbit-hole of perfection and cathedral building, with no real end. Cause there probably ain’t anything called perfection.

When consulting for our various clients, I’ve a clear idea in my mind about the compromises and trade-offs needed between design, architecture, refactoring, and delivery. And I aggressively do whatever might be needed to prod the folks along (be they developers, or product-owners) to get the thing done and into production. After all, there’s always another iteration coming up, and there’s always a next release.

So why the heck can’t I seem to do the same thing when I’m working on a nights-and-weekends project?

I’ve been busy, working on two very interesting projects these past several weeks (on the side - my current project for work is unbelievably mind-numbing). Both these projects are in Ruby and use Ruby On Rails. There, got that out of the way.

I’ve always been in search of software designs that result in a clean DSL (Domain Specific Language)… lisp style, bottom up, bring the language up to the problem, rather than the other way around, etc. What I’ve managed so far is a set of mini-DSLs in my applications. One for each module, so to speak.

And perhaps, that is the way things work in general; rather than the unrealistic goal of building *one* DSL which is supposed to capture your entire domain - build several, smaller ones, which each capture aspects of the domain.

Lisp is a programmable programming-language. It has several high-level features which many “modern” or “contemporary” languages do not. Among its features are -

* the now very common garbage collection
* language level extensibility
* true support for macros
* the now somewhat popular dynamic typing
* a special condition system (exception-handing on steriods)
* true multi-paradigm programming support
* the somewhat common lexical closures
* more

More than the features themselves though, Lisp truly encourages bottom-up programming. Finally, the programmer can build up the language to meet with the problem domain, rather than try to express the solution (broken down, using a top-down approach) in a clunky syntax which has nothing to do with the actual solution or the domain. In other words, domain specific languages (DSLs) become easy - in fact, they are a very common way of solving problems with Lisp. This is good. Even domain experts (non-programmers) can be directly involved in the “coding” using the domain-specific-language. More importantly, small changes lower in the stack can significantly improve and expand the functionality available towards the upper part of the stack (which is the DSL) - which is also where the problem at hand, is actually addressed.

Finally, even if one doesn’t actually program in Lisp at their day jobs, it changes the mental models significantly enough to make one a better programmer for the rest of one’s programming life.