Beefy Boxes and Bandwidth Generously Provided by pair Networks
laziness, impatience, and hubris
 
PerlMonks  

Perldoc, the tutorial

by Juerd (Abbot)
on Jun 01, 2002 at 23:26 UTC ( #170948=perlmeditation: print w/ replies, xml ) Need Help??

Most people learn Perl by reading a simple tutorial, which probably, as they find out later, resembles all sorts of wrong. Some are lucky and find a good tutorial. Other people begin by reading books. There are terrible books and there are good books. However, books are a slow way of learning a language, in my opinion, and they cost money. Good learning books are read only once (if you read your learning book twice, it didn't do a good job at teaching you, did it?). I tend to avoid buying books.

How did I learn Perl then? First, let me explain why I wanted to learn Perl. As a Basic programmer, having used many Basic dialects, I found that there was no statisfying Basic interpreter for Linux, but I did want to use this new and exciting operating system. So I went looking for other languages. Of course, I first considered C, but I have always disliked C and even the thrill of having another platform couldn't get me to like this powerful language. Perl was the next language I looked at. To a Basic programmer, all the cryptic characters look strange, but its string interpolation and hashes were quite convincing to me. I learned Perl and do not feel any need to learn other languages anymore.

When learning how to use Linux, fortunately someone told me to use man whenever I needed help. I wanted to know more about Perl, so I typed man perl. It refered to a bunch of other documents, that I read almost sequentially, skipping those that didn't intrigue me. I learned a great deal of both English and Perl reading the perldocs. There is a lot of information there, and to beginners, it isn't always clear where some things can be found. The terminology was never explained, but I learned to recognise words by ignoring the fact that I had no idea what they were talking about.

A few years later, I still think reading perldocs is the best way of learning Perl. That said, I would like to complain about some things. I now know why strict should be used where possible, and that -w can be very helpful too. This is because people told me, not because I read about it. I think the use of these should be encouraged more by the Perl documentation. The other complaint I have is that some things just aren't explained well enough to beginners. Basic didn't teach me anything about scoping, so I had some trouble with that.

There are some documents that I think should be made available as perldocs. Coping with Scoping could be named perlscopetut and Suffering from Buffering could be named perlbuffertut.

This brings me on the subject of tutorials in perldocs. There are some great extensive but comprehensible tutorials, like perlreftut and perlretut, and some tutorials that are not really easy like perldebtut and perltoot. The most important tutorial can not be found in the standard distribution. perltut it should be called. I don't know if there exists a tutorial that we all agree is clearly the best Perl quick start tutorial there is. But if such a tutorial, it should be distributed with Perl. If there is not, it should be created.

You might wonder why perltut is needed. For the greatest part, it's just because without it, the perldocs are incomplete: they cover everything except for the learning Perl part. But there's another reason: it is now very unclear if there is a tutorial that is accepted by the community, and having perltut would fix that, as we have to agree perldocs are generally quite good.

Not everyone wants to learn a language by reading much documentation, like I did (although I do think it's the best way). Many want a tutorial. I think that tutorial should come with perl itself.

P.S. The links to perlreftut, perlretut and perldebtut are broken. This is because the documentation on Perl Monks is outdated. Not my links, but this site has be be fixed.

Comment on Perldoc, the tutorial
Re: Perldoc, the tutorial
by broquaint (Abbot) on Jun 02, 2002 at 00:10 UTC
    There are some documents that I think should be made available as perldocs. Coping with Scoping could be named perlscopetut and Suffering from Buffering could be named perlbuffertut.
    I believe the reason these are not mentioned in the docs is that they are not specific to perl. For example, lexical scoping is not native to perl and the perl docs will generally assume that you have a programming background so there is no need for this to be covered given the assumptions that are made. Most of the perl docs cover areas that are native to perl e.g perlreftut and while references are found in other languages the way perl deals with them is very much different to, say, C.
    The most important tutorial can not be found in the standard distribution. perltut it should be called
    I have to say I wholeheartedly agree. But I think this is more down to the distribution of perl than the core as this would be making the assumption that the user of perl also has an understanding of *nix man pages. Perhaps a better option would be if there was a standard perl tutorial that would be bundled with all versions of perl whether it be in the form of man pages or an HTML document.

    _________
    broquaint

Re: Perldoc, the tutorial
by emcs (Scribe) on Jun 02, 2002 at 00:44 UTC
    However, books are a slow way of learning a language, in my opinion, and they cost money. Good learning books are read only once (if you read your learning book twice, it didn't do a good job at teaching you, did it?). I tend to avoid buying books.

    I enjoyed reading this node as I have been "Learning Perl" for a couple of months now, but am finding it difficult to get past the beginning stages.

    Different people, have many different learning styles; my personal preference is to learn from books as this is the way I learn the quickest, but I have talked to friends who intensly dislike this method, they prefer to attend organized classes; or one to one training.

    My preferred style of learning is to read a book once: and then to do some work. While I am trying to code, I will refer back to the book many times, especially when I am having difficulties understanding why my code is not working.

    A good Perl tutorial (in my opinion) is well worth the money spent on it.

    emcs

    The dogs bark; but the caravan rolls on.

      I have the exact same modus operandi - read the whole book first, then refer back to it for problems that crop up during hands-on experience.

      Makeshifts last the longest.

Re: Perldoc, the tutorial
by Zaxo (Archbishop) on Jun 02, 2002 at 10:41 UTC

    As if by magic, perl-5.8.0-RC1 has perldoc perlintro. I expect that link will resolve pretty soon, but for the present a local copy would be ideal ;-)

    After Compline,
    Zaxo

      As if by magic, perl-5.8.0-RC1 has perldoc perlintro.

      It is a nice quick start guide, but not enough to be a tutorial. It doesn't handle negative array indexes (which would prevent newbies from using $foo[@foo - 2]), does not explain "context" well enough and a beginner's tutorial should have _some_ OO, or at least something about how 3rd party modules work with it.

      But yes, perlintro (I still rely on this site being updated soon) is a very good start, and I will recommend beginners reading it.

      - Yes, I reinvent wheels.
      - Spam: Visit eurotraQ.
      

        I wouldn't "rely on this site being updated soon." Last time this was discussed most people agreed that keeping the Library up to date was a fairly low-priority task, especially since perldoc.com does essentially the same thing and does it very well.

        -Blake

Re: Perldoc, the tutorial
by Ovid (Cardinal) on Jun 03, 2002 at 04:00 UTC

    ++ for an excellent node. However, I did notice something that stood out. You wrote I learned Perl and do not feel any need to learn other languages anymore.

    I can understand the motivation behind that statement, but learning other languages allows you to appreciate different methods of approaching a problem. For example, later in the thread you wrote "a beginner's tutorial should have _some_ OO". Well, learning Java, Ruby, or some other language that is better suited to object oriented programming will quickly teach someone better ways of looking at OO. Further, some of the hacks in Perl's OO system are frustrating, at best. There is no clean separation of class and instance data, for example, but it would be nice to have. However, many Perl programmers who know Perl's OO system don't know what class and instance data are, so they have trouble appreciating why Perl has a potential weakness here.

    Why I like functional programming by tilly, gives a nice quote by Tom Christiensen:

    A programmer who hasn't been exposed to all four of the imperative, functional, objective, and logical programming styles has one or more conceptual blindspots. It's like knowing how to boil but not fry. Programming is not a skill one develops in five easy lessons.

    tilly further goes to give an example of functional programming in Perl and argues that procedural programming would be a horrible fit for the described problem. Attaching actions to text isn't a typical way of thinking about a problem, but it works nicely here. Read the full thread to appreciate the scope of the problem.

    I also recently posted Productive, Prolog, and Perl, which shows a simple problem for which procedural or object-oriented programming would be an awful fit, but Logic programming suits it just fine. I used Prolog in the example and, ignoring for the moment that Prolog-alpha is on the CPAN, I think that Perl would be a poor choice for said problem, but it could be made to fit the problem if one were to try and write Perl in a "Logical" programming style. However, most of us (including me, to be frank) have little to no knowledge of this type of programming, so writing a Perl program in a style that more naturally fits the problem would be challenging, at best.

    I'm glad you like Perl, but don't overlook the utility of learning different programming styles :)

    Cheers,
    Ovid

    Update: I forgot to point out that learning "non-programming related" stuff is also good (though I'm sure you know this). In "The Mythical Man Month", Brooks points out that adding programmers to a project can often slow it down. For many project managers, this was a revolutionary assertion. However, if I told any economist that, they would have replied "Duh! Tell me something I don't know." Decreasing marginal productivity is Economics 101, but if we don't know economics, the ideas can seem counter-intuitive. Depth of knowledge is good, but I think width of knowledge pays off more in the long run.

    Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

Re: Perldoc, the tutorial
by Abigail-II (Bishop) on Jun 03, 2002 at 11:30 UTC
    I think that tutorial should come with perl itself.

    Patches welcome. I'm sure that if you write a good tutorial, it will be included in the main distribution. Just wishing for things isn't going to make it happen - someone will have to write it.

    Don't take this the wrong way. This is how Perl is being developed. The surest way to get things added/changed is by just doing it, and submitting the patch.

    Abigail

      Patches welcome. (This is usua... nevermind *grin* - Juerd) I'm sure that if you write a good tutorial, it will be included in the main distribution. Just wishing for things isn't going to make it happen - someone will have to write it.

      It seems my rant was posted a bit too soon, as perlintro is a nice tutorial for beginners. It doesn't cover everything I think it should, but I guess it's a matter of time before more docs get into the distribution. I myself am not a good writer, so I won't be the one to write a tutorial.

      I posted this to find out if there is already a tutorial that is accepted as "the best", but there hasn't really been an answer to that yet.

      Don't take this the wrong way. This is how Perl is being developed. The surest way to get things added/changed is by just doing it, and submitting the patch.

      Maybe someone here wants to write a good tutorial that covers everything? Or wants to convert an existing one to pod? Perhaps the document we're searching for already exists, but just isn't named perltut?

      My post isn't just a "hey, I want this and you should make it happen" post: I want to know how others think about this and whether what I'm wishing is sane.

      - Yes, I reinvent wheels.
      - Spam: Visit eurotraQ.
      

        My favorite Perl tutorial. Also, I'm very happy about pack getting a tutorial. Maybe now I can figure it out.

        Cheers,
        Erik

        Light a man a fire, he's warm for a day. Catch a man on fire, and he's warm for the rest of his life. - Terry Pratchet

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://170948]
Approved by broquaint
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others browsing the Monastery: (6)
As of 2014-09-16 05:51 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite cookbook is:










    Results (156 votes), past polls