The Joys and Horrors of Perl I

This post is the start of a series of post where I rant and rave about the joys and horrors of Perl.

Before I started working, Java was my primary language since that was the main language used at the university. Now Perl is quickly replacing Java as my primary language since Perl is the default language at work. This lets me look at Java with fresh eyes as well at it makes it possible for me to clearly see some of the weaknesses with Perl (I hope).

In general I must say I am pleasantly surprised by Perl. The language makes a lot of things very simple, but it has some quite ugly warts as well. I will start with one of the biggest of them.

What the f***!? No classes!?

Perl is not designed as an object oriented language and I generally have no problem with that. Everything does not necessarily have to be object oriented. However the way that the language supports object orientation is in my opinion not good from maintenance point of view. An program maintenance is a BIG deal.

In Perl, object oriented programming is supported by the built-in operator bless. bless takes a reference to some data-structure and associates it with a class name. The reference then becomes a reference to an object of the supplied class name (Perl has no class construct). What the reference points to is not important, it just have to be a reference. This basically means that you can implement objects using any data-structure that tickles your fancy. This
flexibility has of course lead to several different ways of implementing objects in Perl and each way has some different properties.

The most common way to implement objects in Perl is using an anonymous hash as an object. Each element in the hash is an attribute of the object. A major drawback of this way of implementing objects is that there are no access modifiers. You can use the object reference like a reference to any other hash. So you have the possibility of some idiot (possibly yourself one time you are in a hurry) accessing the internal attributes of the object without knowing the consequences and at the same time making it unnecessarily difficult to change the internal representation later. This leads to unnecessary maintenance problems.

The standard argument from Perl fans is that this is not a problem since by convention, all private attributes should be prefixed by an underscore. If someone is stupid enough to access a private attribute it is their own fault. They also argue that some times you also need to access the internal structure to get the job done. These arguments are only partially valid, for when the size of a project grows the probability of someone doing something stupid increases rapidly and the flexibility that the approach gives quickly becomes a liability
instead. If one programmer starts to access the internals of an object frequently, updates to the object could be nearly impossible since the amount of work required to change the faulty code will not be possible due to time-constraints. Thus you are stuck with maintaining backwards compatibility with the internals of you object.

As I mentioned there are several ways to implement objects in Perl and there are ways to get private variables, but they are not the standard way of doing things. This means that to get features that are common in many object oriented languages you have to know several different techniques for creating objects. This is just stupid! A Perl fanatic will probably say that this is part of the flexibility of the language, however this is in my opinion unwanted flexibility since it only leads to confusion and is rarely needed.

I think this will be fixed in Perl 6, but Perl 6 is still years away so for now we have to live with the lack of a consistent standard object oriented system. Blaah!