Deef's Net

Perl is an insane language. I love it.

I’m guessing that there are very few languages that can be made to interpret rod logic, as shown by Damian Conway during the opening night’s keynote (or Latin, or Klingon, to highlight other talks he’s done), nor are there all that many languages that let you write positronic variables that let you return results before you’ve calculated them (same talk).

But even if you discount the things you can do with filters, how many languages let you do something like this:

*{";\n"} = sub { print something }

In case you’re not familiar with some of the lesser used Perl syntax rules, that says “make a function called ‘semicolon newline’ and have it print ‘something’ whenever it’s called.”

That will probably result in a “so what” response from the non-techies reading this, but it should cause a certain tightening of the stomach and a feeling of low-level despair to any programmers reading this, possibly with a little jaw-dropping, once they realize what it means. (Hint: What is at the end of every statement in most languages?) And maybe some anti-Perl flaming for even allowing such a thing (don’t worry, it gets worse — for the C/C++ programmers out there, you can also name a function “\0”). But you can write Fortran in any language.

Back in 2004, I attended a tutorial called Perl Best Practices. This year, I attended Perl Worst Practices. Damian C. commented that we must be the smartest, cleverest people at the conference to have convinced our bosses to let us attend a three-hour tutorial with that title. I’m not sure what that says for me. Other talks included Perl Security and The Twilight Perl (showing that things that should be syntactically impossible really aren’t).

What’s neat about Perl’s insanity is that it let’s you do practically whatever you want. Even if you shouldn’t. Even if 99.999% of the time it’s a monumentally dumb idea. And that allows best practices to be developed and codified over time, rather than being limitations imposed by the language (there is that 0.001% where it’s the perfect solution, and saves you days of writing workarounds). This is increasingly becoming a defining point of the Perl community, once you get away from the people who treat Perl like stereotypical PHP.

Learning some of these crazy tricks, while hopefully not the sort of thing you’d ever use in production, gives you a better understanding of the language. If nothing else, that can be really helpful for debugging, or if you ever have to maintain someone else’s code (or code that you’ve written more than six months ago).

Because, once you’ve spent three hours going through SelfGOL statement by statement, there’s probably not much that an inexperienced or undisciplined coder can do to scare you.

Outside of the Perl world, one of my goals for the conference was to get a better understanding of Ruby, since it’s getting a lot of attention. Well, I tried to be open-minded, but even the presenter reinforced that it’s still a relatively new and untried language that’s going through a fair bit of change as it’s maturing, and the syntax didn’t seem all that better when considering code to line noise.

The “fair bit of change” description is especially true for Ruby’s frameworks. Not that Perl doesn’t have its own problems with frameworks (it does, and I may write some thoughts on that at some point, since they’re mostly not safe to use, either), but Rails is probably the main selling point that Ruby has, to the point of being synonymous to a lot of people, and it’s still very much a moving target, without enough of an emphasis on backwards compatibility.

That makes it a very bad choice for any program that you want to stick around for a while, unless you’re willing to invest a lot of your energy in keeping up with the changes to your underlying framework, rather than enhancing your own code (that’s my big problem with Drupal as well, despite my really wanting to like it).

But lest I be accused of having a bias against anything that isn’t Perl, I did come out of the conference with an interest in learning more about the Mozilla framework, along with a renewed desire to help in at least QA with that project, with the hope of eventually getting to know it well enough to write some client software using its tools. And I went to a good session that did an introductory overview of C, since that’s a definite area of weakness in my skill set at the moment. I probably should have attended a Python session as well, but there are only so many timeslots available. Maybe I can set that as a goal for next time.

All in all, I think I was only in one session that was particularly bad. Otherwise, there was a huge range of quality, but I didn’t find myself wishing I had gone to a different session instead. So that was definitely a win.

More on speakers and presentation styles next time.