Please Stop Using Perl 3

by Curtis Poe

You frequently hear talk about how "Perl doesn't scale" and "Perl is write-only" and there's a bit of truth to that. You see, many programmers are still writing Perl 3 code. Now that might seem strange because people still talk about seeing Perl 4 code, but Perl 3, released in 1989, renamed in 1991 to Perl 4 to ensure that the first edition of Programming Perl could easily document a particular version. It was a convenience for the users of the language and not really a major upgrade of the language. So basically, Perl 4 code is Perl 3 code.

Perl 5 was released near the end of 1994 and it was a sweeping change to the language, making it a truly useful tool for building large code bases, including object-oriented programming. Unfortunately, many of its features designed for making Perl a scalable language didn't catch on for a while due, in part, to so many people being used to Perl 3 syntax. Even to this day, I still get email from people asking why their code doesn't work and I see Perl 3 code. Such code tends to be poorly organized, harder to read and, no surprise, doesn't scale well and tends to be "write-only". So stop writing Perl 3/4.


26 Comments

Adam Kennedy
2006-08-22 14:11:11
And not just PHP.


I'm fairly paranoid about trying to write clean readably code, and I've heard...


"Is that PHP?"


"Is that Ruby?"


"That doesn't look like Perl at all"

Jan Pieter Kunst
2006-08-22 14:35:05
I thought the joke about Perl was that it's "write-only"?
Ovid
2006-08-22 14:48:03
Jan: you're absolute "write". I can't believe I wrote that :) It's fixed now.
Steve
2006-08-22 15:51:27
You're never going to escape this problem, with such a pervasive base of Perl users proud of the fact that "There's more that one way to do things." Because of this people are going to continue to write Perl code that looks like Perl 3/4 (just for the pure fact that they "can")


Because of this flexiblity most Perl programmers have no idea how to write modular Perl code. And it takes an amazing amount or restraint to write code that will "scale" and isn't "write-only." My first experience with making a class or module was so horrific that I gave up (admittedly I probably fall into one of those perl 3/4 guys since thats what I cut my teeth on).


4 to 6 developers on one project doesn't really describe all parts of the term "Scale". What happens when you try to have 10-20 developers working on the same project? What happens when you want to reuse code? I can give a bunch of examples of non-scaling, hard to maintain perl code (Try customizing Bugzilla...) It just so happens that there are a lot more "bad" examples of Perl usage than "good" ones.


Companies like Amazon and Slashdot probably have great teams of Perl programmers that know every little trick and subtle perl-ism to get things done, and they probably continue to use Perl because it was "the" language to use back in the 90's.


But newbies to the language are faced with CPAN (which is actually a good thing) to download 100's of package they are told they need and then given a big huge Perl book to read through and then they get mentored by a Perl expert that first shows them all the 100's of ways to sort a list (all in Perl 4-ish code). God help them when they ask, "How do I do...." (And get 10 ways in pure Perl, 3 other ways using this Uber::Cool CPAN module.)


<highly_volitile_religious_war_material>


I've used Perl for many years, then I switched to Python and haven't looked back. Readability aside (Python *is* better to read), it takes much less time to 'promote' python code up the chain of programming styles (functional, namespaces, objects) from a one-off script than it does for Perl. I think some people mistake/explain this as "scaling".


But if you want a true example of scaling, try telling Google to use Perl on their distributed system..


People enjoy languages like Ruby because they leverage a lot of Perl's language (no type checking, unreadable code, etc) yet add on true object oriented behaviors.


Other people jump to Python because it gets rid of all the unreadablity and some of the crazy semantic behaviors of perl. Thus the idiom,"There's ONE way to do it." I commonly get asked the question, "Does Python have CPAN?" my answer is no, but for the most part you don't need it...the standard library provides a lot for you. And some people probably enjoy the newer languages (Python/Ruby) since they are delivering the same concepts as C++/Java with much less development overhead.


Don't ask me why people like PHP...I suspect it's because they can write crappier Perl-ish code AND smack it together with HTML!!!!


</highly_volitile_religious_war_material>


So I'd argue that the current mentatility of the majority of Perl programmers gives Perl a "deserved" reputation. There are a few Perl guys that break the mold so to speak, but that list is getting smaller and smaller.


All in all *I* would say "stop writing Perl code" :) But I agree with you, people should throw away that ancient "pink" version of the Orielly Perl book and get the latest and greatest tombs of perl books.

ngoc
2006-08-23 01:47:28
Perl scales very well. Perl is maintainable. Perl can be used to process complex and large data. The only thing perl still not good is OO features (and some few other features). But It will be corrected in Perl 6.

Java is advertised much as scaling language and for ENTERPRISE. But I really think Perl scales better than Java. And is more maintainable than Java.


We use Perl to process huge petroleum data. We can do the same job in Java. But maybe with 100 times over budget, 1 or 2 years of delay. And maybe 1 or 2 years more to maintain.

Peter
2006-08-23 06:03:28
Perl most certainly lacks cool buzzword features of Java and Python and it'll be nice to have classes,interfaces and such.
All said and done, one can still write fairly large and maintainable code in Perl - we make a living out of it - so, it's not just a heresay.
I'd love to try Python - after all - google can't be wrong. But the idea that I can't match braces (in vi) to see my blocks is just too frightening for me. I simply refuse to believe that whitespaces, instead of braces make better reading code.
Of course, that's subject to another religious war ;)
Robert
2006-08-23 12:00:30
I agree with (I think it was Randal). A sentence has a beginning, a middle and an end. Code should be the same way. That is one reason I just can't quite take to Python.
Steve
2006-08-23 14:11:55
Python's whitepace issue drove me nuts for about a week, then it just went away.
Steve
2006-08-23 14:14:32
"A sentence has a beginning, a middle and an end. Code should be the same way. That is one reason I just can't quite take to Python."


Huh?

Adam Krolnik
2006-08-23 20:07:58
You know - what I can't stand is people using perl and writing like they are using C.


$i++;
$a[$i] = $next_data;


for($i = 0; $i <=$#a && $found != 1; $i++)
{
if ($a[$i] == 0)
{
$found = 1;
}
else
...
}


Perl is 'write only'?! Almost all code is 'write only'!
Code not written for maintenance (comments, modules, etc.)
is very difficult to follow, especially when large.



CT
2006-08-23 22:34:52
I don't understand why these "Perl users for years who switched to Python" come out of the woodwork whenever they see an opening. The article is about how to help change the problem of too much bad Perl code. Implicit in that is the idea that there is a problem of too much bad Perl code. We get that. Point made. We're trying to change the community attitudes. We don't need a Python cheerleader proselytizing us every possible opportunity.
EH
2006-08-24 05:29:02
Excellent post. I worked at Rentrak for about a month (left on account of nunya) and was very impressed with the code there.


One thing that I think you aren't accounting for is that perl tends to be quite a bit more subtle than other languages. List vs. Scalar context being a big learning curve for people writing more than glorified shell-scripts comes to mind. Or Magic goto, or GLOBs, or mucking around in the symbol table (which is considerably easier than other languages in it's class, but much more arcane) or a million other things I can think of. The inability to override many builtins, even after sifting through CORE::. I'll avoid mentioning OOP because that's an easy target. :)


In the days where C is an arcane black art and lisp is more pretty than functional, I think it's safe to say that there's an easy path to animosity for something that is subtle. Whether or not that's a good thing probably depends on who you talk to.


I guess my point is, some of us who are saying, "Augh! Perl!" really do know what they're talking about, and think the grass is greener in other pastures for more situations than not. It is my hope that the people that DO know what they're doing are technically mature enough to avoid spreading that around like it's gospel to people who don't know as much, allowing people to decide for themselves what's best for them.


I know that's not what you're targetting, but it's something to consider given the size of your paintbrush here.

Steve
2006-08-24 12:11:50
"We don't need a Python cheerleader proselytizing us every possible opportunity."


CT: I'm sorry if my point came across this way, at least I wasn't saying stuff like "Use XXXXX because it rocks!"


I was just making a statement that the Perl language itself makes it very hard to learn the "correct" way to do things, let alone the fact that a crufty perl guru will say:


PG1: "Hm you could do it that way, but you could also say 'blah'".


then another perl guru (if you're lucky to know 2 of them) says:


PG2: "Well you can actually do it better this way and it's faster!"


When all I really wanted to know was the right way to do it. (At this point I'd say probably 1 out 10 "gurus" will give you the right answer)


If you are a good developer and you have a lot of discipline then the sky's the limit. But if you are lazy in any way whatsoever, they can think..."Hmm I don't need to make that a module...I'll just make this regex without documenting it...If it was a bitch to write it should be a bitch to read"


What it boils down to is that the developer needs to be a professional. This typically isn't the case with an overworked sys-admin putting up duck-tape perl code or a hobbyist web duhveloper. Nor is this the case when a majority old school perl programmers got hired during the .com boom and only had an english or art degree with *NO* software engineering experience whatsoever. Yeah their stuff worked, but did it scale? Nope. And damn it's hard to be professional when the language itself lets you get away with so much...


So what are the solutions to the problems mentioned?
1) Become a professional and learn the correct way to do things in Perl (or any language for that matter)
2) If you can't do that move to another language (or job).
3) STOP proselytizing the fact that "There's more than one way to do it", and START proselytizing good software development practices.
4) Educate lusers that "any" language can "scale", it just depends on the amount of effort/resources/money involved.


Until that happens on a wide scale in the Perl community (I don't think it will, maybe Perl6 will cause it) you are going to run into people that say "Perl doesn't scale" and Perl is "write-once", why the surpised look when someone says it? Most of the time their past interactions with Perl have been bad ones and the code they saw didn't scale and was not maintainable.


There! How is that? I went back into the woodwork and didn't cheerlead for that "other" language.

Aaron 'Teejay' Trevena
2006-08-25 07:09:08
Steve said:
"I was just making a statement that the Perl language itself makes it very hard to learn the "correct" way to do things, let alone the fact that a crufty perl guru will say:


PG1: 'Hm you could do it that way, but you could also say 'blah' '.
then another perl guru (if you're lucky to know 2 of them) says:
PG2: 'Well you can actually do it better this way and it's faster!'.


When all I really wanted to know was the right way to do it. (At this point I'd say probably 1 out 10 "gurus" will give you the right answer)"


Actually in my experience, on any decent perl list you'll get a concensus on the sensible solution first, and then the golfing will start afterwoods. Ditto IRC, probably even true on perl monks.


Your statements about the perl community might have been more true when Python was the cool new dynamic language on the block but that was a fair while ago.


Either you're a good programmer or you're not. If you can't decide how best to abstract, document and organise Perl code then your Java or .Net or Python code will be equally abysmal. I know this because for every messy and hairy perl project I've worked on, I've seen and worked on an equally awful ball of mud in Java, ASP, .Net, etc.


If you're in the wilderness, ignorant of perl mongers, ignorant of sites like perl.com, the cpan and publishers like Addison-Wesley, A Press, Mannings and ORA - getting your help from dodgy cgi bbs then what you say could be true - but that doesn't describe any programmer worth hiring.

CT
2006-08-29 12:54:07
Steve, I appreciate the clarification. I might be overly sensitive to the "I used Perl for years and now I just love Python" type posts. As for your most recent post, I think you hit the nail on the head with:



3) STOP proselytizing the fact that "There's more than one way to do it", and START proselytizing good software development practices.


To me it seems there is a noticeable move in the community towards this direction. I think Ovid's original post exactly fits that description. The popularity of Conway's Perl Best Practices is another prominent example. Maybe it won't work, maybe it will take too much time, but I definitely think there is a feeling that we need to move to a "TMTOWTDI, and sure that's fun, but lots of them are bad" attitude. It just takes time...

pgmer6809
2006-08-29 15:58:27
There is at least one PERL guru out there who has written several tracts (soon to be an O'Reilly book?) on "The Right Way To Do It". Damian Conway. And his 'teachings' have been implemented as a module on CPAN called 'Perl::Critic' (or something.) So you can run your perl code through this module and see how well it conforms to Conway's idea of best practices. If you start taking that to heart your coding style will improve substantially.
Dave Cross
2006-09-06 01:52:00
Aaron said:


"If you're in the wilderness, ignorant of perl mongers, ignorant of sites like perl.com, the cpan and publishers like Addison-Wesley, A Press, Mannings and ORA - getting your help from dodgy cgi bbs then what you say could be true - but that doesn't describe any programmer worth hiring."


But sadly the vast majority of Perl programmers fit that description. And the vast majority of employers don't know how to make that distinction.

Dave Cross
2006-09-06 01:55:03
pgmer6809 said:


"There is at least one PERL guru out there who has written several tracts (soon to be an O'Reilly book?) on 'The Right Way To Do It'. Damian Conway."


The book that you are talking about (called 'Perl Best Practices') has been out for a year.

Jenda
2006-09-06 06:53:41
"What happens when you try to have 10-20 developers working on the same project?"
What's more scalable? A language that allows you to have 50 developers working on the same project or a language that allows you to develop the same project with 5 developers? Yeah, it's possible that it's easier to handle a fifty-developer project in Java than a fifty-developer project in Perl, but ... does it matter? And is it really easier to handle those fifty than it is to handle those five?
Stathy G Touloumis
2006-09-07 10:18:31
I think putting an absolute label on the viability of Perl or any language/technology for that matter is rediculous.


There are many instances where Perl has failed and succeeded.


IMHO it is never an issue of the technology but when people "assume" a language or technology will work for a business or process without really understanding the business or process. The failure is almost always in the execution.


Does it matter if the code or technology is throw away when it positively affects the business that could not have been done through a "formal" development process? Who cares if the code is formal OO if the intent of the code is never realized because it took too long to develop or actually has a negative financial impact on the business?


Buzz Morley
2006-09-07 15:04:45
I know one huge bank that uses perl 3 for everything and they are very happy with it.

2006-09-07 21:59:02
Superb Article - lots of bizarre comments though... One word for all programmers: Efficacy

Bottom Line: less complexity + effective implementation in any endeavor (especially endeavors written in Perl) will get the job done at any scale. If you don't document, collaborate or maintain... you aren't doing your job... regardless, I'm sure the Perl interpreter, Java VM, etc will still do it's job.


Unfortunately Java has become so bloated we've been using Perl to do most everything across our enterprise. To say Perl doesn't scale is just plain (and well documented) False... I often find the most vocal anti-Perl activists are those that tried to learn Perl at some point... but just couldn't stay with it for whatever reason (lack of mentor, available training, weak).


2006-09-08 11:14:34
python
   tabs are really annoying
   this is the reason
that


perl {
   is better than python;
}

Abigail
2006-09-13 04:11:20
Whitespace issues in Python have never bothered me. They don't require me to change my style of coding. I indent loops, line up statements on the same level, and don't use tabs.


Perl6 whitespace rules on the other hand would require me to change almost every line of code I write. I won't bother writing Perl6 code. I rather write C or Java. Or Python.

David Nicol
2006-09-24 22:50:58
concerning the issue of giving multiple ways to do things, I
will try to present the multiple ways to do things in the context
of "it depends what you are optimizing for"
umm...
2007-06-16 14:15:08
I've written code in a lot of languages, and it's hard for me to tell what's going on in those two line examples without digging into the documentation for the syntax...