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.

Meta meta

I feel like I'm getting bogged down with layers and layers of meta programming. I have programs that do things. Then I have scripts that run the programs that do things. Then I have scripts that run the scripts that run the programs that do things with different options. Then there are scripts to manage the myriad options and parameters. And just as that gets complicated I have to work with yet another wrapping of the scripts to manage the plethora of things to make sure the stuff has what it needs and runs correctly because by this layer it gets really confusing for all involved. But this new layer is every bit as confusing as every other layer.

I guess that's the history of programming.

So programs started out with machine code, 1's and 0's. Then came assembly which replaced the 1's and 0's with mnemonics for the instructions. Then came the mid and higher level languages which replaced the mnemonics with nicer and cleaner and more readable and one needn't know all of the individual steps to do some task. Then came the even higher level scripting languages to manage and glue together all of the various programs written in the higher level languages. And with it came systems of keeping tracks of arguments and parameters. Command line options and GUI's were made. And still more. Another layer after another to abstract and abstract until noone knows what goes on underneath. It's a bit of a maintainability nightmare all for the sake of making things more accessible. Ah well, there's a certain pleasure to it that goes with the pain.

Comment first, code second

Read this article on commenting. Kind of skimmed it actually. It did make me think about it though. I was going to post a comment on how I do it but I saw a comment from someone else that does it like I do.

Basically, I try and comment BEFORE I code. It solidifies what I'm about to code, its purpose and method. If implementing an algorithm it often helps to explain the steps in words, or even in pseudocode. I've seen people site papers or web resources as well which is acceptable. It also helps to note the limitations, what needs to happen before and after, the overall use of the code snippet and what-not. I find that doing this also helps me to code better. The steps are more clear and potential problems and bugs tend to get avoided when you see a description of the algorithm layed out in laymans terms.

Like most people I often work with other people's code. I get frustrated a lot at the lack of comments or the poor description. I've also done evil in the past, writing code myself that was uncommented, I try not to do that anymore. The bigger the system, the more the need for good comments. I understand that often in the throws of coding marathons, such sensibilities fall to the way-side. This is probably why there are auto-documentation systems out there. I'm convinced that there are people out there who think that this is actual documentation and they don't need to enter their own. In my experience, these do almost nothing to help me understand what I'm looking at. I would not miss it if they disappeared. Granted, sometimes it does help to automatically insert comments in places that need it (functions and such) as mere placeholders and to take stock of higher level stuff. But all in all, comments should be made as the code is written if at all possible.

YAML

YAML once meant "Yet Another Markup Language" and now means "YAML Aint Markup Language" but I would prefer it to mean "What do you get when you breed a Yack and a Camel". It's a data serialization format that (and this is the important part) is human readable text. It was brought to my attention a year ago by a coworker and I had since hacked it in to our system to better handle log file parsing. I completely agreed it to be the right idea. It has made my log file parsing much less stressful and more consistent. It just sucks that the online community for it is still... lacking. Some of the main YAML sites seem grossly out of date and nearly empty.

My recent frustration is dealing with incomplete implementations in the different scripting languages. I'm currently parsing Python generated YAML streams with Ruby. They seem to conform to different versions of the specification; most notoriously for me right now is how they each treat boolean values. My Python implementation wants to turn "+" and "-" into true/false (I had since hacked that out). Ruby wants to turn strings like "true/false", "yes/no", "Y/N", and even "on/off" into boolean true/false. This is causing all sorts of minor annoyances since I'm dealing with text that will have this as literal strings and not as code for boolean values. I in fact think that having the YAML spec interpreting strings as booleans is just a bad idea with perhaps some exception. Auto-interpretation of data is a touchy subject and you're bound to upset someone no matter which way you go. I'd prefer the "everything's a string" method, since that would at least guarantee consistency. But for now I just hack in fixes for my own purposes. I may submit a patch someday. I'd feel safer using the format if I had a sense of more active development however.

Ruby seems to be the only safe-haven for YAML at the moment. They seem to be trying to turn it into a Pickling or Marshalling replacement though. That's not really what I want out of YAML. It's just a really good way to display nested list and hash structures in a clean, pleasant, and consistent way. Anything more may make it too complicated to be portable and general purpose. I'd still rather use it than write my own though, since I don't really have the time.