

Perl Myths Talk 2009 - bigmac
http://www.slideshare.net/Tim.Bunce/perl-myths-200909

======
Goladus
So perl is not hard to read because there's a book about best practices, and
optional libraries that enforce coding styles?

I respectfully disagree. Reading perl requires understanding a significant
amount of perl-specific trivia for any given block of code, that's why it is
hard to read.

<http://shootout.alioth.debian.org/> Binary trees problem.

Perl:

    
    
        sub item_check {
            my ($tree) = @_;
        
            return $tree->[2] unless (defined $tree->[0]);
            return $tree->[2] + item_check($tree->[0]) - item_check($tree->[1]);
        }
    

Lua:

    
    
        local function ItemCheck(tree)
          if tree == 3 then
            return tree[1] + ItemCheck(tree[2]) - ItemCheck(tree[3])
          else
            return tree[1]
          end
        end
    

These demonstrate the REALITY of what it's like reading perl code vs. other
languages. Count the number of different symbols you must know in order to
understand the perl code, versus the number of symbols you must know to
understand the lua code. Anyone familiar with functions, variables, and
standard control flow will be able to read the lua with no problem. If you
look at other code snippets, like Javascript and C#, you'd amend the comment
to say that anyone familiar with methods and object-oriented programming will
be able to read the code with no problem.

With perl, you have to know perl. You have to know perl's control flow
("unless"), you have to know perl references(->), you have to know perl's
parameter passing semantics and the meaning of @_, and you have to know perl's
variable prefixes.

That's why perl is hard to read. That's why people who use perl all the time
don't understand why it drives everyone else crazy. They have all that crap in
their heads already. You never smell your own bad breath. Style guides don't
fix this problem.

~~~
chromatic
> Anyone familiar with functions and standard control flow will be able to
> read the lua with no problem.

Who cares? Why does that matter? Do you really hire or recruit people to work
on your projects merely on the basis of _reading_ code with no problem?

I care a lot more about being able to understand the problem domain and
maintain the code than merely being able to read it by way of familiarity with
an Algol-derived language with class-based OO support and dynamic typing.

> With perl, you have to know perl.

... just like every other programming language ever written. (Oops! Lua's
array indices customarily start at one; good luck with those fencepost errors
by people who can merely _read_ the Lua code but don't know Lua.)

~~~
EliAndrewC
My main problem with Perl is references and contexts. Most of the experienced
programmers I work with find themselves unable to write or debug code that
requires the use of these Perl concepts.

For example, my co-workers and I find it easy and intuitive to work with lists
in Python

    
    
        xs = [5, 6]
        xs.append(7)
        print xs[2]     # prints 7
        xs.append([])   # easy to append lists to other lists
        xs[3].append(6) # easy to append to the inner list
        some_func(12, "hello", xs, True) # easy to pass to a function
    

In Perl this would be way more complicated for reasons that are obvious to
someone who knows Perl well, but a mystery to people who use Perl casually.

    
    
        $xs = [5, 6];       # must be a reference
        push @$xs, 7        # deference $xs as a list
        print "$xs->[2]\n"  # still not too bad
        push @$xs, []       # add a nested list reference
        push @{$xs->[3]}, 6 # omgwtf?!
        some_func(12, "hello", $xs, 1) # not too bad
    

Understanding "push @{$xs->[3]}, 6" is asking a lot just to deal with a nested
list that you need to pass to a function, especially compared to the easily
understandable "xs[3].append(6)". For that matter, it's asking a lot to make
you understand the difference between a list and a list reference. It's asking
a lot to ask to understand the concept of "evaluating in a ___ context",
especially when other languages manage to do the same things without these
concepts.

~~~
kingkongrevenge
> push @{$xs->[3]}, 6 # omgwtf?!

Maybe the first time you see it, for at most two minutes once in your entire
life.

I kind of wonder if the people who freak out about this syntax stuff have ever
studied a foreign language. Do they scream and run out of the room every time
they hit an alien grammar construct?

~~~
Goladus
It still slows you down if you don't use it all the time. Unless you're
someone who has been programming in perl every day for years at a time, then
that line is most assuredly not something that takes 2 seconds to learn and
you'll remember forever. Seeing something like that while you are reading code
means you have to STOP what you were reading, patiently sort it out the syntax
and refer to the documentation to be sure you haven't made any mistaken
assumptions, and THEN move on. Even if that only takes a couple of minutes, it
adds to the frustration level of reading code. And the point is that it is
perl-specific. It doesn't happen with most other code that I have to read.

~~~
jrockway
I rarely write "push @$ref" expressions, but they don't slow me when I see
them. It is blindingly obvious to me what is happening here. I have never read
a manual entry that specifically documents this situation, either... it just
makes sense from what I know about push and what I know about references.

(Yes, you need to learn Perl to know Perl. Please let me know what programming
language you don't need to learn to use.)

~~~
Goladus
_Please let me know what programming language you don't need to learn to use._

I have frequently been able to debug or explain unexpected behavior in
programs written in languages I had never used before. Javascript, C#, Python,
windows shell scripts, PHP, ASP, Emacs Lisp, and Visual Basic 6.0.

Common Lisp, C, and bash are the only languages I had to really "learn" before
I could read code. Perl is the only language I feel like I have to re-learn
every single time I have to read it.

------
skolor
As someone recently getting into using Perl, the Guidelines and Tools Slide
(#36) was amazingly useful. Its got a whole list of things I've wanted, but
didn't think to go out and look for yet. (Primarily tools/books on writing
good perl or testing it).

~~~
draegtun
I didn't see it in the slides but it maybe Tim being a bit modest because he
didn't mention NYTProf:

* <http://search.cpan.org/dist/Devel-NYTProf/>

* [http://blog.timbunce.org/2008/07/15/nytprof-v2-a-major-advan...](http://blog.timbunce.org/2008/07/15/nytprof-v2-a-major-advance-in-perl-profilers/)

For more testing stuff checkout the Perl5 wiki:
<http://www.perlfoundation.org/perl5/index.cgi?testing>

~~~
skolor
He mentioned Devel::*, and showed screenshots of NYTProf, but didn't mention
it by name. Thanks for pointing it out.

------
bkovitz
The debunking of the myth of unreadability omitted something of concern to me:
How much Perl code "in the wild" uses those best practices?

I have no doubt that Perl can be written in a disciplined and reasonable
manner, readable to people familiar with its idioms, and not especially bug-
prone. I cringe every time I come across Perl code because I've never actually
come across any real Perl that's written that way. Or maybe I have, but I've
always gotten discouraged with the language before mastering enough of the
syntax to master the idioms, so I can't really tell.

This is not a problem with Python. It's easy to learn to read Python, and I
have yet to come across really _bad_ Python in practice. Good coding seems to
flow easily from the way the language is made.

~~~
chromatic
> How much Perl code "in the wild" uses those best practices?

Not enough.

Consider this, though: how much Perl code "in the wild" is the result of
programming novices who learned just enough Perl to do a job without actually
having to learn how to program or how to write Perl code well or how to write
maintainable code?

I suspect that it's far more than you might think.

If that's true, then the complaint is that Perl is _too_ easy to write.

------
jlc
Interesting. I know python and ruby. Now I'm wondering if it's worth my time
to learn perl.

~~~
mahmud
If you know python and ruby, learn something that I will actually
improve/change your programming: Scheme, ML, Prolog, Smalltalk, Common Lisp,
Haskell, Mozart/Oz, or Forth.

Python and Ruby are not that different, and neither is that different from
Perl.

~~~
mechanical_fish
You left out Javascript and C, which are even more obvious low-hanging fruit,
though not necessarily as mind-expanding.

~~~
jrockway
Javascript is essentially a less-functional version of Python, Perl, and Ruby
-- but with many annoying bugs. (Variable scoping, for one.)

If you want to learn about prototype-based OO systems, fine, but there's a
reason that only JavaScript (and Self) use prototype-based OO :P

C should be learned so that you are not tempted to ever use it for anything
important.

