Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl: the Markov chain saw

Re: disadvantages of perl

by ELISHEVA (Prior)
on Jul 02, 2009 at 13:12 UTC ( #776738=note: print w/replies, xml ) Need Help??

in reply to disadvantages of perl

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

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://776738]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others browsing the Monastery: (9)
As of 2018-06-19 13:22 GMT
Find Nodes?
    Voting Booth?
    Should cpanminus be part of the standard Perl release?

    Results (114 votes). Check out past polls.