Ruby vs. Python on Domain Specific Languages

As I get more and more into the Rails Ruby thing, I’ve thought of a bunch of comments.

One that recently pushed me to the ‘blog about this’ limit is the discussion of Domain Specific Languages or DSLs.

There appears to be a lot of interest in building DSLs in Ruby. When you read some of the papers, it becomes quite obvious why Python is going to miss this boat. It also explains some of the difficulty as to why some DSLs that I did in Python didn’t take too well…. The whitespace indentation. If you are open-minded and you can get over that hump, you will eventually appreciate Python’s take on the problem.

But how many open minded people… or programmers are out there? By my count… not a lot. Everybody, including me, has blinders on. It’s provable as well. You hear some new programmers gush about Ruby as such a great language. Yet the language is 10 years old. Why is the phenomenon so recent? It is because programmers tend to be into fashion (surprise) just like everybody else.

So, how does this get back to the DSL problem? Simple. Python is the only reasonably successful language to attempt the whitespace is ‘really’ significant tack. Yet, this is a major piece of friction for newcomers, religious non-python programmers, and even python people who are working with other programmers (read TABS). It is also a huge piece of friction when it comes to implementing a DSL. Every attempt at doing a templating language for HTML, for example, has ended up looking a lot like something that isn’t Python. When I used the clever ‘eval’ trick to have Python become my configuration file language… the users hated it. This is a real problem for Python.

Ruby, on the other hand, is easy to use as a DSL platform. You don’t get burned by whitespace. This is one of the key reasons that Rails succeeds with Ruby. All files use Ruby. Even the templating language RHTML, Ruby. It works well…. really well.

So where does this leave Python? It leaves it with less energy and momentum for the future. Ruby is so similar to Python in many respects, yet with better features (ie. lower friction). Ruby will be used in more and more projects. Ideas from the Python world will drift over to the Ruby camp. Look what it is doing to the Java community as well. Perl? PHP?

Someone once exclaimed to me ‘syntax doesn’t Matter!’. Oh how wrong they were!

Sidenote: Humor

Ok, so if the era of the ‘P’ languages has passed, and we are in the new era of ‘R’… will we end up with ‘S’malltalk?

This entry was posted in General. Bookmark the permalink.

3 Responses to Ruby vs. Python on Domain Specific Languages

  1. Neville Campbell says:

    Or ‘S’cheme?

  2. Daniel Lyons says:

    Well, syntax is what it is, except when it isn’t. I learned Ruby in ’03 and now my job is in Python. I can tell you Ruby is a stronger language because of blocks, rigorous use of closures, and being able to make local modifications to classes defined elsewhere.

    I think you’re right though, Ruby’s just more fashionable now. They’re both excellent languages, but I always secretly wish for Python’s whitespace blocks in Ruby instead of a cascade of ‘end’s at the bottom of the file. I’d like to believe that Ruby’s flexibility at creating DSLs is somehow related to its success, but I just don’t believe it. Not enough programmers seem to care. Even PHP, which is a dandy templating language, has morons busy making things like Smarty. Bizarre. If DHH had picked Python instead of Ruby, then Ruby would be playing catch-up now instead of Python. Zope also was a big factor in holding back Python’s emergence on the web.

    I think any reasonably flexible language can make a fine web development solution, if the right person makes the right framework for it. The problem is, Ruby + Rails is the first really excellent web development framework.

  3. dru says:

    Hey Dan,

    I think it would have been too hard to stay Python up and down the stack like Ruby on Rails does.

    I don’t need to know Smarty or Cheetah.

    So, I’ll stick with the syntax superiority to python argument.

    Thanks for the comment.

Comments are closed.