Your skill will accomplish what the force of many cannot |
|
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
I'd like to comment a moment on some of the author's points... from my perspective the crticism that resonated the most with me was the reference to the "UNIX in-crowd." When I was learning Perl I didn't take a class, or read Learning Perl... I learned it from the 2nd Edition of the Camel. This was both a good thing (I liked Larry et al's writing style) and extremely frustrating, because I didn't come from a UNIX background. ("ls" and "chmod" were about the only UNIX commands I knew.) Everytime the book said "Perl function x works just like y in UNIX" I had to go spend (sometimes hours) trying to figure out what the heck that meant. It was very frustrating.
Now, admittedly the 3rd Edition has corrected much of this (that was one of the things responsible for its impressive girth) but it was (is?) a valid criticism. However, I thought the section on CPAN modules getting in the way of portable code was misguided. Yes, distributing (and maintaining) a Perl program that uses some bizarre confluence of modules is a pain, but that's not what Perl is for. Perl is NOT designed for creating one-size-fits-all solutions, which means that there are very few pre-packaged, ready-to-go out-of-the-box, for-pay Perl programs. That's not a bug, it's a feature. Perl isn't designed to solve everyone's problems, it's designed to solve your problem. Your problem, on your platform, on your hard drive, on your server. The nature of the language makes that easy to do (heck, it even makes it fun) but a solution cannot simultaneously be unique (for me) and generic (for everyone) at the same time. Complaining that Perl isn't really "portable" is like complaining that your custom-made suit doesn't fit your grandmother. Well of course it doesn't. It wasn't meant to.
Gary Blackburn In reply to Re: Perl's warts
by Trimbach
|
|