

Perl tutorials suck (and cause serious damage) - Mithaldu
http://blogs.perl.org/users/mithaldu/2011/10/perl-tutorials-suck-and-cause-serious-damage.html

======
steve8918
I appreciate the author's honesty.

To be perfectly honest myself, the last time I looked at Perl was about 4
years ago, and I despised the experience. I used it for about 10 months
because the company I worked at had their entire infrastructure running on it,
but it was the worst code I had ever seen, so I quit. If I remember correctly
the code that broke the camel's back for me (pun intended) was:

$a = $src[$src];

I've forgotten my Perl syntax so the syntax may be incorrect, but essentially
what happened was that the original author had defined two different variables
with the name "src", one being a scalar variable and the other being an array,
and apparently those have two different namespaces.

So when I looked at the perl tutorial that the author points out, it looked
like regular perl to me. However, if the syntax of Perl has changed since
2007, then I'd be willing to give it a shot. Although I've recently started
learning Python, and I'm enjoying it, except for the dynamic typing and the
GIL... which is a rant for another time.

~~~
steve-howard
Yeah, the sigils indicate a sort of namespace (@ for array, $ for scalar, &
for function), but that breaks down because when _dereferencing_ an array, the
@ becomes $. I have a fair amount of experience with Perl and I still had to
read your explanation to remember how that could be valid.

In the company I worked for that used Perl extensively, there were coding
standards. In fact, you don't even need that, you just need to remind everyone
that cleverness is not a goal in writing maintainable software, even if
cleverness is what Perl's best at.

~~~
skimbrel
They weren't originally intended to provide namespacing, as far as I know.
They were there to make the compiler's life easier.

The reason that an array subscript is "$foo[0]" is because the $ sigil means
"HEY COMPILER, the expression here is going to evaluate to some scalar".

@foo is the entire list and the compiler treats it as a list type; $foo[0] is
an element of the list and needs storage/behavior of a scalar. Same thing for
hashes: %bar is the whole hash; $bar{quux} is an element and must be treated
by the compiler as a scalar.

The programmer must remember that square braces mean array subscript and curly
braces mean hash lookup.

So basically, this is a compiler optimization implemented by having the
programmer provide hints to the compiler. It's overhead that probably isn't
needed in the modern age, but we're effectively stuck with it. It wouldn't be
so bad if they hadn't made the second (and IMO worse) decision:

You can reuse symbols across contexts. The way this works is that the compiler
maintains a symbol table where each symbol has a slot available for each of
the types (scalar $, array @, hash %, subroutine &). This was originally the
way to emulate pass-by-reference: you'd write a subroutine that assigned its
arguments into typeglobs (* foo — think of it as a wildcard for all things
named foo that behaves as a magic scalar with the contents of foo's symbol
table entry) and then pulled them back out as the types it wanted:

    
    
      local(*foo) = @_;
      foreach $bar (@foo) {
        do_something($bar);
      }
    

This amounts to telling the compiler "I want to alias the name foo in all
contexts to my argument, and then go look at what's stored in the array at
that name" and is a poor man's pass-by-reference.

Perl 5 has a real reference system that completely obviates the need for this,
except for the case of monkey-patching a subroutine, where you still say:

    
    
      local *Package::quux = sub { ... }"
    

What's left is an unfortunate case where things like the GP mentioned ($bar =
$foo[$foo]) are possible, and people who think they're being clever will do
these things. Like the parent said, this is not a good thing to do.

~~~
Jeema3000
"So basically, this is a compiler optimization implemented by having the
programmer provide hints to the compiler."

I'm not entirely sure that's correct. I think Larry Wall (being a linguist
originally) designed it that way because he thought that using context-
sensitive sigils was more like regular speech where leading words indicate the
number, i.e. 'a cup' vs. 'some cups'...

~~~
epochwolf
> Larry Wall (being a linguist originally)

Having taken a class on linguistics, I have to say basing a computer language
on it is a horrible idea.

Human languages are far more complex and verbose than is required for talking
to computers. Consider that it takes years to master a spoken language. A
computer language should be much easier to pick up once you already know how
to use an existing language. Computer languages should attempt to reduce
complexity and verbosity where possible.

Example: I picked up lua in a week. (javascript and ruby experience helped a
lot) I'm not an expert by any means but I'm capable of writing usable
applications. I doubt a person could pick up a new human language in a week.

~~~
mkn
_Human languages are far more complex and verbose than is required for talking
to computers._

This is mostly a quibble, but human languages are not more verbose than
computer languages, generally. I can generally rely on you to allocate all the
variables and present the result in a context-aware way when I ask you, "What
is 3 + 5?" I'd _generally_ have to allocate variables and tell the computer
where to put the result if I were to ask it the same question.

What was, and still is, sort of magical about Perl is the degree to which it
is aware of context and can use it to sort out meaning. If anything, the chief
complaints against Perl, which stems from its similarity to natural languages
(!), is its terseness and expressive power, these complaints being that it's
indistinguishable from line noise and is a write-only language.

~~~
Mithaldu
Honestly, Perl is really anything but a write-only language. Consider this:

[https://github.com/schwern/AAAAAAA/blob/aaaaaa/aaa/AAAAAAAAA...](https://github.com/schwern/AAAAAAA/blob/aaaaaa/aaa/AAAAAAAAA.pm)

It should be unparsable, but most people who have some Perl knowledge find
they can actually read and understand this.

------
alex_c
Documentation rot is one of the most annoying things when trying to learn a
new technology, and the fault lies mostly with Google. "Definitive" sources
sometimes instantly become obsolete when a new version of a technology is
released - and sometimes they don't. Sometimes they very clearly indicate
which version they apply to, often they don't - if you're new to a technology
you're unlikely to be aware of the difference.

The real problem is that "relevance" for technical resources has a very
different meaning from "relevance" on the Internet at large, because the
content pages and incoming links, by themselves, don't contain all the
necessary information to judge whether a page is still relevant. As a result,
Google is in some ways less and less useful as a programmer's tool - not
because Google is getting worse, but because there are more and more layers of
obsolete information out there.

~~~
mcantor
_> As a result, Google is in some ways less and less useful as a programmer's
tool - not because Google is getting worse, but because there are more and
more layers of obsolete information out there._

This is bloody brilliant.

~~~
ChuckMcM
Its got a name, information white out, and can occur for a number of reasons.
The example I use is finding information on Steve Jobs from 2000 - 2005 is
nearly impossible on Google because the first 50 - 100 results of the query
'Steve Jobs' is filled with eulogies and references to his death.

But news worthy events are only one form of white out, historical weight is
another (as the perl example shows).

Disclaimer I work at blekko.com (a search engine) which allows you to specify
things like /date=2005 in the search providing semantic intent. Searching
through white-out situations is one of the uses of the slashtag system.

~~~
majika
Thanks for the disclaimer. Your post is propaganda.

Finding information on Steve Jobs from 2000 - 2005 is actually pretty easy on
Google. Search "steve jobs", then on the left-hand bar, click "custom range,"
and input 2000 to 2005. Done.

I invite readers to actually try the blekko example to see how incapable it
is. Searching with /date=2005 : (a) sorts the results by date, such that you
the first few pages are full of irrelevant pages from Dec 31, 2005. And, (b)
only returns results from 2005 (it's not clear how to search over a time
range).

------
pwaring
It's not a tutorial as such, but the Modern Perl book is up to date:

<http://www.onyxneon.com/books/modern_perl/>

Unfortunately you can't create your own set of tutorials from it, and it
doesn't rank highly in Google.

~~~
gtani
Effective Perl is also terrific. I spent a _lot_ of time reading first
edition.

One of the problems is Google won't let you filter for tutorials from last,
say 2 years. There's lots of solid tutorials for 5.10 and up

~~~
pwaring
Google will let you filter searches by date, it's there under the More Search
Tools -> Custom Range option. If I choose Last Year, I don't see most of the
Perl 4 stuff.

The problem is that people looking for a basic Perl tutorial may not know
about all the filtering options.

~~~
Mithaldu
You're right in that it is not the right search, but as i said on Reddit about
this:

What people _should_ search for is immaterial. For us in the perl community,
only what people _do_ search for counts.

------
prodigal_erik
> Another option would be to reach out to the maintainers of those sites and
> convince them to take down their sites or at the very least add links that
> prominently point to more modern content.

Not only should advocating link rot as the preferred solution alarm any web
user, but there are people out there who specifically need to learn Perl 4 to
maintain or port crappy old systems (they might even outnumber people
selecting Perl 6 or 5 for new projects), and we shouldn't throw their
tutorials down the memory hole to make the language look more sane. Stick with
a notice that better dialects are available, please.

~~~
jleader
I seriously doubt there are more people maintaining code in Perl 4 than there
are starting new projects in Perl 5 or Perl 6. Perl 5 replaced Perl 4 in 1993.
I personally know of several companies using Perl 5 when they start new
projects; I think my last exposure to Perl 4 in production was around 1995.

On the larger subject, I agree, old documentation shouldn't be discarded, but
should be clearly marked as referring to an older version. Of course, the
horrible outdated examples the original article mentions _have_ such
disclaimers, but people still see their code as representative Perl code.

------
gatlin
There is a subset of Perl one can get a sense of by reading the Camel book in
order which is sane, readable, and effective. If you read Wall's explanations
and justifications you get a great mental model on top of which the "weird"
stuff makes sense and feels even natural.

Most criticisms I read focus on how dealing with legacy Perl is typically bad
because it was written poorly. The thing is, I've read legacy PHP, legacy
Python, and other "legacy" code that was just as terrible.

The _new_ Perl code I work with, though, written by my colleagues, is every
bit as elegant and readable as code in any other language - provided
thoughtful people are writing it.

Perl has a bad rep but I have yet to see a single legitimate argument thrown
at it which doesn't boil down to "I read some bad legacy code." I've been in
the same boat, and believe me, I sympathize :)

------
snorkel
Unfortunately Perl coding culture includes a few deeply entrenched bad habits
such as using horribly short variable names, overuse of the default variable,
and using regex when a simpler string match would suffice. These subtle bad
habits make typical perl code hard to follow and thus reflect badly on the
language itself.

~~~
hapless
That's not really a current concern for the perl community. That was true 15
years ago.

Lots of 15-year-old code is out there on the internet for folks to sneer at.

~~~
sliverstorm
In my opinion, the fact that 15-year-old code is floating about and _still
relevant_ should be something to appreciate.

------
grout
Perl culture has largely moved from static pages to blogs and Twitter, and
Google doesn't do well in that situation. Disclosure: I work for a competing
search engine. But that's why I know.

------
nickolai
In this particular case it is also google's fault for turning up results of
such dubious freshness( blekko for examople gives perl.org as first result -
which looks better to me)

So as weird as it sounds, Google shares the blame for the poor perl code being
written.

------
billturner
I think Perl could use something like "Learn Perl The Hard Way." The
foundation for the tutorial/book is already there:
<http://learncodethehardway.org/>

------
mmuro
This isn't a problem with the tutorials. It's a problem with the freshness of
those tutorials.

If you are really worried about this, write a blog post (or several) that show
people how to properly code Perl.

~~~
keithpeter
Agreed, but this is part of a much wider problem with the currency of pages
that have a high search engine rank.

Try searching for information about an obscure problem with (say) Linux. The
pages found often relate to earlier versions of the OS and even in some cases
2.4.xx kernels. You have to know a bit to be able to filter the search for
newer releases.

------
st0p
The situation for PHP is just as bad, try googling for php mysql tutorial...
The first five results are all using oldskool mysql_connect like back in the
day. This is deprecated in php 5.4 and much better alternatives exist
nowadays. Definitly a bad situation for any language IMHO.

~~~
alttag
This suggests a different alternative exists: re-branding Perl (or PHP) as
Perl6 (or PHP5), and consistently using those terms within the community to
distinguish the two. Make a point that it is _a different language_ , enforce
the usage (via style guide) in all public facing commentary.

It will take time, but the community will start to change, and thus actually
change what users are searching for.

Think of HTML/CSS. One gets a more relevant set of results by searching HTML5,
because there was a great deal of effort put into explaining how the language
had changed. When looking for bleeding-edge features, a search for CSS3 is
more helpful than a search on CSS (which like the perl situation, sometimes
returns legacy garbage). The same applies when trying to troubleshoot a
problem on OS X: adding 'lion' to the query often improves relevance of
results.

I short, make a conscious effort to create a new label and inject it into the
public consciousness.

~~~
danssig
Or you could, you know, do what other languages do and just move on to perl 6.
It _was_ meant to replace perl 5 after all. To be honest, as a outsider this
whole movement of keeping perl 5 around forever after perl 6 is getting closer
and closer to usable is one of the most bizarre, cultish things I've ever seen
in the tech community (and that's saying a lot).

~~~
Mithaldu
Oh man, i should've seen this post before i answered to your other one. You're
either a magnificent troll or are just commenting on things you have barely a
passing knowledge of. Do you also wait for Perl 6 because it will make all
Perl code 5 times faster like the recruiter at that Berlin company i visited?

~~~
danssig
I coded in perl for an agonizing 5 years. Sure, it made sense to start working
on perl 5 again once it was clear that perl 6 was stalled but is that still
the case? I was under the impression that there are just a few things missing.
If that's so then I would say people should be getting prepared for migration.

You can resist it, as has happened in various communities (i.e. python) but to
actually _compete_ with perl 6 and try and make the two different _languages_
is down-right cult behavior. Perl isn't a person, it doesn't have feelings. If
you tell it "screw you perl 5, perl 6 is better" it's not going to cry or
leave angry messages on your phone. It's just a tool.

~~~
Mithaldu
First and foremost: There is no way to "move on" from Perl 5 to Perl 6. Perl 6
is a completely different language at this point and more akin to what Ruby
tried to be, back when it was made, in respect to Perl 5.

And well, with the pace Perl 6 is moving on it'll be another decade for it to
become production-usable. There may be only 5% of the feature-set missing
(maybe more, maybe less, i don't keep track), but those 5% are the hardest
part, and then comes the task of making all that run fast and to bundle it up,
etc. etc. I wouldn't hold my breath. Also see chromatic's writings on that
matter:

[http://www.modernperlbooks.com/cgi-bin/mt/mt-
search.cgi?blog...](http://www.modernperlbooks.com/cgi-bin/mt/mt-
search.cgi?blog_id=1&tag=perl%206&limit=20)

[http://www.modernperlbooks.com/mt/2011/08/why-my-side-
projec...](http://www.modernperlbooks.com/mt/2011/08/why-my-side-project-
doesnt-use-perl-6.html)

~~~
danssig
Well, fair enough if that's the case but I wish the perl community would be
consistent. Anytime someone jokes about perl 6 not being usable, someone
(often chromatic!) comes out and says "it's usable now, you're talking
nonsense".

And if it's truly a different language then you should change the name. Racket
did it. And then you would have room to eventually have a version 6 of perl
(what you call perl5 now).

~~~
Mithaldu
Quite a few people want to change its name, but Larry doesn't want to and
short of kidnapping him and tieing him up in a basement with some sketchy
figures in robes and bandanas there's not much we can do on that front.

And well, it is _usable_ as in, you can write software with it. It's just not
commercially usable or complete.

------
va_coder
Isn't that the Perl culture? As someone who has seen a lot of Perl code, I'm
serious.

~~~
mchanson
I think there are two very different sides to perl culture. About ten years
ago I worked on a OO Perl project which was ~10k lines. It had coding
standards, test suites, documentation, and was easy to maintain and bring new
engineers into.

The other side is hacked together scripts. Which have their place, but are
often a mess.

~~~
Mithaldu
Actually, there is a name for both sides:

There is the CPAN, which is obviously what it is;

And there is the DarkPAN, a term describing all the internal projects in
companies, or small tools hacked together by people who don't know or care
about the CPAN.

~~~
jpdoctor
> or small tools hacked together by people who don't know or care about the
> CPAN.

In some parts, the latter is referred to as BedPAN.

------
kokey
He must be from the same tribe as my girlfriend, who also doesn't seem to
capitalize her grammatical person 'i'. Perhaps they read the same grammar
tutorial.

~~~
Mithaldu
I'm from germany AND lazy. :)

~~~
rcthompson
I was about to say that maybe the lowercase "i" was a sign of humility and
selflessness, but never mind.

(Just kidding, I'm sure you have generous helpings of both :)

~~~
Mithaldu
Haha. Sometimes i do also think about this being a choice on that, but it's
more a post hoc ergo propter hoc thing. The original reason is mostly that i
rarely ever capitalize anything. :)

