Pablo Lorenzzoni writes to defend Ruby in response to Kanwei Li's April post about dropping it in favour of Python.

Kanwei's post has some questionable points that Pablo rightly picks up on (being forced to use ternary operators?) and some that he doesn't ("LOC matters, people.").

Just like Kanwei, some time ago I decided to ditch Ruby and focus on Python for the tasks that I would normally use Ruby for. The two final nails in the coffin for me were

Interestingly, Pablo cites rubygems as one of the points in favour of Ruby.

Whilst both Pablo and Kanwei mostly focus on technical details for their attack and defence of Ruby, these two points for me were largely social, community issues.


I like both Ruby and Python, just commenting to suggest you check out Ragel, Nokogiri, and Superredcloth.
Albert (,

Hello, thanks for your comment. In light of yours and sbober's comments, I will have to take a look at Ragel et al. I do have a few bits and pieces still written in Ruby here and there, where I've used a library I haven't found a useful analogue for elsewhere. rmail comes to mind: there might be a perfectly serviceable implementation of the same thing in Python or Perl or whatever (in fact I'd bet on it), but I've just adapted the existing script I had to hand when I've wanted to do mail filtering, for example.


Jon, since version 4.0.0 redcloth is written with the help of Ragel (a state machine compiler that can be used for lexical scanners). There are only very few regular expressions left. Before that redcloth was a hand written parser/scanner combo. That's the way much text processing is done. It was quite okay to understand, as the regexes were split up into the relevant scanning tokens and the code was clean.

Have you looked at the current version of python-textile? If the code quality of a textile to HTML converter was that important for your ditch of ruby, you shouldn't be using python. python-textile is exactly what you describe redcloth with: big regexes and some big loops or global match/replace.

I'm not using python and ruby much. I just think comparisons should be fair. Yours wasn't.

sbober [],

Hello, thanks for your comment. It must have been redcloth pre 4.0.0 that I looked at. Specifically I was looking at it to try and extend it (to add support for wikilink tokens in a piece of software I was writing). Alongside surprise at the regexp/loop approach (I honestly thought it must have been written by someone who had never heard of a parser, although I know that to not be the case), I was also dismayed that the library couldn't be easily extended, given the language's famously open classes and duck typing.

I haven't looked at python-textile, no. For the purpose I am talking about I subsequently started using ikiwiki, which is written in Perl. I haven't looked at the internals of the markdown or textile plugins for Ikiwiki either. I'm sure there are good examples of bad programming in libraries and modules for every mainstream language. I merely acted on what I encountered, I wasn't searching for things to dislike.

Ragel sounds interesting and what you describe sounds like the right approach for this kind of thing.

Regarding a fair comparison, in all honesty, this really wasn't a comparison. I merely pointed out the points that made me ditch Ruby. As you point out, this was a decision I took some time ago.

It's not like Python's packaging is any nice. Distutils isn't amazing and setuptools just make matters worse. I don't know Ruby but Python's way of doing things currently is not to be taken as an example.
Floris Bruynooghe,

Hello, thanks for your comment. Python packaging is not ideal, no -- but at least it's possible for distributions to manage it. There's a good article by Joss Mouette, the author of python-support, on the Ruby design decisions which mentions python's "egg" (something I haven't seen yet) and some of the issues which were resolved by the Python community.

It is frustrating as a packager to have to make the decision between "python-central" and "python-support" in Debian, and to some extent the reason there are two is because packaging Python is non-trivial.

I find it a little bit amusing that Perl is the clear leader in the packaging stakes, considering Python and Ruby have come along since and could have really learned by example.

I guess you could read my post as advocating Python's approach to packaging but that is not the case.

It looks like Kanwei's post was probably an April fools joke.