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.

Rails and I

This is absolute craziness. I cannot stop thinking about development in Rails. I work with .NET in my daily job, but Rails has occupied every other piece of my spare time. Now that I think about it, this is how web development should be. Now, I know that sounds like a fanboy-ish thing to say. Maybe you're right, maybe not.

My current job requires me to spend time in .NET 1.1. Before that, I had to work with .NET 2.0. While the latter is much better at helping out the web developer, it does not compare to Rails. Of course, all of this is documented elsewhere, so I want to just share my experiences.

Views to the max

The simplest example I can think of off the top of my head is building views (HTML ones, not database views). While Rails has a fairly well laid-out convention on how to build a view of data, such is not the case in .NET, especially 1.1.
I've recently had to learn a new data model, as well as re-introduce myself to 1.1 and I was shocked at how hard it is to set up a simple view in ASP.NET 1.1. While I was mucking around with DataGrids, DataGridItems, manually setting up DataSets, etc., I reflected on how easy it would have been to do this in Rails. Hell, I would have appreciated just the ORM part of it, if not the conventions and the MVC way of doing things.

Of course, a lot of this is the environment. Where I currently am, there is an over-reliance on stored procedures. I am not against the stored procedures per se, but if I see a 3 line SELECT query being bundled into a stored proc, I lose my mind. Not to mention that the 3-line SELECT query gets its data from a database view which consolidates a myriad of database tables. Even a query that simple takes over 5 seconds to run. UGH.
When I think about it, I come to the conclusion that these people NEED Rails. You see, since Rails enforces a default way of doing things, it's harder to f**k things up. Not impossible, mind you, but harder. There may be a bit of flexibility lost, but when I look at where the unconstrained lead developer's mind can take me, the misery it can cause me, I'd actually love to have him constrained to a set of conventions.

I love templating

Templating, is to me one of the most important features of Rails. Again, speaking from experience, whereas .NET 2.0 has a template engine of sorts, it doesn't compare to Rails. As for .NET 1.1, well........put it this way, I've seen what a programmer can do when he needs a feature and thinks he's smarter than the people putting together a framework. Again, lack of standardized features within a web framework has caused someone to go off the deep end (and I mean, the deep end. This guy has managed to bypass how ASP.NET operates and replicate its rendering capability, all for the sake of having a template for web pages. I shudder every time I think about it.).

Can you say, Javascript integration?

JavaScript integration rocks in Rails, as well. Now, where I am currently, there is no such thing. The "template" created by someone here has the path to a JavaScript file hard-coded. Now, I'm not talking about a relative path, no, I'm talking about a nice absolute one.

However, I do have experience trying to integrate a JavaScript library at a previous position. Back then, we used a very early version of the Dojo JavaScript library (0.2, I think). Huge thing, this library. Also, our "clever" lead dev decided to freeze the library at that version, though as it matured, the Dojo library/framework really came into its own. That is beside the point, though. We experimented with different AJAX libraries in order to get the desired functionality. All of the libraries we tried (AjaxPro, Anthem.NET, even Atlas) did one thing good that the others didn't. So we ended up with 3 of them. Dropping Dojo into the mix to have file uploads without having to refresh the entire page, plus using its effects features, caused havoc, as it could have been expected. This is what impresses me about Rails. The core developers of Rails managed to integrate a fairly full-featured JavaScript library, AJAX-enabled and all, into Rails in such a seamless way that one does not need to think about whether or not JavaScript calls are going to work, but rather how to use this wonderful JavaScript library to his/her advantage.

Conclusion

Of course, there are whole lot more features that I have not covered here. As soon as I learn Rails more deeply and have a chance to compare its implementations to other frameworks/technologies, I will write about it.

Until then, I hope that you enjoy using Rails as much as I do. And if not, well, it's your loss.

Really.