Thoughts on Lisp and Rails

There has been a lot of buzz about Lisp and Ruby on Rails lately. Hell, just the other day, I managed to compose a post extolling the virtues of Rails, especially in comparison to .NET. However, I am coming to a realization about these two. I will try to articulate that realization to you.

Rails first

Let's start with Rails, since I'm more familiar with it. David Heinemeier Hansson has evangelized it, many have talked about it, including myself and Steve Yegge has even copied it. It promises faster and cleaner web development. It promises to release you, the poor web developer, from the chains of idiotic frameworks and languages. It includes an ORM to abstract the database, a templating engine to abstract the front-end and many more things. And, as far as I am concerned, it lives up to hype. Sure, there are compromises and things that could have been done differently, it gets knocks for its performance, but all those issues can be solved or, at least, worked around.

However, I will not recommend it to a novice web developer. That may sound counter-intuitive at first, but if you think about it, it makes sense. The abstraction that is so useful to someone who has been in the trenches of .NET and PHP is DEADLY to a novice. Black magic will remain black magic and the novice will not learn how things work.

Only after you have felt the pain of connecting to databases from more than one language, dealt with ASP.NET's idiotic Server/User Controls system, seen a page with a 6 MB ViewState, tried to build your own abstractions in PHP where the requirement was that you need to connect to either MS Access or MySQL and more can you appreciate and understand the Rails. If you start with Rails and get used to its magic of scaffolding, you are in serious trouble as a web developer. Scratch that, you will be fine as long as you don't run into problems. But, at the sight of the first problem, you are screwed.

That's why I usually tell novice web developers to start out with preferably PHP, but in worst case with ASP.NET. There are still free tools available for .NET and PHP is obviously open source. Once the novice has been put to hell on several fairly complex projects, managing database issues, debugging application code (especially PHP, since there's less integration than ASP.NET), as well as any AJAX-related issues, then we can talk about using Rails.

Rails, in my opinion anyway, is for experienced developers. It's for people who are sick and tired of battling the programming language and framework limitations and would like to simply work on getting the site or web application launched. These professionals already know how the process works and they find that current technologies impede them. They spend more time trying to work around limitations of the framework/language in question than solving problems. Rails makes it easier and more fun.

Novices would get the fun part, but would learn nothing more than to rely on Rails' magic. That's not good.

Don't forget about Lisp

Paul Graham loves it. He loves it so much, he evangelizes it. Steve Yegge swears by it, especially Scheme and eLisp (the Emacs implementation of it), although he doesn't peg it as the Next Big Language. I haven't delved too much into Lisp to confirm or deny the gospel.

I do understand, after extensive reading, the potential power in Lisp. I'm actually excited to find the time to learn it. Practical Common Lisp may be the way forward. There are a few nice projects that let you learn the language while creating something. This is in tune with Rails. Hopefully, it will be as fun working with Lisp as it is with Rails.

Secret projects abound.