Re^2: The Limitations of the CPAN

[Ovid]

The point here is that Perl is no more and no less suited to enterprise-class work than any other language. The skills needed to build an enterprise-class application are not language specific. Please stop promulgating that mismeme.

Sorry, but Perl has some significant issues for developing enterprise-class applications that other languages don't always have. For example, I was working on our code and noticed a test failure that I traced down to this line:

    open FOO, $bar;

When I saw that, a quick grep through our source code revealed this problem in a number of places, and not just with open.

Or how about this:

    $object->_private_method

Too bad that overrode a private method in a subclass.

Or how about this:

    $object->{recieved}++;

Whoops! That was unfortunate.

Or how about this:

    sub foo($$);

    # we'll just inherit foo() instead
    # sub foo {
    #     my ($self, $arg) = @_;
    #     ...
    #}

How many people will spot that bug?

Or how about this:

@ISA = $foo ? 'bar' : 'baz';

That's really fun to debug in a persistent environment.

And how about the fact that I signature-based method dispatch is not supported in Perl, so I have an entire class of bugs that simply doesn't exist in most other languages?

If any of those above examples seems contrived, I assure you that I've been bitten by every single one of them. Further, they lead to very subtle, frequenly intermittent bugs that are difficult to track down. In large systems, this compounds the problem. Most of the above issues are non-existent or a snap deal with in Ruby or Smalltalk.

[dragonchild]

For every one of those that you mention, I can name a similar issue in C/C++. As I don't know Ruby or Smalltalk, I cannot speak to those languages, but I'm sure they have similar issues. There are whole classes of bugs, in every language, that simply don't exist in some other language. Heck, Ovid, that's a major reason why new languages get written - to solve a class of bugs that some other language is rife with.
• Do you hate malloc()? Well, write a language that manages your memory!
• Do you hate dealing with variable typing? Write a language that's weakly typed!
• Do you hate having to write all your code up front? Write a language that does runtime compilation!
• Do you hate being constrained by awkward calling semantics? Write a language that doesn't have any!

And so on and so forth. The point is that Perl was designed to deal with whole classes of bugs and issues. Perl6 will be dealing with whole classes of issues that Perl5 has. Please note that many of these issues are problems other languages would love to have to deal with. They're "high-class issues". Kinda like having to decide between going on a free cruise and having to choose between your girlfriend and your best friend. It's a problem, but it's one most people wouldn't mind having.

I have also been bitten by most of the bugs you describe. I'm not disregarding them. And, I'm sure that Ruby solves many of them. Ruby should - it's designed by a former Perl hacker, who probably had many of the same frustrations you are expressing.

The thing you have to realize is that no language will protect you from typos, 3am hack sessions, or just plain old stupidity from your coworkers. I'm going to guess that you've been the lead developer for some time and have been very frustrated with the stupidity you've had to deal with. *shrugs* It's not Perl's fault ...

• ... your coworkers can't be bothered to read the documentation for open or to use lexical filehandles (which solves the problem).
• ... someone chose to use hashrefs for your objects and use direct access when there are literally hundreds of better solutions on CPAN, such as Class::MethodMaker.

Am I making any sense?

[tilly]

Sorry, but this really comes across as, "Without knowing the alternatives, I'm confident that your criticism applies equally to everything else. So don't complain."

This impression is not helped by many things that are easy to criticize in your response. Here are a few instances.

• You incorrectly spotted what Ovid was bothered by in that open. It isn't the global filehandle reuse (though that is bad), it is not checking system calls. Lexical filehandles do not solve the problem.
• You identify Yukihiro "Matz" Matsumoto as a former Perl hacker and suggested that he was motivated by what Ovid was. I'd like a source for that because I've never heard it, and it doesn't fit what I know about him. I've seen him describe himself as a Lisp hacker. I've seen him admit to knowing Perl 4 (and disliking it - he says that it feels like a toy language). I've also seen him criticize Python for not being OO enough. Yes, lots of Ruby people used to be Perl hackers. But I've never heard that Matz was.
• Ruby was emphatically not designed to address shortcomings with Perl (although I've seen Matz say that the lack of a scripting language that could handle Japanese character encodings is part of what got him to actually write Ruby). You can read this faq item to find out what he claims motivated Ruby's design.
• There are hundreds of different solutions for writing objects on CPAN. Better is in the eye of the beholder. The fact that standard documentation, top Perl programmers, and examples that you'll find online generally reach for hashrefs first strongly suggests that you can't dismiss that solution as just having a stupid programmer.
My impression is flavoured by one significant fact. I know Ruby (if not nearly as well as I know Perl) and I am in full agreement with Ovid.

My considered opinion is that there is nothing that I consider a significant strength of Perl as a language which Ruby does not share. There are many things that I consider significant weaknesses of Perl as a language which Ruby does not share. The things that I consider weaknesses of Ruby which Perl does not share are relatively minor. If I had control at the start of a large project, I'd choose Ruby instead of Perl. I'd solve the programmer availability problem by being willing to hire good Perl people and retrain. The cost of rewriting wheels to be found on CPAN I believe would be paid for by savings elsewhere in the project.

[diotalevi]

The cost of rewriting wheels to be found on CPAN I believe would be paid for by savings elsewhere in the project.

I'd like to lift this thought and make an example of it. I've just recently reimplemented parts of CGI.pm in LotusScript, Lotus-IBM's VB dialect, and it was mostly easy. Instead of having to hunt down a specification on what exceptions production quality would have to handle, I read perl's own escapeHTML and param functions. I've saved myself a number of steps by re-using the domain knowledge coded into the perl module but without actually using perl.

For this type of thing, CPAN is a great resource even when the actual code isn't going to be executed.

[de-merphq]

The link you provided states pretty clearly that he deliberately took a chunk of perl as a model. Meaning to me he was some form of perl hacker, even if he didnt like the language or call himself such. How would he do it otherwise?

Then, I reorganized the features in Perl into class library, and implemented them. I posted Ruby 0.95 to the Japanese domestic newsgroups in Dec. 1995.

[ysth]

You incorrectly spotted what Ovid was bothered by in that open. It isn't the global filehandle reuse (though that is bad), it is not checking system calls. Lexical filehandles do not solve the problem.

I see three problems with open FOO, $bar;. That kind of code just doesn't belong in anything more than a one-file script, and maybe not even there (unless it's a single-use throwaway script). I don't think this is an issue with "enterprise-level" capability at all.

[Ovid]

The reason I pointed out that Ruby and Smalltalk do not have these issues is because they are dynamically typed languages that are more comparable to Perl than strong and staticly typed languages like C++. If I need raw performance or tight integration with the underlying OS, C or C++ may be the way to go, but I'd still prefer to limit those to specific domains and write the bulk of the business logic in a dynamic language. As a result, I won't quibble with you regarding C++. My issue is that there are certain classes of problems that Perl has that other dynamic languages don't have and those problems are magnified in larger systems. Telling me that I need to hunt around and find the particular solution for the particular Perl-specific problem is little consolation when that problem goes away by not choosing Perl.

Heck, read what Paul Graham has to say about Lisp. While I certainly don't agree with everything he has to say, I wholeheartedly agree with his "some languages are better" assertion. I know this for a fact. I used to program COBOL.

[dragonchild]

Ruby most certainly may be better than Perl - I don't know as I don't have that experience in Ruby. I hope I wasn't giving the impression that I think Perl is the be-all-end-all of languages (though I do think it gets closer than most). I too agree with Graham's assertion that some languages are better than others. I too know this for a fact - I have to work with JavaScript on a daily basis. :-)

What I am saying is that there are reasons why one should choose a language over another, some of which have little to do with the power of the language. I guess my intial reaction to your post was fueled because you were posting about readily-acknowledged short-comings in Perl. No problem, except you said "XYZ language doesn't have this problem" and didn't demonstrate how that was the case. Nor did you say "And this problem is easily circumvented by doing foobarbaz", which would have helped the rest of us poor schlubs who don't have the choice of changing languages at the moment.

[Anonymous Monk]

I don't like languages for weak programmers that protect them, though I will say it's easier to make an error in Perl than it is in Ruby, and that one can program in Ruby without thinking of dark corners of it much more so than Perl. Perl is great, I love it, and criticism coming from someone who loves the language is REAL. We aren't saying "Java is teh ROXXOR, Perl SUUUUKKZ", but rather sharing experiences between two languages of similar capability.

Or more bluntly -- Ruby is a nicer and more eloquent Perl.

[stvn]

I will not disagree with you that those are all insidious bugs which in other languages would not exist, but I think this only supports dragonchilds point more. Bad programmers in perl are bad programmers in java are bad programmers in COBOL, etc etc etc. All your examples are, IMO, not examples of what is wrong with perl, but what is wrong the individual programmers who wrote them. Sure these particular problems might not exist in Java, but Java has it's own set of "bad programmer" mistakes which can be just as evil to debug and fix.

I don't believe you should blame the language, as much as you should blame the programmer. Disciple and experience would have solved all the problems you mentioned.

[rrwo]

Remember that Perl allows people who know what they are doing to do what they want. Which is great when you know what you're doing. It's bad when you don't have any standards. It's worse when other people on the project don't know what they're doing and don't have any standards. And in that case, it doesn't matter what language.