Beefy Boxes and Bandwidth Generously Provided by pair Networks
No such thing as a small change
 
PerlMonks  

Re^3: The Limitations of the CPAN

by dragonchild (Archbishop)
on Nov 17, 2004 at 18:38 UTC ( #408519=note: print w/replies, xml ) Need Help??


in reply to Re^2: The Limitations of the CPAN
in thread The Limitations of the CPAN

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.

Replies are listed 'Best First'.
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.

      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.

      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
        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.

        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.

      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.

        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.

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.

    Cheers,
    Ovid

    New address of my CGI Course.

      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.

        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.

        Cheers,
        Ovid

        New address of my CGI Course.

Re^4: The Limitations of the CPAN
by Anonymous Monk on Nov 17, 2004 at 19:01 UTC
    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.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://408519]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others exploiting the Monastery: (2)
As of 2019-08-21 00:48 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found

    Notices?