|
Re^4: The Limitations of the CPAN
by tilly (Archbishop) on Nov 17, 2004 at 19:37 UTC
|
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] |
|
|
| [reply] |
|
|
| [reply] |
|
|
By that criteria Matz is a Perl hacker in the same way that he is a Smalltalk hacker. And Larry Wall is a Lisp, Ruby and Python hacker.
I'm not doubting that Larry Wall understands Lisp, Ruby and Python. He certainly understands them well enough to know what the major datatypes and basic syntax are. He might need to refer back to references for details, but he certainly could program in them. He even knows them well enough that he probably has ideas about how he might implement them if he wanted to. But for some reason you don't hear much about the masses of code that Larry chooses to write in those languages.
Conversely I don't doubt that someone of Matz' level would be very competent in Perl almost immediately upon learning the language. After all he already knows how to think and organize his thoughts, he merely needs to learn how to express those thoughts in Perl. However what he means by "reorganized the features in Perl into class library" is that he designed a class library that provided datatypes corresponding to Perl's major datatypes. He then wrapped his method calls in enough syntactic sugar so that some of the shortcuts would look similar. He didn't try to reproduce Perl, he just tried to make (without compromising his OO framework) it possible for people to script problems like they would in Perl.
The knowledge of Perl which is implied is on the same level as you might expect from a decent sysadmin. A good programmer with an active interest in learning languages could be expected to learn that much Perl in very short order.
Of course the level of programming skill that this feat implies is another story. For instance it is well beyond what I'd expect from a random Perl hacker in that time frame. For one thing Perl 5 had only been out for a year, people hadn't had enough time to master OO based on experience with Perl. Matz, of course, already had 15 years of OO experience...
Of course you might ask why he'd pick Perl to imitate if it wasn't a language that he was a particular expert in. The answer is simple, he wanted to write a scripting language. In 1995 Perl was clearly the best of breed scripting language out there. Perl had no serious challenger to that title. Likewise Smalltalk was the best of breed OO language. So those are what Matz used as templates for his OO scripting language, even though he was primarily a Lisp hacker.
| [reply] |
|
|
Just a note for perspective:
1995 was pretty much the very early days of perl5. perlhist points out that the official release of perl 5.000 was just over a year old: 1994-Oct-18.
My personal recollection (1995 was my own first year with Perl, so I recall it pretty distinctly), was that everybody at that time was still using perl4 for most tasks. References were the big unknown, OO in perl was even more distant. It tooks a few more years before perl5 became the norm.
n.b. I'd like to stress that that was my own impression, with rather limited exposure to the outside world of perl. It is well possible that other people had different experiences, in that era.
| [reply] |
|
|
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.
| [reply]
[d/l] |
|
|
| [reply] |
Re^4: The Limitations of the CPAN
by Ovid (Cardinal) on Nov 17, 2004 at 19:31 UTC
|
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] |
|
|
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.
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 if the post was misleading. I meant to focus on a counter-argument to the "CPAN is everything" argument that I routinely hear. The other shortcomings, I should add, are widely known here on Perlmonks, but I've been surprised (disappointed?) how often I have to point them out in the real world.
| [reply] |
Re^4: The Limitations of the CPAN
by Anonymous Monk on Nov 17, 2004 at 19:01 UTC
|
| [reply] |