Perl tutorials suck (and cause serious damage)

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

by Mithaldu • 15 years ago

135 129 15 years ago

blogs.perl.org

kokey• 15 years ago

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.

Mithaldu25• 15 years ago

I'm from germany AND lazy. :)

rcthompson• 15 years ago

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

va_coder• 15 years ago

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

Mithaldu25• 15 years ago

I'd like to answer, but the question is a bit vague. What are you referring to with "that"?

mgkimsal2• 15 years ago

I took "that" to mean "hard to read / cryptic code".

mchanson• 15 years ago

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.

Mithaldu25• 15 years ago

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.

mmuro• 15 years ago

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.

Mithaldu25• 15 years ago

I tried to keep the title short and attention-grabbing. Note how one of my solutions basically say: "We need to write a perl clone of Python Tutorials."

Also, more importantly, this task is so huge that a single person trying to solve it on their own is doomed. It needs to be a community thing.

keithpeter• 15 years ago

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.

pwaring3• 15 years ago

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.

Mithaldu25• 15 years ago

I'm aware of Modern Perl and recommend it for every novice, but as you mention, it is not a tutorial and thus doesn't have much to do with what the average newbie is looking for. It's also not readable on the web.

pwaring3• 15 years ago

There's a HTML version available (the build scripts are available on GitHub), so it could be readable on the web.

gtani• 15 years ago

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

pwaring3• 15 years ago

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.

majika2• 15 years ago

It's one hell of an ugly link, but:

http://www.google.com.au/search?q=perl+tutorial&ie=utf-8...

zura• 15 years ago

I'd also recommend the Higher-Order Perl book:

http://hop.perl.plover.com/book/

Mithaldu25• 15 years ago

It's a good book, but i don't think it's good for newbies. Some parts of it still go over my head. :D

npongratz• 15 years ago

Modern Perl's author, chromatic, offers some pretty good advice on how to learn Perl:

http://www.modernperlbooks.com/mt/2011/09/how-to-learn-perl....

snorkel2• 15 years ago

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

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

In my opinion, the fact that 15-year-old code is floating about and still relevant should be something to appreciate.

grout2• 15 years ago

For some people, though, any use of the default variable is overuse. Nothing to be done about that whine.

snorkel2• 15 years ago

IMHO it's OK to use $_ in small scope contexts, like in a tight loop, but very offensive when $_ refers to an operation that occurred three pages back.

steve8918• 15 years ago

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.

waqf• 15 years ago

Perl 6 changes this syntax to @src[$src], effectively admitting that the way sigils worked through Perl 5 was a failed experiment.

steve-howard2• 15 years ago

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

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.

kgtm2• 15 years ago

Perl is really powerful, and with power comes responsibility. Reference handling is an area that needs great care, as you can easily make subtle mistakes. Coding standards are important in a code base, often there are many ways to accomplish the same thing. Usually some forms are cleaner than others and can be enforced. An example regarding dereferencing:

  use v5.10;
  use strict;
  use warnings;
  
  my $ref = ['one', 2, 3];
  say $ref;
  
  foreach (@{$ref}) {
  	say;
  }

  # These are the same. The first form is much cleaner.
  # It also makes more sense semanticaly
  say @{$ref}->[0];
  say @{$ref}[0];
  say $ref->[0];

mikecaron3• 15 years ago

Some years ago, Damien Conway spoke about changing sigils going away in Perl 6... whenever that comes out... perhaps 2030.

sreque2• 15 years ago

I had the exact same experience coding Perl in my last company. I found myself, just like Steve Yegge says in his ancient languages blog post, having to memorize all the special edge case rules and idioms of the language just to get anything done. Whenever I got to choose Python, Ruby, or C for a task I felt like I was breathing fresh air again after being stuck in a musty room for a while.

I remember being offered to choose any toolset I wanted for a particular project and finding out that Perl was the only scripting language that had the bindings to the C libraries I needed to use. Naturally, I decided to to do the whole project in straight C instead. :)

The funny thing is, whenever I would code in Perl for a while, I would actually grow acclimated to it. I would start to think to myself, "Hey! I'm finally getting things done. I CAN be productive in this language!" It was only after switching away to another language again that I would re-recognize just how painful Perl really is. This experience actually repeated itself multiple times for me as I moved on and off Perl projects and it helped me learn to sympathize more with others who are perfectly content to code in Perl for a living.

At one point, I had enough and began recording all the weird Perlisms that were wasting my time as I encountered them. My goal was to compile a "95 theses against Perl" document and post it on my manager's door as a joke. Fortunately, I only got into the 40s before my manager offered to let me move to another team where I never had to write a line of Perl again in that job!

It's possible to write good Perl just like it's possible to write good COBOL, and better tutorials would definitely help newcomers to the language do just that. I would rather spend my time writing good code in other languages, however.

kristaps• 15 years ago

Do you still have that list? I think it could be very useful to someone who has to dive into a legacy Perl codebase.

mikecaron3• 15 years ago

So here's the thing, Larry Wall is not only a programmer, he is a linguist. That's reflected in the myriad of ways that one can write something in Perl, reflected in the common refrain at YAPCs the world over, "TMTOWTDI" (There's More Than One Way To Do It). But because of the flexibility Larry designed into the language, there's also "more than one way to do it" ...wrong (ok, not "wrong", but so complicated and whacky that Joe programmer 10 years from now wouldn't have a clue about). But this very flexibility gives Perl a unique beauty.

I don't think it's the language's fault that poor code exists to teach people the way to Perl zen. It's more that scripting languages themselves lend to one-offs and poor code writing, especially in the days of early Perl, when people were giddy to get their hands on something that wasn't as ugly as "sh". We need better programmers who are not "too busy to write good code" as well as better material.

vetler• 15 years ago

Also, $a is a global variable within the current package, which means that if you don't have to declare it, even if strict is turned on.

greglindahl• 15 years ago

$a and $b are special due to their use in sort functions. This is a wart that predates "my".

Newer languages have warts, too, you just don't know what they are, yet.

nickolai• 15 years ago

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.

st0p• 15 years ago

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.

alttag2• 15 years ago

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.

danssig15• 15 years ago

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

grout2• 15 years ago

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.

alex_c2• 15 years ago

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

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

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.

Mithaldu25• 15 years ago

This is a nice theory, but Google manages to keep step if new material is produced. Gabor Szabo's tutorial series is really very new, but is the fourth result. The problem is that there is not enough up-to-date material connected with the term "perl tutorial".

alex_c2• 15 years ago

Yes and no. I obviously don't know that many details about Google's ranking algorithms, but content age and incoming links play a big role. This plays against content freshness and rate at which new incoming links are added.

I suspect Google uses more or less the same algorithm for general content and for tech documentation. The difference is, general content - news, discussions, fiction, etc. - rarely loses relevancy, it can only be supplanted by newer, more relevant content over time.

This happens for documentation, but it takes time - and at any given time you end up with a hodgepodge of content for various versions.

There's also no foolproof way to search for content for a specific version - this would go a long way towards fixing the problem. The closest solution is restricting the search results by date, I often have to do that.

billturner• 15 years ago

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

prodigal_erik• 15 years ago

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

jleader2• 15 years ago

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

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

Perl tutorials suck (and cause serious damage)

Related Stories