Mechanical

Criticizing Perl

I love the Perl language. Unfortunately, there's quite a bit to criticize about it. Most of the issues which dissatisfy me are being fixed in Perl 6, but that's a long way off. So for the time being, I work around the problems.

There are two major camps of those who criticize Perl: those who know the language well and those who know the language poorly. Their criticisms do not generally overlap. It's gotten to the point where when someone says "I don't like Perl", I usually say "many people don't" because most people who don't like Perl don't know much about the language and didn't bother to learn. They see sigils on the front of variables and say the language looks like line noise. They see examples of Perl from bad programmers and generalize that to all of Perl. They "know" that only strongly typed (whatever the hell that is) languages are worth considering so Perl "must be bad".

Anyone whose thought processes are that simple-minded is someone I don't want working for me. There are plenty of reasons to dislike Perl. The three aforementioned ones aren't in that list.

One issue which amuses me the most, though, is how some people think Perl is so bad but keep mum on the subject of PHP. Most folks with only a passing familiarity of either language would be hard-pressed to tell them apart.

I wonder, though, if part of the problem lies in Perl's power? To really exploit the full richness of the language, you have to know it well. How many will stick with it long enough to get there?
  • Current Mood: amused amused
Tags: ,
Well, I'm sure that I fall into the category of people that only know the language rather poorly. I respect the power and flexibility of Perl, but I find PHP to more intuitive and user-friendly. I prefer weakly typed launguages basically because I tend to only use them for pretty small and simple applications and because I'm lazy.
I like to think that I know it decently well. I'm not near guru level like yourself, but I've got a pretty good understanding for most things.

I've got a class project coming up doing some alife research, and I'm considering going with Perl to do it. I just get afraid because I haven't really done any OO-style coding in Perl yet, at least not with my own classes, and even with references over pointers, I still get kind of nervous. I think it'd be a good way to learn more about a language that I really enjoy, but I'm not so sure if it's a good idea to try out, or if I should just stick with C++ because that's what I know and I've got some solid code examples that I can use there to work it out.

Since you are notably more skilled in Perl than I, I would love your opinion. Think it's worth attempting something large and OO in Perl?
Think it's worth attempting something large and OO in Perl?

Given that I do a lot of work with "enterprise class" software in Perl, I would have to say "yes" :)

There are problems, though. Perl's standard mechanism of blessing references means that encapsulation tends to get violated all over the place. The two best methods of dealing with this are using so-called "inside out" objects (see Perl Best Practices) or doing what I do and have a large, thorough test suite. Still, for all the times Perl has bitten me, I would say that the language is so fast to develop in that it's a fair trade off.

As for alife in Perl, be careful. I've done it and Perl is great because of it's rapid development, but for AI work, it's rather slow as AI tends to be computationally intensive.
I have to say that speed is one of my concerns. However, given the scale that I'm going to be working in, I'm not so sure it's a big issue.

One thing we have to do is have some sort of nice GUI setup for it, so that you can somewhat easily visualize what's going on in the world space, so I'm also looking into Perl/Tk, even if it's a bit ugly, and I kind of fear how that's going to change things.

Also, as for seeing Perl Best Practices - are you referring to the book that came out a few months ago, or possibly some webdoc somewhere I haven't seen?
The book. It's a wonderful resource. Even if you don't agree with all of the practices, you'll have a good understanding of the issues involved.
I wanted to come back to this post to leave a followup.

It took me a week to get to PBP, but I have to say that of the Perl books I've read (which I'm sure isn't as many as you, but I own and have read most of the O'reilly set), it's easily been the most useful one yet.

I've got some simple classes going, and I've also got a test suite that currently contains 45 tests. That's roughly at least 40 more than any other student in the class so far (although it's about 800 less than the prof - but hey, I can't expect to be at his level yet :D)

Also, thanks for the tips on the concerns. I am hoping that because I'm doing more evolution-based alife that doesn't have much intellect going for it, that the resource issue won't crop up. So far, so good.

Thanks so much for this advice. I'm really enjoying things now. That book turned me around 900 deagrees (I'd say a simple 180, but it was such a whirlwind at first, that 900 feels right) and I'm on a solid track now.
heart perl.
i know what you mean. however, to be honest, i understand the urge to criticize perl and not criticize php.

perl has a few things that really upset people emotionally for some reason. one of these is that you cannot have if/else blocks without braces. another thing is that it is 'elsif' instead of 'else if' -- it's weird, i don't really comprehend it, but i have understood this irrational response as i have had it in the past. there are things that can just seem ugly at first blush.

php's ugliness on the other hand is limited to rather drab things like lack of namespaces and inconsistent naming conventions. php just feels too blah to have a strong opinion about. it's not threatening, or radical. it's just there.

perl strikes me as php's crazy, half-drunk, hawaiian shirt wearing, all-around more interesting uncle, but i tend to do my web work in php because it's more staid. go figure.
I've never tried Perl, and do all my Web work with PHP.
(not that much of it, mostly plucking som data from a MySQL database and displaying it)

I picked PHP because that's what the server I'm using offered.

It works for me.
Maybe if I bump into a problem I can't solve using PHP I'll look into Perl, but then again... I may just redefine the problem...
(I'm lazy; what else is new?)

That said, I prefer strongly typed languages, but mostly because I tend to be a bit of a slob, codewise...
(Strong typing forces me to clean up my code a bit)

Then again, I wrote a pretty large front to MySQL using REXX once...
It was a mess... a real mess...
Amusingly, your comments are related to an email that I accidentally sent to the wrong address today:

Don't think of typing in terms of "strong", "weak", "static", "dynamic", etc. People constantly use different definitions of those without even realizing it and this leads to fruitless conversations.

Instead, think about typing the container (Java) versus typing the data (Perl or Ruby). That's what programmers are usually referring to even if they don't realize it. With the latter I get to take full advantage of the power of allomorphic (as opposed to polymorphic) dispatching -- well, I would if Perl 5 hadn't rejected the autoboxing patch :( -- and virtually eliminate the need to know class hierarchies. Instead, I can focus on class *capabilities* and just Get Shit Done.

(Allomorphism is where classes unrelated by inheritance present the same subset of behavior. For example. a Customer object and a World object may both offer a "save" method even though they're not related. That's allomorphism. Rubyists call this "duck typing").

Yes, you do trade some compile time safety for runtime safety, but as Bruce Eckel (Thinking in Java) himself pointed out, one of the primary reasons for *container* typing is a poor substitute for a test suite. One of the main problems with typing the container instead of the data it contains is we are led into a false sense of confidence that the container (variable) has a valid value. We're usually more concerned with data domains instead of data types. For example, the temperature of liquid water shouldn't be declared as a "float" or "double". It should be declared as float or double whose value is greater than 0 degrees and less than 100 degrees (Celsius) and if we really want to be safe, we specify that this domain only holds at one atmosphere of pressure.

Strong typing will not help you there. Strong testing will. As a result, if you put the test suite into place, it's almost irrelevant whether you type the container or the data. In fact, the most frequent benefits (not all) you can get from typing the container are performance related. It's unfortunate that many programmers hwo rely on container typing have a false sense of safety as a result.

(Note that focusing only on performance is a false optimization. The question there is whether we need to take advanage of CPU performance or programmer performance. Unfortunately, cost/benefit of this analysis is something that many programmers overlook).
you know me, and my language familiarities.

i love perl, and i hate it ...

the thing that i hate the most about it is that there are 1001 ways to do everything, and that leads to either having to keep a tight control of your developers in an environment (coding standards, etc), or unmaintainable code (yes, those are the extremes).

but, i have to give it marks for allowing good OO design to take place and enforcing scope, specifically by requiring $self to be passed in. i hated that at first, and have come to like it, recently, after dealing with class scope issues in javascript (talk about infuriating).

but that's just me ...
Er, Perl allows for a strong OO design in many respects, but unless one switches to inside-out objects, the encapsulation violation inherent in blessed references is horrendous (and don't get me started on the lack of multi-method dispatch -- something that any mature "OO" language should offer).
I figure, if it's not FORTRAN, then it can't be all that bad.
One issue which amuses me the most, though, is how some people think Perl is so bad but keep mum on the subject of PHP. Most folks with only a passing familiarity of either language would be hard-pressed to tell them apart.

Or those who love Perl and say PHP sucks. That's an interesting bit.
C'mon! We all know Perl doesn't scale! You should use Java!

<- Runs