|
Re^2: The Limitations of the CPAN
by Ovid (Cardinal) on Nov 17, 2004 at 18:22 UTC
|
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.
| [reply]
[d/l]
[select] |
|
|
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?
Being right, does not endow the right to be rude; politeness costs nothing.
Being unknowing, is not the same as being stupid.
Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.
| [reply] |
|
|
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.
| [reply] |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
| [reply] |
|
|
|
|
|
|
| [reply] |
|
|
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.
| [reply] |
|
|
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.
| [reply] |
Re^2: The Limitations of the CPAN
by coreolyn (Parson) on Nov 17, 2004 at 18:45 UTC
|
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.
I have to diagree with this point much as I don't want to, the plain fact is that TMTOWTDI creates far to much distraction from productivity for Managers to accept and feel comfortable with. Perl has everything it takes to be enterprise class, however, more coders code that path of least resistance rather than with the big picture in mind.
| [reply] |
|
|
Perl has everything it takes to be enterprise class, however, more coders code that path of least resistance rather than with the big picture in mind.
At my last place of employment, a Java developer wrote some code to pull data from the database. That code, because the structure was copied everywhere, ended up in every single place data was pulled from the database. Because of this code, this company ended up spending $400,000 on a new server with no discernible improvement.
What was this code, you may ask? It was the path of least resistance. Something along the lines of:
- Get a list of IDs from the database
- Iterate through that list, creating an object for each ID
- Each object, potentially, will populate objects it has, using the same method
So, what would have been a cinch to code up using a very minimal knowledge of SQL ended up costing at least a million dollars in unnecessary upgrades and lost productivity. All because a programmer didn't bother learning how to use the tools he was using.
I've seen this "bug" in at least three languages, two of which are considered enterprise-class (Java and C/C++). I've also seen it in Perl. The path of least resistance is a human bug, not a software one.
Being right, does not endow the right to be rude; politeness costs nothing.
Being unknowing, is not the same as being stupid.
Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.
| [reply] |
Re^2: The Limitations of the CPAN
by jacques (Priest) on Nov 17, 2004 at 18:18 UTC
|
| [reply] |
|
|
Just cause PHP is more accessible has nothing to do with the fact that Perl is still extremely accessible. :-)
Being right, does not endow the right to be rude; politeness costs nothing.
Being unknowing, is not the same as being stupid.
Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.
| [reply] |
|
|
That's quite true. As a below-average programmer myself, and one that has used (and still uses) both Perl and PHP for various projects, I know from personal experience that Perl is very accessible to below-average programmers (like me) and that PHP is even more so.
| [reply] |