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.
|
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
| [reply] |
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. | [reply] |
|
|
| [reply] |
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
| [reply] |
|
|
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.
| [reply] |
|
|
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
| [reply] |
|
|
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.
| [reply] |
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 | [reply] |
|
|
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.
| [reply] |
|
|
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
| [reply] |
|
|
|
|
| |
|
| A reply falls below the community's threshold of quality. You may see it by logging in.
|
|
|
