Beefy Boxes and Bandwidth Generously Provided by pair Networks
Problems? Is your data what you think it is?
 
PerlMonks  

disadvantages of perl

by perldesire (Scribe)
on Jul 02, 2009 at 10:19 UTC ( #776689=perlquestion: print w/ replies, xml ) Need Help??
perldesire has asked for the wisdom of the Perl Monks concerning the following question:

Hi monks,

One of my friend questioned me "what are the disadvantages in perl".. I could not list out... :(

I think definitely i can get best answers from perl monks...

Kindly give your sound data on this....

Comment on disadvantages of perl
Re: disadvantages of perl
by Anonymous Monk on Jul 02, 2009 at 10:38 UTC
      The linked doc says: "The article should be up to date as of Python 1.5.2 and Perl 5.005."

      That means it's a tad less than up-to-date as of 5.10, etc.

      Not only is the article three, or four if count 5.9, major releases out of date, it's a pretty breezy and unconvincing critique based on a single, largely idiomatic, sub and format which in 11 years of Perl I've never used once. I've seen this same style of critique of Perl in particular from Python devs. Perhaps with time, compassion, and a little fluvoxamine they can get over it.

      That said, it does bring up the actual major weakness of Perl which is, almost paradoxically, its greatest strength as I see it. It's overly flexible. You can write crazy, illegible nonsense because you can code stream of consciousness / this is how it fell together after I tried the first 15 things that made sense for the first 15 things in my way instead of trying to see the problem holistically.

      Perl is so good at solving problems in nearly any fashion the solver devises that it becomes an albatross on the next dev too often.

      I've had to wear a lot of albatrosses too but I still wouldn't trade it for anything.

Re: disadvantages of perl
by tweetiepooh (Friar) on Jul 02, 2009 at 10:39 UTC
    This may sound trite but often the advantages and disadvantages of a programming language are the same depending on you point of view.

      Trite in general, perhaps, but, in this particular case, TIMTOWTDI is the greatest strength of Perl to those who like the flexibility and its greatest weakness to those who want to see one and only one way to do anything.
Re: disadvantages of perl
by jettero (Monsignor) on Jul 02, 2009 at 10:40 UTC
    I find most of my co-workers, who recently started using Perl, get rather frustrated with all the funny symbols. Also, the OOP is kinda weak. Moose fixes that, but costs a lot to load up and came a little late in the game.

    I don't find these things so bad personally, but some people do. The real question is: why come to a site full of Perl fans to see what's so bad about Perl? We like it. Try the Python forums. They'll have a list of complaints.

    -Paul

      The real question is: why come to a site full of Perl fans to see what's so bad about Perl?

      I find 2 reasons:

      • Many Perl newcomers here at the monastery can give valuable experiences on what they are finding hard to learn of Perl
      • Also, the weak points of any subject should be spotted by experts in that subject, and perlmonks has more experts in Perl than a Python forum

      Perl is great... but not perfect, that is what Perl6 is all about, no?

      citromatik

      Also, the OOP is kinda weak. Moose fixes that, but costs a lot to load up and came a little late in the game.

      Better late then never :)

      -stvn

      Great post, but I have to nitpick, with the right incantations Moose start up cost is much less than it originally was. Even less once they get some stuff moved to C/XS.

      meh.
Re: disadvantages of perl
by Arunbear (Parson) on Jul 02, 2009 at 11:11 UTC
    • It makes programming fun
    • It allows things that should be easy to be done easily
    • It makes the impossible possible
    • It encourages its users to learn and broaden their horizons
    • Lots of 3rd party modules, i.e. CPAN
    • It evolves, i.e. Perl 4 -> Perl 5 -> Perl 6
    • It lets you impress your significant other
    e.t.c, e.t.c
Re: disadvantages of perl
by JavaFan (Canon) on Jul 02, 2009 at 12:04 UTC
    That's a very subjective question. It's also a question, or a variant of it ("what don't you like about Perl, and how would you change it?"), I often ask at an interview. There's hardly a wrong answer to it - but not being able to list any drawbacks is one of the worst ways to answer the question.
Re: disadvantages of perl
by parv (Priest) on Jul 02, 2009 at 12:32 UTC

    Search http://use.perl.org/ ("Journal" section) for "What I hate about Perl", "things that I hate about Perl", or other similar phrases.

    On another thought, avoid the atrocious search result page on use.perl itself, try Google instead.

Re: disadvantages of perl
by ELISHEVA (Prior) on Jul 02, 2009 at 13:12 UTC

    Re: What's wrong with Perl. The writer also is apparently struggling with some key concepts, as in, "I tried using references, but never made it work.". His discussion of lists within lists furthers that point: in his final solution for lists within lists (@b=([(0.8,0.9,1)],2,3,4);,[(...)] is redundant. [...] would suffice. The writer's problems with regards to lists of lists appears to come from mixing up the Perl and Lisp meaning of (...)

    Which gets me to one of the main weaknesses of Perl as I see it: Perlopia - the tendency of some to assume DWIM (do what I mean) means do-it-the-way-Perl-does-it. There are some special ways Perl thinks about language that work quite well and there are others that violate most of my intuitions from all the other languages I've learned so far (which for purposes of illustrating range include among them: C, C++, Elisp, Java, Visual Basic, bash, DOS, awk, Pascal, PHP, Javascript).

    One Perlish idea that works is context sensitivity. It is tricky to learn properly, but, once learned, it allows for quick and expressive programming. I think it works because context-sensitivity fits nicely into the way our brains process natural language.

    One Perlish idea that doesn't work (just my opinion) is the approach to variable scoping. Variables don't come naturally. They are something most of us have to learn to work with. The analytical training of an 8th or 9th grade algebra class is less about quadratic equations (which most people forget) and more about learning how to deal mentally with missing information and symbols that represent a bounded but as yet unknown range of values. Natural language is just not much help here. The closest analog we have is the pronoun.

    When we can't rely on natural langauge, we rely on past technical training. For 20+ years I was able to get by on a single mental model of scoping. This model said the names and addresses of variables in an inner block (or lower on the stack) hide the names of variables in outer blocks. If I made a closure it used whatever version of the variable happened to be in play in the scope where the closure was generated. Somewhere in the back of my mind I knew that there were several strategies languages used to create this effect, but I could ignore it and treat it as an implementation detail for the curious.

    Not so in Perl. As was made amply clear in this thread, you simply cannot understand the behavior of variables inside closures without understanding that Perl has two different mechanisms for scoping variables. In Perl the implementation details matter. I have yet to be convinced that having to know such implementation details should matter. So far (for me) this feature of Perl has been primarily the source of curious bugs. I might be convinced if someone could show me that such complexity allows me to make a higher level task easier to implement, but that hasn't happened yet.

    Best, beth

Re: disadvantages of perl
by zgrim (Friar) on Jul 02, 2009 at 14:22 UTC
    I'm nobody, but hey, I'll give it a shot.

    The C API is a mess. Ok, say you identified the few bottlenecks of your code with great profilers like NYTProf, now you think "i'll write that in C". Except, see, you'd need to be a freakin genious to get that right. The Perl C API should have an explicit motto like "Not for mere mortals" or "Abandon all hope ye who enter here". Or something. To program non-trivial stuff with its C API, you *have* to know all the implementation details of Perl. You know, all the stuff grown into it since 1994. Or something.

    Speed. We lose each day on the speed front. It's not the late 90s anymore. :(

    Multiple cores. perl copies waaay too much data around. Can not be told to do otherwise. Readonly is not readonly. Fork COW ? Exploding RAM. Given the rise of multiple cores this is... unfortunate.


    Syntax. I need to repeat myself way too much. use warnings, strict, feature, shift, ref... think for example, params validation, say, is_non_empty_hashref,


    # WTF if ( defined $r && ref $r && ref $r eq 'HASH' && keys %$r ) { ... }

    Sigils are OK. IMHO, their only problem is that deep structures can become syntax horrors. I think explicit aliasing in the core could reduce this one.


    Exposed internals. I know about the guts. I'd like to not care. KTHX.
    # XXX PerlIO: Wide character... binmode $socket, utf8::is_utf8( $data ) ? ':utf8', ':raw';
    Context gotchas! Quick, tell me the difference between lists and arrays. You think you wouldn't need to know ? wantarray() ? Oh...

    Let me try to sum things up. Yes, i'd love the language to have macros, a speed{y,ier} VM, a clean and well-documented API, powerful function signatures, a bit-more-than-minimal OO, immutability, cached compilations (ie. working bytecode), assertions, inline expansions. Type hinting, for speed, would be the sugar on top. What did i miss ? Ah, *way-too-many-ways-to-do-stuff* !! :) I'd like the Core to HLP ME THRE PLIZ.

    Yes, i know about the Promised Land. Oh, the Dream... Except, you know, Perl 6 is/will be *another* language. :)
    I love Perl 5. It gets many things more than right. I like the people. I like the culture. Did i say i love perl ? And after it drives me nuts, i love it more, because that usually means i find "better" ways to do the stuff i was doing. And then i hate it again. And then... yes, sorry, it's a nice day here at the Asylum...


    Update: del bad, pathological code, for spawning responses undermining the point :)

    -- 
    
    perl -MLWP::Simple -e'print$_[rand(split(q|%%\n|, get(q=http://cpan.org/misc/japh=)))]'
      # WTF if ( defined $r && ref $r && ref $r eq 'HASH' && keys %$r ) { ... }
      indeed
      if( $r and UNIVERSAL::isa($r,'HASH') and %$r ) { ... }
      Exposed internals. I know about the guts. I'd like to not care. KTHX. ..

      You don't need to know about the guts, but you do need to encode your data, if you care about its encoding.

        Should be
        if( UNIVERSAL::isa($r,'HASH') and %$r ) { ... }

        You don't need to know about the guts, but you do need to encode your data, if you care about its encoding.

        Unfortunately, you do in some circumstances. For example, the only difference in between $up and $dn in the following is the internal storage format, yet they differ in output.

        $\ = "\n"; utf8::downgrade $dn = chr(0xC9); utf8::upgrade $up = chr(0xC9); # <5.10 >=5.10 print pack('A', $dn) eq chr(0xC9) ?1:0; # 1 1 print pack('A', $up) eq chr(0xC9) ?1:0; # 0 1 print $dn =~ /\w/ ?1:0; # 0 print $up =~ /\w/ ?1:0; # 1

        They are being fixed. As you can see, pack no longer depends on the internal encoding since 5.10.0. Other discrepencies such as /\w/ are being fixed too.

      if ( defined $r && ref $r && ref $r eq 'HASH' && keys %$r ) { ... }
      There's no need to write it like that. 'ref' never returns an undefined variable. You may write this as:
      if (ref($r || "") eq 'HASH' && keys %$r) { ... }
      Or, after turning off the appropriate warning:
      if (ref $r eq 'HASH' && keys %$r) { ... }
      which isn't too bad.

      Note that it won't enter the block if $r is a blessed hash, but that I consider a feature. (Otherwise, replace ref with Scalar::Util::reftype).

      Exposed internals. I know about the guts. I'd like to not care. KTHX.

      # XXX PerlIO: Wide character... binmode $socket, utf8::is_utf8( $data ) ? ':utf8', ':raw';

      While the status of the UTF8 flag currently needs to be known and manipulated in some situations (bad!), that's not one of them. The UTF8 flag offers no indication as to whether something needs to be encoded or not. See Re: Decoding, Encoding string, how to? (internal encoding)

Re: disadvantages of perl
by raisputin (Scribe) on Jul 02, 2009 at 17:25 UTC
    I am also a nobody as someone else previously said but this is what I have to say about perl.

    1) sometimes it is difficult to know what you need as far as modules are concerned, but I think this is pretty similar in any language.

    2) some of the documentation for <insert module namehere> is less than helpful.

    3) it is almost too easy, even for a beginner to write code that is very functional. the "problem" with this is that it might not be using any decent programming practices. I am probably guilty of this more than I know.

    4) it seems that I can accomplish anything with perl. I am not sure what it is about perl, but it is just so easy to use that I feel programmatically (is that a word) empowered. My confidence grows daily.

    5) perlmonks.org - this damned site is just too helpful even when a n00b like me submits spaghetti code :) LOL

    6) Seriously, there is no disadvantage that I can think of when using perl. I have tried to learn a couple other programming languages and quite frankly I just don't get it most of the time. perl is like the game of go. Minutes to learn, and years to master :)

Re: disadvantages of perl
by SuicideJunkie (Priest) on Jul 02, 2009 at 17:35 UTC
    Does anyone else find the debugger a bit claustrophobic? I tend to just use prints and code inspection instead.
    On the upside, I suspect that it helps encourage me (with a big stick!) to keep the code clear and easy to follow at least. :)
Re: disadvantages of perl
by leocharre (Priest) on Jul 02, 2009 at 18:34 UTC
    It's "slow".
    That's the only disadvantage.
Re: disadvantages of perl
by elTriberium (Friar) on Jul 02, 2009 at 19:32 UTC
    I "had" to learn Perl during my work, but I really like the language now.

    However, there are several aspects, which I don't like that much:

    1) Perl on Windows. I don't see any "real" applications being written in Perl for Windows, probably in part because you have to install Perl on Windows first. Linux usually comes with a Perl installation. On my local Windows machine I don't even have Perl installed (because I don't need it there, which - for me - also shows that it's not being used that much on Windows).

    2) CPAN is great. What is not so great in my opinion is the documentation and usage of the cpan shell. I often saw questions on perlmonks on how to install / uninstall specific versions of a module. Sure, there are ways to do that, but it's not really trivial.

    3) Threads in Perl. Even with Perl 5.10 I often see a ""*** glibc detected *** double free or corruption" when using threads. I suspect that this is related to some older versions of CPAN modules that I'm using, but it's just for my specific situation something I don't like about Perl. This is why I ported many of my perl scripts to use processes / fork instead of threads.

    4) Some of the general language constructs. I don't know about all the special symbols and in general stick to a more "C-like" programming style in Perl. I also don't like Perl's built-in OOP mechanism, which is why I use Moose. So there are ways to use Perl the way I'd like to use it, but it also means that it sometimes hard for me to read and understand existing Perl code.

    I now use Perl a lot and I think for certain problems it's the "best" language to use. However, the problems I mentioned above (and some more) don't make me feel like it's the "perfect" programming language.

      1) I'm not sure what you call a "real" application, but I've written a number of significant applications using Perl and Tk that are used daily by a number of people or are major parts of our corporate software deployment process. They look awful (Tk's like that), but were quick to write, are easy to maintain and are very appropriate to their purpose. Oh, and they are all running on Windows of course.

      There is no "perfect" language, although there are languages that are well suited to particular application domains. Perl is a very good text processing and prototyping language. It is not such a good general GUI application development language, although it performs really well in that role for small applications if you don't care much about the "look". Perl can be very portable across systems.


      True laziness is hard work

        I don't doubt that it can be a good approach to develop certain applications for Windows in Perl.

        It's more like a question I'm asking myself why I never got in contact with Perl when using Windows. All of the applications I use on Windows are either binaries (probably written in C, C++, C#, ...) or java-based.

        On the other hand on Linux I often see tools written in Perl. Most of them run on the shell and don't provide a GUI. So maybe that's the main reason here: GUI development isn't that easy / good / advanced in Perl.

        Don't get me wrong: I'm not stating that developing Perl on Windows is bad, I'd more like to state my own experience and maybe get some input from others to understand if I have some misconceptions there.

Re: disadvantages of perl
by LanX (Canon) on Jul 03, 2009 at 00:32 UTC
    Structures defaulting to flat lists!

    @Arrays and %Hashes act per default as list not as reference which makes many useful things complicated and only some other things easy.

    For instance @a=(@b,@c) is not a nested structure but a flattend list, so you better choose $a=[$b,$c].

    So if your working with nested structures or your passing structure in and out subroutines you need to switch to references, where you need much more typing, and you loose the "documenting" advantage of sigils.

    Especially if you return large arrays out of a sub as a ref to avoid copying, you cant alias them to a normal @array you need a $arr_ref.

    e.g. this doesn't work:

    my (*arr)= ret_arr_ref(); print @arr

    Even if you decide as a consequence to constantly work with references and you enjoy dereferencing with the arrow-operator it's annoying that you can't use the special commands for arrays and hashes directly. You need to put extra dereferencing and often additionally enclosing curlies:

     push @{ $hash_ref->{key_to_arr} }, "elem"

    instead of

     push $hash_ref->{key_to_arr}, "elem"

    Personally I think this is the biggest obstacle for beginners, a complication where many decide to look for a more intuitive language (in this aspect)!

    Cheers Rolf

      You seem to be viewing (...) as a data structure. That isn't at all unreasonable, but it is not the only meaning that we commonly give to (...). Perl's definition of (...) is drawn from another part of life: math. A better mental model would be the parenthesis in math statement: (3+4)*(6+10). It is simply a way of grouping things to indicate the order in which you want them processed.

      Merely being an ordered collection doesn't determine how we'll use it. There are many different things one can do with groupings: nest them, concatenate them, visit their members one by one. In Perl which action you want to take on the grouping depends entirely on context. For example, when you use it in a for loop, the for loop processes the elements in order (just as you asked). And when you assign it to an array, Perl adds each element to the array in order, just as you asked. Nesting parenthesis doesn't change the treatment any more than does ((3+4))*((6+10)). The elements still get added in the order you requested.

      I had little trouble grasping Perl's approach to parenthesis because my interest in mathematics and my interest in programming are closely related. Perl's syntax was natural for me. But I fully appreciate that others have come to programming from different directions than I. They are used to giving symbols other meanings than I give them.

      It all comes back to the the vagaries of DWIM (Do What I Mean). As tweetiepooh has pointed out a language's strengths are also its weaknesses. DWIM, or as Larry Wall calls it "The Principle of Least Surprise", is rather subjective:

      ... The question is, whose surprise are you pessimizing? Experts are surprised by different things than beginners. People who are trying to grow small programs into large programs are surprised by different things than people who design their programs large to begin with.

      For instance, I think it's a violation of the Beginner's Principle of Least Surprise to make everything an object. To a beginner, a number is just a number. A string is a string. They may well be objects as far as the computer is concerned, and it's even fine for experts to treat them as objects. But premature OO is a speed bump in the novice's onramp.

      Interview with Larry Wall, Slashdot, Sept, 2002

      In a language where DWIM rules, we need to be very sensitive to the fact that not all of us are thinking the same thing when we get to the word "mean". If you are teaching Perl or helping an organization develop Perl skills it is very important to be sensitive to this issue or else you will end up with confused frustrated programmers for whom Perl definitely does not do what they mean.

      Best, beth

        Hi Beth

        The OP was asking for disadvantages of Perl, and I was giving him a common view. An easy thing is only complicated to achieve, which violates a mantra of Perl.

        In fact this criticism is so widespread that Larry already changed this design in Perl 6 (almost a decade ago): @ and % default to references and the comma operator is changed.

        IMHO that will (sadly) also be the biggest source of confusion for migrating to Perl6.

        To be clear: I like flattened list, just shouldn't be the default.

        Cheers Rolf

Re: disadvantages of perl
by targetsmart (Curate) on Jul 03, 2009 at 07:04 UTC
    This is purely my opinion on what I think as disadvantages, suggestions/help/pointers welcome

    1) sometimes I badly wanted to use threads, but forced to use fork, for every fork a new interpreter gets launched; eats more memory.

    2) I suffered from too many alternatives on CPAN for a single purpose. Doing a analysis on those to choose right one, really takes time for me.

    3) For beginners there are numerous tutorials available to pick-up the language, but after spending considerable amount of time as beginner, It is very difficult to find a way to climb up the perl master/wizard stage(I know it is tough), If someone wants to become a master from intermediate stage it is quite difficult,(might be true with other languages too), there is no defined path to master Perl AFAIK, if we stay in touch with the language for years, might be we may come to know via experience.

    4) I really wanted to write code in Perl, compile it and want to run in a VM(like jython for python), so far it was not possible. (eagerly waiting for an official full stable release of perl 6).

    this list can grow if I spent more time on this point.
    but one question arises in mind, what I have done about it so far, thirst is there, but thrive is not there as vigorous as it should be, i think for all the disadvantages there exist a workaround, which with clear attention & focus it can be spotted out, we can continue to yell like 'this is not there', 'this is not there', but what have we done about it, I am benefited 99% of the times from Perl rather than worried about lack of certain features, why can't we join the development and contribute it to the perl society.
    I am forever indebted to perl and its society for giving such an elegant language and relevant knowledge for free and continuing to stay as free.


    Vivek
    -- 'I' am not the body, 'I' am the 'soul', which has no beginning or no end, no attachment or no aversion, nothing to attain or lose.
Re: disadvantages of perl
by dsheroh (Parson) on Jul 03, 2009 at 12:09 UTC
    I'd say that the biggest disadvantage to Perl is its history. There are just way, way too many "tutorials" out there based on outdated versions of perl and perpetuating bad, unsafe programming practices. Aside from misleading those who don't know enough Perl to know that there are better ways to write it, they also do horrible things to Perl's reputation (and, in some cases, that even spills over to harm the reputation of those who write in Perl).
Re: disadvantages of perl
by dec (Beadle) on Aug 16, 2009 at 01:21 UTC
    Hot on the heels of someone asking what is the advantage of perl, here is someone asking what the disadvantages are. Here are some I can think of:
    • perl can't run other languages:
    • It can't build a project (ExtUtils::MakeMaker)
    • It's inefficient (perlxstut)
    • It can't make tea.
    • This "perl" of which you speak might not be the Perl interpreter, but simply another program with the same name.

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others pondering the Monastery: (12)
As of 2014-09-17 17:20 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    How do you remember the number of days in each month?











    Results (92 votes), past polls