Excellent post. Well written, and agreeable. How did you get in my head like that? :-)

One thing I like to point out when someone plays the "I'm not using a module because I want to really learn Perl" card: a very important part of learning Perl is knowing when to be lazy. Doing everything by hand may help someone learn how things work behind the scenes, but it doesn't usually help learn how to solve real problems in the most effective way. In other words, not only is reinventing certain wheels usually a waste of time, it's counter-productive to the stated goal of "learning Perl".

One thing I like to point out when someone plays the "I'm not using a module because I want to really learn Perl" card: a very important part of learning Perl is knowing when to be lazy. Doing everything by hand may help someone learn how things work behind the scenes, but it doesn't usually help learn how to solve real problems in the most effective way. In other words, not only is reinventing certain wheels usually a waste of time, it's counter-productive to the stated goal of "learning Perl".

Using modules is only worth it if you're good enough at [Pp]erl to debug the flaws in someone else's module; this is usually even harder than debugging your own code.

And yes, modules can contain bugs. Heck, even the perl binary occasionally has bugs; the more code you can understand and fix yourself, the less you're held hostage to someone else's failings.

If you have the time to invest in understanding something directly, do it. Using a module is only a sound business decision if you can trust the author to have coded it right; otherwise you're setting yourself up for a pile of extra maintenance and bugfixes. Often, this involves reading and deciphering so much obfuscated module code that you might as well have coded it yourself, in a readible way, in the first place, and saved yourself the mental anguish of dealing with some foreigner's tortured notion of how to write decent English documentation.

In short, if you want the job done right, you get what you pay for. If you're not willing to code it yourself, you have to check it yourself, and that's not better. Ultimately, you're the one responsible for the solutions you provide, so if you can't guarantee them, you can't trust them.

Edited by planetscape - fixed the anonymonk's square brackets which were being linkified

Using modules is only worth it if you're good enough at Perl to debug the flaws in someone else's module

Extending that idea to code reuse in general, is using perl only "worth it" if you're "good enough" to debug flaws in that? What about an operating system? Or your computer's processor? Sure, all these things can and do contain bugs, but it's still very much "worth it" to use them.

the more code you can understand and fix yourself, the less you’re held hostage to someone else’s failings.

The problem with that reasoning is that the more code you write yourself, the more you’re held hostage to your own failings. Much-used modules get a lot of people bumping into all of their quirks; your own code gets much fewer beatings and will take correspondingly longer to straighten out.

I’ve written about this elsewhere. There are good reasons to roll your own instead of using a module, but most of the time, the factors in favour of rolling your own are far outweighed by the factors in favour of using a module.

Makeshifts last the longest.

2. Prior experience in another language makes you qualified to write perl without learning the basics. Prior experience in another language will give you just enough confidence to shoot yourself in the foot with Perl, repeatedly.

3. The documentation is terse and hard to navigate. This is false. The documentation is verbose, rambling, riddled with confusing attempts at humor, needlessly complex, and hard to navigate. It is, however, not terse.

4. The Perl community is an automatic answer machine. False. Tom Christiansen was the automatic answer machine; but he was decomissioned after the CIA watched the movie _War Games_, and grew afraid of Artificial Intelligences like him.

5. Modules are a crutch for people who can't do it themselves. Again, false. Modules are a crutch for people who can do it for themselves. They allow huge groups of people to suffer from exactly the same set of bugs simultaneously, rather than having to invent their own, distinct, set of customized bugs. This allows exploit writers to target a larger segment of the population, and keeps security professionals employed to stop them.

++ #outstanding! :)


holli, /regexed monk/

Prior experience in another language will give you just enough confidence to shoot yourself in the foot with Perl, repeatedly.: Excellent point. I think juggling makes a good metaphor for programming in this case. Juggling small balls (using BASIC), juggling bowling pins (using Java), and juggling chainsaws (Perl) all use some of the same skills, but you had better damned well know something specific about juggling chainsaws before you try it blindfolded.

print substr("Just another Perl hacker", 0, -2);

- apotheon CopyWrite Chad Perrin

Agreed, great post.

Having said that, I'll take some issue with point #3. I really do think Perl documentation (O'Reilly books, CPAN docs, the lot of them) is not geared towards non-programmers. By "non-programmers" I mean folks who are don't have years of experience, a degree, or are full-time.

Of course, it might be me. Maybe I'm still running a 4.77 mhz chip here, but I find that I really have to work at understanding a lot of the methods and concepts by just reading the books. I learn by example and there are so view real-world code samples that show how things work. That's why I like PMs--there is a lot of practical stuff here (you might have to dig it out).

I'm not complaining, I'd just love to find working examples and tutorials for things like CPAN modules.

As I master them, I plan to add to the Tutorials, but not until I know it's solid. Otherwise I'm guilty of #2 above.

I learn by example...

One of the things that bugs me now and again about learning materials is that some of them only teach it for one learning style. Granted, it would be strange to have 4 versions of "It's OK to slice in Perl", from Visual to Kinesthetic. [And can you imagine the Aural tag: "Read the preceding paragraph outloud to yourself 3 times"??]

The better materials tend to have some of each where practical, and allow the victim to choose a not-quite-linear path: highlighted summaries for the readers, simple diagrams for the viewers, and examples and puzzles for the practical folk.

When the Camel Book comes out in a 10 box DVD set, complete with lightning talks for footnotes, and behind the scenes shots of Larry on a Segway talking to a simulation of Carl Sagan, everyone should be covered.

-QM
--
Quantum Mechanics: The dreams stuff is made of

...Granted, it would be strange to have 4 versions of "It's OK to slice in Perl"...

That's one nice thing about PM's Q&A--often there will be several examples.

...When the Camel Book comes out in a 10 box DVD set...

Can I queue that up in Netflix?


—Brad
"The important work of moving the world forward does not wait to be done by perfect men." George Eliot

"As I master them, I plan to add to the Tutorials, but not until I know it's solid. Otherwise I'm guilty of #2 above.": I think that's not an optimal approach. I find that learning is often helped immensely by trying to teach the same concepts to others. Try writing tutorials, preferably in places where they can be vetted by others that know more than you.

Perlmonks is actually a very good place for such a thing. Choose a subject you know a lot about, but maybe not everything, and write a tutorial about it. When people start responding to you, I guarantee you'll get the tutorial fixed in short order so that any mistakes you made start clearing up very quickly. As a bonus, you learn.

print substr("Just another Perl hacker", 0, -2);

- apotheon CopyWrite Chad Perrin

Most of the objections to perldoc can be solved by pointing people to perldoc.perl.org. I personally find it better than the perldoc "man pages" because it is easier to search, can be simply bookmarked, etc.

If you're learning Perl, the same site offers an archive of itself that you can download and run locally. Truly invaluable.

This should be on one of the FAQ somewhere!

Maybe, "What are the Common Misconceptions While Learning Perl?"

2. Prior experience in another language makes you qualified to write perl without learning the basics.

I think it's important to note that while it may be possible to apply prior programming knowledge to Perl and even come up with some 'working' code without ever learning the basics, it certainly wouldn't be reasonable to advise beginners to do so. Additionally, I can't think of any case where it could be stated that someone who disregards the basics and dives head first into the code armed only with prior programming experience would be 'qualified' to write Perl. I once built and installed a kitchen counter (badly) and i wouldn't presume to be a qualified carpenter.

When I said that 'Prior experience in programming languages may be very helpful when learning a new language' I meant the emphasis to be on 'learning'. 'Learning Perl' contrasts sharply with 'Using Perl to pound a few nails'.

but it doesn't mean you know how to properly express yourself in said new language

My inflamatory rhetoric above is only to mirror yours. When I found that google search rather different than you implied, I distrust your whole post. I suppose rather like you were soured by some of the mistakes in tutorials on the web.

I see the first search results this way:

1. an old (1995) intro by a Ben Johnson at the National Ctr. for Super Computing. Basic intro for people who Ben expects to read the docs.
2. Perl4 dox with a intro stating it is just of historical interest. A sensible beginner would move on.
3. by a John Pollock at The Web Design Resource this is both out-dated and a bit lame.
4. is a reference to perlmonk's Tutorials.
5. is a Carnegie Mellon University Perl4 manpage. It does have a header mentioning Perl5 and pointing the reader to perl.com.
6. is www.perl.com. All my readings there have been worthwhile. I haven't read a beginner's tutorial there but I'm inclined to give it a pass. That is prejudice, I have no real reason to think that cause they can publish good mid- to high-level instructions that they would be good with a beginner's tutorial.
7. is Robert's tutorial in the UK. This is outdated and dated in its own time. Rather lame. Its saving graces are that it shows -w early on and that it points the reader to perl.com and activestate.com.

Despite the fact that you indicated that you wrote this 'inflamatory rhetoric' to illustrate a point rather than to be taken literally, I'd like to respond to it:

> Did you google on PERL and tutorial or did you draw from
Yes, I did.
> hyperbole or imagination? Did you intentionally mislead us,
Yes, I drew both from hyperbole and imagination, and no I didn't intentionally mislead you.
> lie to us, dupe us or was it just ineptitude?
or lie to you or dupe you. Yes, my attempt at using 2nd person narrative to describe the activities of fictional users was probably driven by my ineptitude at expressing myself in prose.

I'm not sure what you're getting at with your post. By your own admission, 57% of the tutorials you've found on Google are one of (or all) outdated, 'lame', or requires the reader to be sensible. This supports my comment that 'Certainly the majority of tutorials will mislead you, lie to you, teach you broken concepts, and basically waste your time'. Note that I didn't say 'all tutorials will mislead you, lie to you, or teach you broken concepts', just the majority.

I don't believe that when a beginner approaches a new language (especially if they have no prior programming experience) that they should be expected to be sensible about what learning material they choose or have some innate ability to guide themselves to well-written learning material. I also don't believe that if you present an outright beginner with 7 choices of material to learn a new concept from that they will somehow instinctively choose the best material. That's why I think it's a good idea to guide people to the best possible material at the outset and allow the beginner to focus on learning rather than disseminating the good from the bad.

As a clarification, all of the 2nd person narratives at the beginning of the misconceptions are fictional and straight from my imagination. They may not hold up under intense scrutiny, nor are they meant to. They are meant as an entertaining read to describe what a random, fictional beginner possibly encountered. They aren't based on my own experiences, but are rather drawn from my imagination and from the actual experiences of literally hundreds of people I've found to have been mislead during their learning process. I apologize if this is unclear, but I guess you'll have to chalk it up to my less than adequate ability to express myself in written English language. Alluding to an ulterior motive to mislead or lie to people is uncalled for. (The previous statement is in response to 'When I found that google search rather different than you implied, I distrust your whole post.' rather than to the admitted 'inflamatory rhetoric' to 'mirror my own')

Thanks
m.att

M.att, the key point of my reply was what you replied with: Alluding to an ulterior motive to mislead or lie to people is uncalled for. That is what you did, or you were more direct.

I don't and didn't subscribe any ulterior motives to you. I did not mean to allude to such either, I only meant what I said I ... found that ... search ... different than you implied, I distrust your whole post. No allusion to motives intended: I find an error and so I doubt the accuracy of the rest of your post.

That you feel so attacked demonstrates my point. You smeared a bunch of people who, just like you, went to some effort to share their knowledge. You impugned their competency, motives and honesty. When I only ask if you are doing the same you are offended.

My lame does not equate to your utterly horrible and I do not agree that my examples support your point. I am not offended that someone codes to a standard I dislike: &routine is perfectly good perl. (Most Monks realize that &name cannot be routinely applied to builtins. The student who learns that convention early on also learns early to distinguish builtins from package subs.)

I found your first post to be entertaining, you succeeded in that. I generally agree with your post.

Beginners have misconceptions¹ because they are beginners. What is good teaching material is difficult to determine without access to the student. Even the student who likes and wants to learn will coast, or stop learning, at some point. The student who learns just to accomplish some specific aim will do this at the earliest possible time. This suspension of learning can leave gaping holes for a long time. The sites I called lame may very well serve someone who just wants to achieve some aim. That they don't want to learn Perl, but just want to do XXX, does not make them less worthy of being taught. You, and I, will want to teach them Perl--someone else may be able to teach just what they want to know. The people who were so served, if any, will not be likely to come to your attention, they moved on.

Be well,
rir

¹ -- there are also voids of conception ~

My Google experience was somewhat different. Entering "Perl tutorial" as a phrase, I only had 195,000 hits. I checked out the first 21 (I'd have stopped at 20, but the last page was in German so I continued to the next English-language page).

1. More about makefiles than Perl.
2. Not found.
3. Outdated tutorial for Perl 4
4. Perl 4 tutorial.
5. Not horrible, but uses some deprecated code.
6. Last update was in 1999
7. Discusses Perl 5.6.0; written in 2001
8. Dated 1999
9. PerlMonks!
10. Dates to 2000
11. Dated 1999 – discusses how to work with RSS
12. Discusses how to select the correct database
13. Author states, “…I’m not an expert with Perl”.
14. Gave me a blank page when I tried to access this link.
15. Discusses Perl 5.005
16. Referenced page did not have the word “Perl” on it; search options did not return any hits for “Perl”.
17. Tutorial from 1995.
18. This was a page linking to sites purporting to teach Perl; did not have any information about Perl on the page itself.
19. Decent tutorial for someone who knows some programming. Not for the complete novice.
20. German-language page that I cannot evaluate.
21. Link to Perl.com!

Almost all these links were useless, especially to a complete newbie to programming. The only ones that seemed good were the ones to PerlMonks and perl.com, and #19. Numbers 5 and 7 weren't altogether useless. Overall, only 25% of these sites appeared to be helpful. The rest were not (IMNSHO).

20. German-language page that I cannot evaluate.

http://google.com/language_tools ?

# 26. learn.perl.org: The site for people learning Perl.