Beefy Boxes and Bandwidth Generously Provided by pair Networks
There's more than one way to do things
 
PerlMonks  

Perl's warts

by grinder (Bishop)
on Mar 21, 2001 at 13:37 UTC ( [id://65986]=perlmeditation: print w/replies, xml ) Need Help??

There's an ongoing article running over at the Web Developer's Virtual Library about Perl. The 22nd installment talks about what's wrong with Perl.

All in all a very interesting read, except for the part where the writer suggests that for large projects one is better off using Python instead of Perl. eeeeeeeeeeeeeww!!!

--
g r i n d e r

Replies are listed 'Best First'.
(Need a new motto?) Re: Perl's warts
by arhuman (Vicar) on Mar 21, 2001 at 16:00 UTC
    Why do I always see the same false argument against Perl :

    "Perl allows you to do something.
    SO you can't do something else with it."


    Declined several ways :

    "Perl allows you to make obfuscated code.
    SO Perl can't produce readable code."

    "Perl allows you to use shortcut.
    SO Perl can't be used to make explicit statements."

    "Perl is often used for small scripts.
    So It can't be used for large projects."

    Perl is a good (the best for me) language beccause given to good programmers it will make them produce amazing code, of course given to bad ones it will produce only crap (but it will be the same whatever the language, Perl isn't the cause here...)

    Whatever the criterion :
    * Speed of developpement.
    * Compactness.
    * Readability.
    * Portability.
    * Ease of developpement(With all the modules available).

    Perl CAN excel in all those areas but you'll probably have to make some choice to enhance some with the tradeoff of degrading some others.

    I know I'm not saying anything new, especially for you Perl blesssed adept, but I wonder if we should communicate more on this.

    The TIMTOWTDI is now famous, shouldn't we promote other mottos ?

    Perl Is As Good As Your Coding Skills ?
    Only Bad Coders Badly Code In Perl ?

    I'm waiting for your ideas (I'll take the best one for my new sig ;-)


    "Trying to be a SMART lamer" (thanx to Merlyn ;-)
      Here's one I came up with a while ago:
      "Perl doesn't write bad programs; programmers do."
      As for your motto idea i perfer the second as the first seems to imply that it is a shortcoming of Perl. The second place the blame where it belongs just 1/50 of $1.00

      I Like the first one, piagaycs is easier to say than obcbcip

      my $name = 'Ben Kittrell'; $name=~s/^(.+)\s(.).+$/\L$1$2/g; my $nick = 'tha' . $name . 'sta';

Re: Perl's warts
by Trimbach (Curate) on Mar 21, 2001 at 16:16 UTC
    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
    Trained Killer

      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.

      This statement reflects something I've said many many times before and I'll say yet again, Perl needs to be more OS agnostic. The fact that it's severly Unix biased is not A Good Thing(TM). Perl has so much to offer for developers of all platforms (and speaking from my perspective, most certainly Win32 and Unix), but there's noone that can convince me that it really "feels" like a Win32 language in any way as much as it does a Unix one. (I happen to use both OS's).

      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.

      Interesting way of putting it. Though I can't say I totally agree that it's not for "ready-to-go out-of-the-box" stuff. Visual Basic + DLL Hell isn't a much more exciting prospect to look forward to. I speak from experience at my last job, where we simply could not get our internal report generation program to run on any but one of the computers in the office (because of missing DLL's and other odd errors).

      And just one more thing I can't help but comment on...use Python for large projects? eek...I started testing Python out by doing (or starting to do) a new client of mine's site with Python. I got severely turned off by the syntactic whitespace when a.) I indented one line with a tab and the next line with spaces and the compiler complained (a completely invisible error), and b.) I downloaded what I thought would be a reusable form mailer Python program, only to find out when I got it that the indentation was all messed up, rendering the code useless. I can't imagine how much my paranoia would increase if I was dealing with a 20,000 - 50,000 line Python code base.

      Needless to say, I'm doing the site in Perl now. :)

        This statement reflects something I've said many many times before and I'll say yet again, Perl needs to be more OS agnostic. The fact that it's severly Unix biased is not A Good Thing(TM). Perl has so much to offer for developers of all platforms (and speaking from my perspective, most certainly Win32 and Unix), but there's noone that can convince me that it really "feels" like a Win32 language in any way as much as it does a Unix one. (I happen to use both OS's).
        And I'll disagree with that. Perl's target market is Unix hackers. It's a toolbox for Unix. The fact that it also tries to be cross-platform is secondary in goal. I would not want any decisions made to increase portability at the expense of how well it hacks on Unix any more than I'd want Perl to be easier for beginners at the expense of experts.

        Certainly, if you can add or modify a feature to make it more portable without damaging the Unix interface, I'm for that.

        But let's take a common complaint: the unlink operator. Everyone not familiar with hacking C on Unix wants to rename that to something like the delete operator. No. I say no. The prime market for Perl is still the Unix hackers who are moving cross-languages, not "scripting hackers" (whatever that is) moving cross-platforms. The word unlink has a very specific meaning to Unix hackers, and helps us get the job done faster.

        Perl fills the niche as well as it does because it did stay focussed on what was important for Unix hackers.

        If you want vendor-neutral, equally inefficient code on all platforms, you know where to find Java.

        -- Randal L. Schwartz, Perl hacker

        Just my $.02 .........

        While Perl's target market had traditionally been rather UNIX-centric, I think that this is no longer the case. More and more people are using Perl on WIN32 and Mac. In fact, most desktops are indeed WIN32 (I don't like it either).

        With that said, I think that the misconceptions about Perl are largely based on most people thinking that it is strictly a web scripting language. People don't realize that this wonderful language has been used to develop enterprise-type solutions for large corporations.

        In fact, many hardware design tools/suites (on UNIX and WIN32) use Perl as part of their API because of its flexibility and power. We also use Perl as part of our software distribution system here at work (on UNIX and WIN32).

        I would not want to take the UNIX flavour away from Perl because I think therein lies its power. If someone does not know UNIX commands and the like, then it's about time they learned them. After all, if someone's not willing to learn a little, why do they even bother programming or doing anything for that matter?

        Try not to think of Perl's unique features as warts but rather as beauty marks.

        Mick
        Interesting way of putting it. Though I can't say I totally agree that it's not for "ready-to-go out-of-the-box" stuff. Visual Basic + DLL Hell isn't a much more exciting prospect to look forward to. I speak from experience at my last job, where we simply could not get our internal report generation program to run on any but one of the computers in the office (because of missing DLL's and other odd errors).

        I would argue that Visual Basic + DLL Hell isn't designed to provide any solution for anyone :-D but when I said "ready-to-go out-of-the-box" I was referring to pre-compiled binaries... probably written in C or C++ or something like that. Any such generic solutions have inherent limitations because they're generic... the binary can't take into account all the little in's and out's of my particular system, and because they're precompiled they can't take into account all the intricacies of my problem at hand. A generic binary can often be a good solution to a problem, but a custom-made solution can be made perfect.

        That's where I think Perl is the bomb... it gives you a relatively easy tool to provide a perfect, customized solution. (Sure, you could write your own binary in C, but why when it's so much more fun to do it in Perl. :-D)

        Gary Blackburn
        Trained Killer

      I started with a similar background and a similar situation. So I have one question. Where did you learn chmod? I started with 3 commands, they were ls, cd, and rm.

      However I have to agree with merlyn's comments below. A language needs to have a core philosophy IMHO to succeed. And Perl's really is well summarized as the Cliff Notes version of Unix. In learning Perl, I also learned to appreciate the Unix philosophy. Now is it right in all things? No. Neither is Perl. But by keeping a coherent philsophy Perl keeps a center. And I think that matters.

(Ovid - Perl and linguistics) Re: Perl's warts
by Ovid (Cardinal) on Mar 21, 2001 at 23:06 UTC
    <pulpit>

    Well, time for me to join in the chorus of those disliking this article. One of the things that I have said, many times, is that the strongest criticisms of Perl usually come from those who do not understand Perl well. In fact, I'll go so far as to say that even those who generally do know Perl well get caught up on one thing: they fail to appreciate the linguistic nature of many Perl statements.

    Case in point. The author complains about the following snippet:

    foreach (1..10) { print }
    His argument is that for the average programmer, it doesn't appear to do anything. Well, that's true for programmers who don't appreciate the linguistic nature of Perl. Think about what happens when someone says "pick up an apple and eat it." What is "it"? We (humans) understand that "it" refers to the apple. A non-thinking computer needs to be told something that's the equivalent of "pick up the apple and eat the apple."

    The computer typically cannot infer then meaning of "it". Perl, on the other hand, can. "It" is analogous to $_. In this case, of course, the $_ is implied, but the point holds (I think). There are many examples in Perl of things like this. Understanding context is another one.

    $var = @array; ($var) = @array;
    The two lines above are a great example of context. The answer to your question depends upon how you ask it. It's the same with language. If I ask someone "Are you going to the store?", it can have different meanings depending upon the context (in this case, the emphasis). For example, if I emphasize the word "you", I'm asking if it is you who is going to the store. If I emphasize the word "store", I am asking where you are going. Those are totally different questions, yet the words are the same.

    I think this is one of the biggest stumbling blocks for new Perl programmers. Until they grasp that Perl, at one level, is fundamentally different in approach from other languages, they'll have problems and that is a huge reason why so many people whine about Perl. Perl, once you grok it, tries really hard to work the way we think, rather than the way computers think.

    </pulpit>

    Cheers,
    Ovid

    Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

Re: Perl's warts
by jmcnamara (Monsignor) on Mar 21, 2001 at 14:48 UTC
    The quoted article makes some fair points and the other sections of the tutorial seem to be well written.

    In particular I am interested in the assertion that Perl gives rise to cliquish "social clubs". Does anyone have any experience of how forums related to Python or other languages operate in comparison to PerlMonks or comp.lang.perl.misc.

    In the C hierarchies of USENET there is less acrimony than in the Perl groups. I have often wondered if this is related to the fact that it is harder to learn C and therefore harder to get to the question answering stage. Perhaps this harder earned experience leads to more discipline and restraint amongst the participants.

    In short, is there something at the heart of Perl that leads to cliques and squabbling.

    John.
    --

Re: Perl's warts
by chromatic (Archbishop) on Mar 21, 2001 at 23:44 UTC
    Let's start out with an honest examination of the author's valid points:
    • Perl is Unix distilled. Things like fork instead of threading, the IPC model, lots of functions, and a strong command-line, text-processing-filter heritage do come from its Unix background. On the plus side, learning Perl is a good way to pick up a lot of useful Unix constructs.
    • Many functions are tied to their C counterparts. Just try to do any socket programming or file locking without man pages handy. Granted, there are modules to make this easier, but they still require at least passing familiarity with the C library.
    • Dereferencing gets messy with multi-level structures. Using temporary variables helps here, and it's nice that you can drop the -> for multilevel structures, but wrapping layers of context braces around things gets old.

    And where the author is wrong:

    • Spaghetti Symbols. If the author is surprised that you don't use %hash{key} when accessing a hash element, he doesn't understand the symbols and shouldn't be talking about them. Period.
    • It's hard to read code other people write. If the author has never encountered coding standard wars in any other language, he has very limited experience. Apparently, even languages like Java and Python allow programmers to choose their own variable names -- and they don't even have to make sense with regard to the problem domain and overall metaphor! Clearly, this is too much flexibility for a programming language.
    • You have to read documentation to discern the arguments a subroutine expects. This is only a problem if you don't have code like the following:
      sub this_subroutine_takes_no_arguments_and_returns_nothing { # do something here, but nothing useful }
    • It's hard to install software on client machines. Though how he intends the client to install his software without being able to install any software is beyond me. (Yes, I'm being facetious.)

    Update: I snipped a snipe at Python. It was unfair. If you're really curious, frag quotes part of it below.

      but he offers no specifics and obviously has a bias toward Python. So be it.

      I honestly don't see this "bias" as being towards Python given the mild contents of the single paragraph where he mentions it. Not to mention this line from the first page: "But nothing is flawless — indeed, not even Perl." Unless that was sarcastic, but it doesn't seem like it to me.

      Anyway, it seems to me that whenever Perl gets critiqued, it's the same arguments that get raised (or 'misraised', such as criticisms against implicit variables). It seems like we need a Perl advocacy document (faq, howto, manpage, pod, something), to expand upon the bits of perlfaq1 that address this sort of thing. http://www.perl.org doesn't seem to have this sort of straight-forward doc on hand, just a few points directed towards IT managers.

      -- Frag.

(jeffa) Re: Perl's warts
by jeffa (Bishop) on Mar 21, 2001 at 19:51 UTC
    What really got me was when the author presented the problem of implicit variables, which can get rather messy in the wrong hands. However, his example of printing the first 10 digits, well 1 - 10, was far from complete. He completely left out this one:
    print foreach (1..10);
    which totally trumps being "two shades removed from perfectly clear" - show that code next to a C-style loop and ask people on the street which is easier to comprehend.

    On the other side, I find I do have to step back and remember who I was before I knew *some* Perl. That person was intrigued by Perl, a little scared, but its warts were a 'turn on' to me, not a critism.

    Jeff

    R-R-R--R-R-R--R-R-R--R-R-R--R-R-R--
    L-L--L-L--L-L--L-L--L-L--L-L--L-L--
    
      And for that matter, it could have simply been:
      print 1..10;
      I find the article to be quite misleading on the subject of implicit variables:
      Critics pounce here, and say that this third example is exactly what gets us into trouble with Perl. Defenders point back to the libertarian argument for self-discipline: "don't do that". But the fact is, programmers do do that, regularly. Because they can.
      "Defenders" of Perl would never say "don't do that"! Implicit variables are, ultimately, a strength of Perl. The fact that code is not immediately apparent and obvious to someone who's never troubled themselves to learn the language is not in any way an argument against it.
         MeowChow                                   
                     s aamecha.s a..a\u$&owag.print
Re: Perl's warts
by Petruchio (Vicar) on Mar 21, 2001 at 22:30 UTC
    Second, what if you wanted to pass an arbitrary or unordered list of parameters to a subroutine? Perhaps you sometimes want to supply a particular parameter on some subroutine calls, but not others. Ideally, you should be able to pass key value pairs to a subroutine, so that you can pass arbitrary value lists and assign their variable names at the same time.

    This is when you say:

    my %parameters = @_;

    which allows you to call your subroutine "ideally":

    foo( color => 'blue', size => 'really big' );

    Apparently the author is not familiar with this idiom, though it's pretty common.

    Update

    The author does indeed say,

    Sure, one could pass a reference to a hash with these key value pairs

    But that is not what I've done. I've passed an ordinary list, not a reference to an anonymous hash. That would be:

    foo ( {color => 'blue', size => 'really big'} );

    which would require the subrountine to say something like:

    my %parameters = %{+shift};
      Apparently the author is not familiar with this idiom, though it's pretty common.

      He does say

      Sure, one could pass a reference to a hash with these key value pairs, and then decode the hash inside the subroutine. Again, this is asking the programmer to do what the language should intrinsically understand: in essence, to code around the language.

      I missed this the first time I read the article. I'm kind of ambivalent about this way of thinking. I accept the argument as valid, but on the other hand it's not a whole lot of overhead (read: not much syntactic sugar required). The cookbook shows a number of compact techniques for doing this. Although when writing OO Perl, it really is a drag to have to write my $self = shift every single time.

      What I have noticed with Perl is that I figure out very few tricks myself from first principles. Just about all of my mastery has come from reading books and other people's code. The only other language that I have observed this is C++. If you haven't read the Gang of Four book, and studied how the STL works, you'll only ever skim the surface.

      --
      g r i n d e r

Re: Perl's warts
by coreolyn (Parson) on Mar 21, 2001 at 19:36 UTC

    I Gotta admit the analogy to the code and the condition of a workers desk was a fair analogy, but I'm totally lost as to why the UNIX heritage is a deal. I started in CPM and moved up the many levels of DOS then branched out into *NIX's. Perl's taught as much about *NIX and 'C' as anything else.

    What the author (and businesses) fail to see is that Perl's ability to create 'a social club air' is a positive side effect that improves participation, productivity, and professional growth. Unlike Java where obfuscating the code is a desired effect, Perl invites you to dig deeper and learn more.

    coreolyn
Re: Perl's warts
by beagle (Initiate) on Mar 22, 2001 at 02:50 UTC
    Hello Monks,

    It seems that my WDVL article has made its way here to the Monastery. As the author of said "Warts and All" piece, I wanted to make a few points. By and large, the discussion here is fair and reasonable. I don't want to respond point-by-point to every criticism and agreement -- in some cases, I've had a difficult time with topics I haven't fully mastered, in other cases criticisms are a matter of subjectivity.

    There is no motivation to bash Perl behind this article. If you look at yourself in the mirror and say "boy I'm getting a little fat around the middle", that doesn't mean you're a horrible person. But it's still important to look, and to see.

    I'm not inexperienced with Perl, as some critics jump to argue. That I might disagree with, or prefer, alternate language constructs in certain instances is not a sign of naivete. The audience for this article, and the series in which it appears, are newcomers to the language, and my perspective is geared towards that of a newcomer, and what may be troublesome. This can and does sometimes involve the way Perl uses context sensitivity and reference syntax.

    The mention of Python at the end of the article does not disclose a secret pro-Python/anti-Perl agenda or bias. It is merely a suggestion for those whose curiosities are piqued. I favor no single programming language, all are tools. The vast majority of my live, production code is written in Perl.

    Perl Monks, being an advanced breed, are certainly going to view some of these observations from a very different perspective. By the same token, Ward's Auto World is going to evaluate a particular car differently than Consumer Reports, given their audiences.

    I appreciate everyone's responses here, I take the comments and critiques to heart.

    cheers

    Aaron

      Re-reading the article from the perspective of a newcomer, I have to agree with nearly everything you've written. Context is complicated. References are an advanced concept. Learning the Unix Way To Do Things, especially with no Unix experience, will take some time.

      I disagree that these all mean the language is too difficult for beginners. It might be easier to learn a language with a small core syntax (like C or Python), but to do useful things you'll also have to get to know libraries and extensions, just so you can do something useful.

      You'll never find a language that allows you to Do Useful Things without having to learn a few things here and there.

      The same goes for natural language. You can go to the Cairo Bazaar (presuming you don't speak Arabic) and buy some things by pointing and holding up fingers and occasionally flashing the appropriate number of Egyptian Pounds. You'll have a more difficult time getting directions to your hotel if all you can do is point and grunt.

      Granted, some people aren't interested in having to learn much. And, granted, there are parts of Perl that frustrate me (the tricks you have to go through to inherit instance data in objects, for one).

      The thing that bothers me about articles like this is the idea that there's some terrible, hideous complexity lurking underneath Perl's friendly Do What I Mean facade, and that's somehow inappropriate for programmers. That's simply a matter of education -- especially when dealing with the second great hurdle of Perl, the difference between scalar and list context.

        Hello chromatic,

        Your points are well taken and valid. As the "Warts and All" article was the latest part of a now 22-part series on Perl, I think it goes without saying that the piece is not intended to scare newcomers off the language.

        Rather, those following the series have gone through a topical survey of most of the major Perl subjects -- enough to get them going writing a variety of web-based scripts. This article is like a signpost along the way, saying, in essence, "now that we've covered most of the basics, here are some things to watch out for". Necessarily, these include opinions.

        Which, again, needs to be considered in context: the series itself is titled "The Perl You Need to Know", and it has a specific conceit -- teaching Perl to developers who are goal-oriented and want to achieve a particular task, without delving more than necessary into the academics of the language.

        I fully understand that the latter point probably makes many Perl Monks cringe and shriek. I sympathize. But much as you, and I, possess interest in programming and in Perl that goes beyond merely "how do I accomplish such-and-such and move on with my life", not everyone shares that same depth of interest. They may have perfectly valid reasons. I don't feel that it benefits the Perl community to alienate these people, or to suggest that only those who want to "go all the way" need apply.

        In any case, that is the philosophy behind the "Perl You Need to Know" series, and I thought it might help to put installment 22, "Warts and All", into context.

        Once again, I do appreciate this discussion and all of your wisdom out there.

        thanks

        Aaron

      My brief exposure to Python came when I was called on to maintain a suite of programs written by someone else. It was a useful experience. I have respect for the language and the people who use it.

      Now that I've paid my compliments, I have purchased the right to turn critical - (just kidding).

      What's wrong with Python is the same as what's wrong with Perl. Not all of its advantages are always available all of the time - some features exclude others (like, nobody writing a one-liner on the command-line would regard significant whitespace to be a positive feature in that application; but, nobody likes trying to read a clutter of unfamiliar perlvars ).

      So, I do think there was a slight unfairness to the article, if you don't mind considering the observation. In the earlier articles beagle, you folks said to Perl, "Be a square!", and then "Be a circle!", and behold, Perl was adaptable to being both. Then, in Warts..., I think you've said "Aha! but Perl cannot be a square and a circle at the same time!" (Which is true - but, I have heard rumors to the effect that Larry considers it a bug, if a circle cannot also be a square, and intends to do something about that!)
      :-)

      mkmcconn

Re: Perl's warts
by jmcnamara (Monsignor) on Mar 22, 2001 at 05:32 UTC

    The majority of replies to this node seem to be from people leaping to the defence of Perl. Is this really necessary? We all understand the power and utility of Perl and in comparison the criticisms made in the article were fairly mild.

    Aaron Weiss' article is only one part of a long tutorial that the author has been publishing for almost a year. Why did this one generate so much friction?

    People who believes "Perl, Right or Wrong" should read Mark-Jason Dominus' article Why I Hate Advocacy.*

    Again, the criticisms were mild. The article is an opportunity to consider another point of view and then get on with what you were doing before.

    John.
    --
    *The "someone" mentioned in the article who "showed up in comp.lang.perl.misc" is a well-known Perl Monk

      I have no problem with people coming up with legitimate issues with Perl. There are many issues that I could come up with that demonstrates a particular weakness in some area or other. The problem I had with this person's criticism, and the problem I have with most criticism of Perl, is that the author of the criticism is trying to compare apples and oranges and complaining that the orange isn't red and that its skin can't be easily bitten through.

      Perl, as I mentioned, is fundamentally different from most languages in its approach to programming. It tries to think like you do. One of my biggest complaints regarding other languages is when they try to think like I do, they screw it up. Take VBScript's CDate function, for example:

      myDate = Cdate( someval )
      The format of "someval" is supposed to be determined by my computer's locale settings. If that setting requires a mm/dd/yy format and I pass that in, all's well in VBScript world. What if I accidentally pass "31/12/00"? VBScript figures that "31" is too large to be a month, so it treats it like a day and the resulting date become December 31st, 2000. What if I pass a null value? The date is set to December, 31, 1899. Well, that's just great. Now I have to write a bunch of extra validation to get around VBScript second-guessing what I intend.

      Perl, on the other hand, seems to guess intelligently what I want. That's because of how it was designed. I can't think of any other language that I've worked with which does this.

      Like I said, there are valid criticisms of Perl. If you need to write device drivers, GUI apps, or need raw speed, Perl's not for you. Perl even has problems on its own. Caller, for example, doesn't always work as advertised. OO-Perl is SLOW.

      In short, Perl has legitimate problems and critics have every right to complain. However, if all they do is come up with the same tired, misunderstood arguments, then Perl advocates are going to point this out.

      Please don't take this as the start of a flame war. I'm not trying to get anyone's goat and I apologize in advance if I have.

      Cheers,
      Ovid

      Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

Re: Perl's warts
by jlawrenc (Scribe) on Mar 22, 2001 at 08:21 UTC
    removed
      jlawrenc,

      I'll gladly point it out -- I've also written instructional materials on JavaScript, yes. The implication that this makes me a JavaScript advocate completely escapes me. The insinuation that, because JavaScript is a weak language, this reflects badly on my coverage of Perl is a strawman.

      JavaScript is a terribly flawed language. That has no relevance here. Education is not advocacy.

      cheers

      Aaron

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://65986]
Approved by root
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others pondering the Monastery: (4)
As of 2024-03-29 12:01 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found