jmtd → log → Ruby vs. Python
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
The redcloth library - a textile-markup-to-HTML library, which is well presented and documented. I looked under the hood and reeled in horror away from the "parser" which was implemented in terms of regular expressions and big loops. I felt this spoke volumes about the quality of code coming out of the Ruby community.
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.
Comments
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.
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.
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.