Perl Myths Talk 2009

http://www.slideshare.net/Tim.Bunce/perl-myths-200909

by bigmac • 17 years ago

43 61 17 years ago

skolor2• 17 years ago

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• 17 years ago

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...

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

skolor2• 17 years ago

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

jlc• 17 years ago

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

berntb13• 17 years ago

IMHO, the best part with Perl is the community (CPAN is a result of that) -- and the worst part is the relentless trolling on web sites like this...

Since Ruby/Python/Perl are really similar, I'd recommend that you learn something completely different instead.

Disclaimer: I like Perl. What makes Perl fun for me is to a large part that the linguistics influence results in Perl breaking most "normal" laws for programming language design, but still works. I go to work smiling.

jrockway7• 17 years ago

I don't think it's a lingusitics thing, rather, Perl was not designed to be limited like other popular languages were. Larry never sat down and said, "I am the only person that is possibly smart enough to understand this concept, so I am not going to add it to the language". (Java and PHP's designers did. Look what that got them...)

akl• 17 years ago

I'll differ from berntb - you should learn Perl exactly because it's fairly similar to those languages you already know, and the effort required to do so will be minimal.

You may not end up using it all that frequently, but an hour or two seeing how another programming language does something is usually interesting perspective, imo.

mahmud• 17 years ago

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_fish2• 17 years ago

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

Goladus12• 17 years ago

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.

chromatic5• 17 years ago

> 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.)

Goladus12• 17 years ago

Who cares? Why does that matter?

Ask the guy who made the slides debunking the "myth".

This is not about hiring or recruiting people. This is simply about language readability.

I have been using perl longer than any other major language except C, and I still have to review basic syntax crap every time I have to read perl code.

... just like every other programming language ever written.

Not true. Perl requires significantly more language-specific trivia than most other languages, and for marginal benefit. Differentiation between scalar, list, and hash is not especially useful most of the time. It doesn't significantly help readability (or writability) and makes the code more complicated.

A nonstandard default array index is one piece of trivia. In fact, it can be deduced from the example I gave, and if you aren't sure you can check. I highlighted several in that one perl example.

EliAndrewC2• 17 years ago

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.

acg4• 17 years ago

Surely being able to read the code makes it easy to maintain: the reason you might use perl is for existing libraries/support and the level of abstraction available. Language design has a direct impact in maintainability.

mechanical_fish2• 17 years ago

Do you really hire or recruit people to work on your projects merely on the basis of reading code with no problem?

No, but everyone we hire must first pass through that stage. To become a Perl expert one must first spend quite some time as a Perl beginner.

zaphar2• 17 years ago

seriously?

  You have to know perl's control flow ("unless"

unless is that difficult to understand? Its plain english has totally understandable semantics without reading a lick of documentation about perl.

  you have to know perl references(->)

This is just like C++ and an arrow is pretty dang readable and plain to me. Perhaps even more informative than a period.

   you have to know perl's variable prefixes.

I might be convinced to give you this one but really reading the perl code isn't that difficult even with 3 extra symbols to know. Even not knowing the symbols the code example you show is both readable and concise.

Yes perl may have some quirks but for the most part it "Does exactly what you think it would by reading it". That was a design goal of the language after all.

Of course anyone could write perl code that is incomprehensible and makes use of perls semantics to obfuscate their purpose (using every example you cite) but that is with effort on their part and significant effort in some cases. And just to drive the point home may I present lua code that is way harder to read than any perl code I've ever seen even in an obfuscated perl contest: http://www.corsix.org/content/obfuscated-lua

To reiterate, no one in their right mind would right lua code like that except as an exercize and experiment. Same thing goes for perl. The perl code you show above is perfectly readable. Unless does exactly what you expect it to. -> arrows mean exactly what you would expect them to. Arrays start at 0 exactly like most programmers expect them to. and on top of that its readable. The only point you bring up that I think supports you argument is the @_ and argument passing semantics. But again that's only one and as another poster pointed out Lua has at least one also in it's array indexing.

Goladus12• 17 years ago

I never said that code wasn't readable at all. But it's more complicated than the lua code and not as easy to read. I've never used Lua in my life but barely have to think about reading it. The questions I do have are keywords that are easy to search for in documentation. With the perl, I have to double-check and make sure there's nothing funny going on, and that is a VERY simple piece of code. If you look at another function in the same program (which I didn't use because the lua version is recursive which you could do in perl if you wanted), you'll see some non-obfuscated perl code that is a much better example of the pain of reading perl if you are not familiar with its idiosyncrasies. Not only do you have to trace through every step of each loop, you have to figure out what the double-asterisk syntax means and the bracket syntax.

    sub bottom_up_tree {
        my($depth) = @_;
    
        my @pool;
        push @pool, [undef, undef, -$_] foreach 0..2**$depth-1;
    
        foreach my $exponent (reverse(0..($depth-1))) {
            push @pool, [reverse(splice(@pool, 0, 2)), $_]
                           foreach reverse(-(2**$exponent-1) .. 0);
        }
        return $pool[0];
    }

igouy• 17 years ago

+1 for intelligent use of benchmarks game source code

jrockway7• 17 years ago

No offense, but your "tree == 3" is hard to read. Most people assume == means "equal to", and containers cannot be equal to the integer 3.

I can guess that you mean the length, but if that's the case, why don't you write "length(tree) == 3"? If we are just going to guess to understand, then we have the same problem with Lua that we have with Perl. With Perl, you can guess that $array->[number] is an array lookup, that the $ in "$foo" is essentially meaningless, and so on.

In other words, Lua and Perl are both hard to read.

bkovitz2• 17 years ago

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.

chromatic5• 17 years ago

> 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.

Perl Myths Talk 2009

Related Stories