Re^4: The Limitations of the CPAN

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.

Comment on Re^4: The Limitations of the CPAN

Replies are listed 'Best First'.
Re^5: The Limitations of the CPAN by diotalevi (Canon) on Nov 17, 2004 at 19:50 UTC
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.	[reply]
Re^5: The Limitations of the CPAN by de-merphq (Beadle) on Nov 18, 2004 at 01:36 UTC
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. --- alter ego of demerphq	[reply]
Re^6: The Limitations of the CPAN by tilly (Archbishop) on Nov 18, 2004 at 03:35 UTC
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]
Re^6: The Limitations of the CPAN by bart (Canon) on Nov 18, 2004 at 12:29 UTC
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]
Re^5: The Limitations of the CPAN by ysth (Canon) on Nov 18, 2004 at 08:42 UTC
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]
Re^6: The Limitations of the CPAN by Ovid (Cardinal) on Nov 18, 2004 at 16:28 UTC
I'm not trying to make the argument that this snippet is a particular problem for enterprise-level capability. I'm saying that certain problems get magnified when dealing with large-scale code. Cheers, Ovid New address of my CGI Course.	[reply]