Perl fondly

I've read a many complaints about how Ruby took on too many Perl-isms. Actually, that's probably one of the bigger criticisms, and I completely disagree. In fact, I think Ruby is missing a few Perl-isms.

Some things about Perl that keep me coming back or I just appreciate.

• THE BEST regex syntax, which basically was inherited from awk/sed and the like. I am puzzled that while Ruby smartly has "=~" they didn't include the substitution syntax form "s/.../.../g" which is so common, ingrained, and best of all, compact. WHY WHY WHY?!! I mean, Ruby can still keep the sub() and gsub() (so as not to munge in-place). This is why I still use Perl for all of my command-line hacks [perl -pe] instead of Ruby. BTW, Python's regexps suck balls.
  
• Variables are easily identifiable because ALL variables begin with a $ or @ or %. Since Ruby is OO and has good data structures, only one symbol would be needed, say the $ (which means global in Ruby though). When I first learned Perl, the constantly having to type $, I admit, was kind of annoying. But I learned to appreciate it.
• Because of the regex syntax and the "everything is a string" paradigm, it really is nice and convenient to quickly manipulate strings which is what I spend a good chunk of the time doing at work.

But generally, I've outgrown Perl for most of my scripting tasks; it's just not practical or convenient since the data structures are rather weak. I wish others in my group would follow suit.

A Ruby in the rough

I've noticed in the past few months more articles in the nerd channels about Ruby (mostly in regards to RAILS which I don't use). I'm sure it's simply selective attention on my part because I really love Ruby, more fervently than I did Perl when I first started using it some 10 years ago.

Ruby is a scripting language and I've been using it nigh unto a year now. It is currently my favorite scripting language and it was so practically from the first day I started playing with it. You can find plenty of advocacy, zealotry, demogoguery, and fanatacism in the usual places online; I'm sure even more if you can read and understand Japanese. Fortunately for me I did not see or read any of that online bantering about how "my scripting language can beat up yours" when I decided to play with it, only enough about it to give it a try.

Two things sold me on it immediately:

• Nice data structures
• The presense of "=~"

I'd been a Perl die-hard for years, was forced to use Python for work reasons, learned to really appreciate Python for what it was, and then cursed both for not having what I liked and needed to have in each. Perl makes for great quick-and-dirty guerrilla-warfare scripting but became clumsy for larger projects. Python was systematic, clean, and good for such larger projects, mostly due to its data structures, but it really dropped the ball when it chose not to add that little simple piece of syntactic sugar ("=~") to handle regular expressions. I deal with lots of text data but even if I didn't I do consider regular expression tools a basic necessity to life on the command line. And using regular expressions in Python just blows! There are other annoyances in each but those are currently of primary importance to me and my trade.

Enter Ruby, which upon first encounter appears to have the best of both worlds. Oh joy! I got busy with it immediately. It also had an interactive mode like Python, something Perl really needed. With a bit more experience, I discovered and began to appreciate some of its other and even novel features:

• Truly object oriented in presentation (even the number 1 acts like an object) which adds a kind of consistency.
• Interesting use of code blocks (I didn't like lambda's in Python, does anyone?).
• Ease with which to extend even basic classes and objects.

With more use I found myself rethinking my former ways of coding a task (e.g. I found myself considering even simple things more often in terms of iterators). There are also things I find truly elegent (e.g. using code blocks for initializing).

The unfortunate aspects:

• It's still rather new (outside Japan) and so the community and support is rather smaller than Perl and Python.
• The syntax and keyword naming is a mite unfortunate and takes some getting used to. But at least it doesn't strongly rely on syntactically significant white spaces like Python.
  
• It has automatic variables. You don't have to use them, and I don't mind them, but it freaks some people out. It does mean you can run cool stuff on the command line like Perl though.
• It's yet another scripting language, and there will be some inertia to overcome, especially in the staunch work environment.
• I miss Python's use of named and initialized arguments. This is almost a deal-breaker. Grrr... nothing's perfect it seems. Fortunately, that might change in the future for Ruby, and there are hacks to simulate it now but they are just hacks. I don't like the hacks though.
  
• At present there only a relative few books on Ruby in English. Fortunately the first one out is a great one, on par with the Camel book in my opinion.

Currently I'm the only one at my office that uses Ruby. It will probably stay that way due to the inertia problem. But I decided to continue writing and infesting the company research code with it until someday they all seccumb to my will and see the light.

The infamous Python indentation

I don't care how good it looks, how clean it appears, how visually aesthetic to the reader it becomes... having the proper indentation as part of the Python syntax is just an annoyingly bad idea. I use emacs for most coding but occasionally use vi(m) for quick fixes, especially when I'm running from another terminal or someone else's machine. They are not always configured equally so that they produce different indentation lengths. It's just an annoyance but it occurs often enough to make me groan. I've read people defending this type of syntactically significant white space by claiming that all editors worth their weight can be configured to do the right thing and the clean listing is worth the "slight" inconvenience. I think it's wrong to dictate a certain level of editor in order to properly and easily edit code. I should be able to use whatever I want without having to configure it, even a DOS editor. But here's a short list of how it inconveniences my edits:

• When developing, I often disable chunks of code with an "if (0)" or "if (false)". Because there's no end-of-block keyword (indentations mark it) I can't do this in Python. I have to resort to highlighting the entire section and re-indenting it en masse. Or i have to highlight it all and comment it out. Again, this requires an editor with the correct macros. But it is still more work than the simple if(true|false) I can use with most other languages.
• Python's lack of block end keywords makes it easy to unintentionally nest blocks. Ever have consecutive if-statements and the second if auto-indents under the first one instead of at the same level? This is a common gotcha when I'm editting and replacing a line of code.
  
• In emacs I often use tab to auto-indent/clean-up code. Lack of block end keywords means the indentation is not unique. It also means that you cannot have a beautifier program.
• It's dangerous to cut and paste code from one section to the other, or off of web pages or other programs because the indent may be different (and difficult to clean up) or it may be at the wrong level.
• Using Python interactively from the command line becomes a pain too since you have to keep track of indents for every line.
  

I sympathise with the desire to produce consistent, pleasant, and hence more maintainable code. I think enforcing it this way created more annoyances than it meant to solve. A simple beautify program often does the trick when you want the script cleaned up after a lot of cut/paste/reorganization.