Is Perl's OO evil? A Pythoner's Perspective

by Jeremy Jones

My first Perl module reverse-engineered a proprietary network protocol used at the company I worked for at the time. My purpose in creating it was to test the production and development implementations of the protocol. The module quickly grew to over 1,000 lines of code. I developed a sense of dread every time I had to make even the slightest modification to this particular module. After a while, I couldn't take it any more. I needed a language with cleaner OO support. That's when I found Python. And I have used Python nearly exclusively ever since.

What was so painful about that Perl module? The first thing was my newness to OO...and to programming in general. At that point, I had done some C and shell and was still pretty new to Perl. The majority of my OO exposure was what I had read in the perltoot.

The next thing was the general oddness that went into creating a Perl module. For example, there was this "bless()" function. I didn't get that. What was "bless()" and why was I doing it to my "$self"? Another weird thing was the "1" at the end of my module. I didn't get that, either. But, neither of these things were deal breakers for me.

The next, and probably more significant, thing was dealing with complex data structures such as a hash of hashes. At the time, all those curly braces and arrows and backslashes were just not intuitive to me for creating the data structures that I needed. And I had even read perldsc.

I'll go ahead and admit it. The problems I had with Perl says more about me and my understanding of Perl (and programming) at the time than it does Perl. I was a newbie trying to do something that was fairly complex with a language which will gladly give you plenty of rope to do with as you please. I happened to be putting that rope rather uncomfortably around my neck. At least that's how it felt at the time.

I was reading Perl Testing by Ian Langworth and chromatic the other day and had a moment of enlightenment regarding Perl and OO. One of the example pieces of code was a simple OO module. As I was reading the code, something about it was comfortably familiar. The constructor (typically "new") returned a reference to itself (typically "$self"). That vaguely reminded me of the __new__ method in Python. "$self " was a hash, which reminded me of an object's __dict__ attribute in Python. Each method's first argument was an implicit "$self", which is pretty much identical to Python.

I still prefer the Python syntax over the Perl syntax, but I feel that my exposure to Python helps me "get" what Perl is doing with its OO implementation. Funny. I feel like I could probably do some Perl coding again and not mind it so much...even before Perl 6 is actually released. So, I don't consider Perl's OO evil (any longer). And I don't consider OO to be so bolted on as an afterthought (which it might be...I really don't know). And, even though it appears as such at first glance, I'm not so sure that the internals to OO are any more exposed in Perl than they are in Python; they're just more Perlish.

The "take away" from this little stroll down nostalgia lane is that Perl isn't so evil. And specifically, its OO support is usable. I still prefer Python, but Perl is a viable language for getting work done.

10 Comments

jwenting
2005-11-07 23:06:59
evil
Perl is evil as a whole, it's not just the OO module.
So your hunch was right, it just didn't go down deep enough :)
johanvdb
2005-11-08 03:31:41
A bad craftsman always blames his tools ...
Have you ever looked at the workshop of a real craftsman? You won't find new shining tools, but old wrenched tools, torn and worn by their use ... still the craftsman is able to produce better products then the average John Doe or the self-proclaimed expert ...


My 5 cents ...


shogun70
2005-11-08 05:05:43
Perl is great, but...
my #1 "yuk" is all those curly-brackets and arrows.
Not sure how it could be fixed though.
aristotle
2005-11-08 06:44:59
Re:
An informed opinion, as always. :)
aristotle
2005-11-08 06:55:59
Re:
Most people in the Perl community will tell you that Perl5 wasn’t exactly built for OOP. It’s is very doable, and because it’s so minimally supported you can also mold the OO support in ways few other languages would allow you to, but it also means you need to work harder than with languages which have more extensive support for OO – I’m thinking mostly of Ruby here. Another problem is that the best approach for doing OO in Perl isn’t obvious (and in fact took years to be discovered and is still only making inroads with the community slowly).


In any case, if you want to do OO with Perl5, I recommend a look at the Class::Std module: http://search.cpan.org/dist/Class-Std/


In Perl6 – whenever that one will be done –, OO support will be much smoother right out of the box, and these contortions won’t be necessary.

simon_hibbs
2005-11-08 07:22:54
A bad craftsman always blames his tools ...
I've always seen this proverb as having more depth than that. A good craftsman will make sure he has the right tools, will know exactly how to use them and will take care of them. A bad craftsman blames his tools even though he's the one that chose them.


Simon

Reedo
2005-11-08 08:12:56
Re: Perl is great, but...
I agree with the "yuk", but I suppose there's a tradeoff, as some others have commented. Perl uses '.' for string concatenation (and for all I know did so long before Perl had any OO features at all). And the fact that a reference, whether to bless()-ed objects or a sub or a plain string, is just another scalar value, means you need special operators like -> to say "operate not on this scalar but what it points to". The upside is that Perl's OO guts are clearly visible; the downside is that, well, the guts are clearly visible.
joshuawait
2005-11-08 09:56:42
The Gift of Perl
The gift of Perl is that it is not militantly anything. If you want to use OOP. Great. Go to it. If you don't want to use OOP. Great. Go to it. If you want to mix and match as your heart pleases, great. Go to it.


This lack of an enforced structure provides flexibility, but as the author notes not having a required structure can make the language confusing--particularly for beginners trying to implement complex ideas. Perl's gift is also its burden.


I applaud your choosing Python over Perl as you recognized your abilities and the choose the right tool for the job. I also applaud your returning to Perl in order to expand the options you have in toolbox.


I'm trying to follow the axiom stated in the Pragmatic Programmer "Learn a new programming language every year". IT expands the mind an opens up new ways of thinking.

jmjones
2005-11-08 14:48:48
Re:
Thanks for the pointer! I'll have to check out Class::Std some time. I think OO is a great approach to decomposing tons of problems and I typically think in this manner when approaching things, so this might help out when I do happen to reach for Perl.
j.f.m.
2005-11-09 01:56:24
It's just, well, flexible
Perl supports every important aspect of OO but it enforces no particular implementation beside 'bless'. I was also fed up with it some months ago and considered moving to C#/Mono or Python.



Then I heard about Damian Conway's excellent 'Class::Std' in 'Perl Best Practices' and it provides what I need: A consistent, reliable implementation of OO techniques. It even handles multiple inheritence and true encapsulation of private instance data. Though it's not part of the standard distribution of Perl, it is the best 'Class' package available. The book is a must have, too. Now I don't see a reason to migrate to Python just to get nice OO.