Beefy Boxes and Bandwidth Generously Provided by pair Networks
Problems? Is your data what you think it is?

A tutorial for Perl to teach Beginners

by theroninwins (Friar)
on Sep 06, 2004 at 08:51 UTC ( #388753=perlmeditation: print w/ replies, xml ) Need Help??

OK Prolog:
I am still studying at University and I have to do a project of my free choice.
Since I am new to Perl I can still see all the problems that beginners have eventhough they know other programming languages. So I was thinking that like for VIM on Linux I want to program a little tutorial that teaches beginners how to use Perl and what is possible. I don't mean to really cover everything that you can do with it (that is impossible) but the basics and maybe something more.
Since I am new I would like to know if such a program is usefull (I think it is, but I might be mistaking) and what parts of Perl should be covert by it (what did you do first with perl) I just like to get a little overview and maybe some hints so I can get started.
Like I said it is just an idea (came to me last night at about 3am) but I must say I can't get rid of it, so I guess doing it is the best thing I can do. What are your thoughts on this??

Comment on A tutorial for Perl to teach Beginners
Re: A tutorial for Perl to teach Beginners
by bart (Canon) on Sep 06, 2004 at 09:06 UTC
    I like the idea of somebody very new to Perl pointing out the difficult spots. Even if you don't have all the answers, just logging the questions that arise, would be a valuable resource. Us oldbies have long forgotten what is weird and hard for the people on the outside...

      That's an excellent point, and one that I think a lot of people forget.

      I've just been accepted as a Ph.D. student. (Yay me. :-/) So I've had the opportuntiy of applying to teach undergrads, particularly first-year CS classes. I don't like that idea. To my mind, it's hard to teach a class when you don't know what's hard and what isn't. I've (probably) already forgotten that --- I'd rather teach a fourth-year complexity course than a first-year intro-programming course, because I can remember what's hard about complexity --- but I can't remember what's hard about learning to program; I need to re-learn all that.

      I would wholeheartedly welcome a "Perl for newbies by newbies" tutorial --- or a regular column. I've already forgotten what's difficult about using Perl's filehandles and regexes (Edit: Yeah, as if that's all), and that makes it more difficult for me to figure out what bits need more detail when I'm writing for someone who hasn't.

      F o x t r o t U n i f o r m
      Found a typo in this node? /msg me
      % man 3 strfry

        So i will post my problems that I have and I think are regular to other new users too. And if I get some answers by use saints or others I can get my project started.... But where can I post these Probs without flooding the SoPW section? A column would be a good Idea but how can you realize it here (and more it would be good that if you see postes by other new users that you coulsd postes there probs too, because like that I can see the whole range)...Any idears??
      In the beginning I always found $_ difficult to understand. Specifically, all the operations that $_ was left out of because it was 'assumed'. Very tough for a newbie. Also, I did not discover strict and warnings until I came here. They are a pain at first but, as I went along, I learned alot by listening to what those modules had to say.

      Neil Watson

Re: A tutorial for Perl to teach Beginners
by phobia (Sexton) on Sep 06, 2004 at 14:02 UTC
    I like the idea, the only thing, I I think you might want to think about is how you actually do the tutorial. It is easy to write a tutorial about a specific part of a language, but it seems like you are going to give an array of the language. What would be kind of cool, if you could do is, write your tutorial in perl. That have like a funky little way of showing off, what perl can do. (Though, that won't be the highlight of the language.)
      On this I haven't decided yet and like I said I am a beginner to the language as well, but if it is posible to me to do so I will of course do so, so people that read the tutorial may browse the source code as an final example or something like that. :-)
      The written tutorial that I will post on this page is only part of my project planned, but what I really want is to make it interactive: A lesson will explain the part that is subject at that time and then the peopple that read it can practice what they read.
      If that is possible then I will try to do it in perl.
•Re: A tutorial for Perl to teach Beginners
by merlyn (Sage) on Sep 06, 2004 at 22:02 UTC
    I make my living from writing tutorials about Perl. The most important thing to consider is to understand where your audience is starting, and where you want them to end up. And then leave everything else out. "When in doubt, leave it out", is my tutorial motto. If you can connect the dots from start to end with six steps, don't add a seventh.

    -- Randal L. Schwartz, Perl hacker
    Be sure to read my standard disclaimer if this is a reply.

      Along with this, we (that is, the Stonehenge folks) tell our classes that we are going to lie to them. That gets their attention, then we explain that we aren't really going to lie, but we aren't going to tell them the whole truth. For instance, we're not going to explain every dark corner of scalars before we show them how to use them. Then we tell them that when they study this more, they may run into exceptions and special cases, and we purposedly left that sort of stuff out so we got the idea across without taking two days to explain it.

      People learn in spirals. They'll go over the topic several times and pick up different things on each circle, and on each circle they are not going to pick up everything. A week of training or a written tutorial is a single circle. If you put everything in those, people are just going to get confused and not pick up anything.

      As Randal says, just give them the steps to get them from start to end. Don't worry about completeness---they'll get that as they gain experience. Let them know where they are going, and make sure they know the connections between the steps. Make the path clear, not just the end points.

      A lot of the Stonehenge material reduces complex topics to a single sentence: "A scalar is a number or a string", "An object is a blessed reference", "A closure is an anonymous subroutine which references a lexical variable that has gone out of scope". The rest of the discussion comes back to the single sentence and spirals around it because that's what we want people to walk away knowing. They'll pick up the nuances, exceptions, and special cases with experience (or maybe the next level Stonehenge course :)

      From a beginner's perspective, it's the mistakes that people want to read about. Just about everything in Perl already has a couple articles about it, and just about everything is already documented, so the only thing left is the human story. :)

      brian d foy <>
Re: A tutorial for Perl to teach Beginners
by gmpassos (Priest) on Sep 07, 2004 at 00:19 UTC
    Is a good idea and any work on "How to teach a programming language" is important since no one in the world knows what is the best way to teach that.

    The biggest question is that "programming language" is different to "know how to program". The 2 concepts can be similar in the 1st view, but actually are very different, since is much more easy to teach a programming language to who already knows other, but over the topic "how to program" we also have a lot of areas, like structured languages and the mature way to program, the Object Oriented Style.

    Over the years I saw a lot of people learning different programming languages with different styles, and saw the final result. In my opinion, if you want to create a complete programmer, you should start to teach from the base, with a structured languages where is possible to know how the bases are built. We don't need to work with assemble code, but know how an enverioment without OO works and how to create complex algorithms is very important. So, in the structured level the student will learn algorithms.

    Then, after learn the basics of algorithms, it can start to play with a well orgnized enverioment with a OO language. In this level it will need to learn how to make elegant codes, not only creating a well formated style to write the code, but in how to make interaction of each chunk of methods and classes. In the OO level the developer will learn discipline and organization.

    Note that learn the basics of structured programming is important, but the student need to learn that we can't, actually we never should, use a pure structured program for production softwares. The structured level is just to learn how the things work and to not have a dumb programmer, that only knows the easy job, since we know that the easy job can't do everything, and the hard chunks of codes are small, but this small chunks make a good job and a real software. The structured level will also teach how to be creative, since we alwasy write complex codes and complex solutions on that.

    In the university I saw teachers trying to teach programming languages directly with OO. Do that for people that never saw a programming language is a crime, since they will think too hard to program an will lost the motivation. Also I saw people that can learn programming languages directly in the OO level, but they never will be able to go to a lower level and create solutions that can't be resolved with a static and already built OO enverioment. We can't forget that OO was created to make structured codes more organized, were we can isolate each part of the solution, what opens the oportunity to reuse codes. So, the student need to know that structured code exists to know for what OO exists, since only a OO declaration do nothing, it just delcare a DATA structure, and methods, who really do the job, are small chunks of structured codes that work over this declared DATA.

    I think that in the begin the biggest problems is to teach in a way that we create motivation for the students to learn this thing that 90% think that is too annoying. So, start to show the power to be able to create things that we always use, like some intercomunication software, were we send some MSG to another computer, making a simple chat. Also we can show how to work with the internet, let's say, get a Web page or build a dynamic page, and the list goes. So, never start showing boring and stupid things, 1st get the attention, than you start with the exercises. Is like to teach a musical instrument, first we get the attention with simple but interesting musics, than we past the exercises that will create the technic, and only after the technic we start to teach discipline with score.

    So, you need to show the different levels of programming and I think that Perl is a good way to show all of this, since we are free to use or not all of this levels. We also are able to run our code in different OS, we have, we are free to change, create and recreate Perl, etc...

    I think that the final tip is that a programmer is always a developer of something. So, a developer need to be able to work alone, to learn by it self how to create a solution for the problems that it have. Some people are able to just get the problem and discover by it self that it need to learn language X, with the methodology Y, and resouces Z. But normal people need to have someone to show that X, Y and Z exists, how to use them, for what they exists and the list goes... So, be beware to not create dependent programmers, since a dependent programmer is like a musician that can't learn a new music by it self. Is someone closed in the world that someone taught to him, and won't be able to create new things, and for me a dependent programmer is for nothing, I just won't hire him.

    Well, this is the basics of what I have experienced on teaching programming languages, and I holp that this can be useful. ;-P

    Graciliano M. P.
    "Creativity is the expression of the liberty".

      May I add the general concept that perl is a complex tool made simple for all purposes.

      It is very difficult to do complex things and yet be as simple as to do lots of useful things in only one line of code.

      Nowadays, Microsoft is proposing that their new 'revamped' software is going to make no distinctions whether it is working on the www or on a local computer. This has always been a choice with perl. It is so simple to use in a web server as it is to use it as a helping CLI tool to configure LINUX ini files, do powerful DOS commands, etc.

      One of perl's biggest targets might be to reach a point when you could do a lot of things by just writing a simple command.

      _`(___)' __________________________
Re: A tutorial for Perl to teach Beginners
by theroninwins (Friar) on Sep 07, 2004 at 05:58 UTC
    Thanks for all the comments that reached me til now.. since the feedback is so good I would like to quote some for you thought in the beginning of the book so that beginners that read it know what thought others have and what others think of the language... for me it is very motivating to see that others are interested in that subject to. (If you don't mind me to do so I would ask you to either give me the line from who I have qouted i.e. "John Smith, member of Perkl Monks" or "theroninwins (membername at Perl Monks)" or somthing similar. I will at some stage on the way but up a thread with all the names from whom I which to quote, but I would like to know if you would mind me do so in the first place.
      Oh dear, I don't think you'd want to mention that PM exists? The learners might think there's a large group of people that _like_ the language and are interested in learning and sharing! Who knows what could happen...
Re: A tutorial for Perl to teach Beginners
by tilly (Archbishop) on Sep 07, 2004 at 16:59 UTC
    I've seen a number of tutorials written by beginners for beginners, and I unfortunately have to tell you that I don't see them as being very valuable for other people.

    The problems that each beginner has are different, because they relate to that person's background and misunderstandings. If you watch beginners learn a skill in class (any skill, any class), you'll often see two people next to each other getting opposite advice. That's because they are doing it differently.

    Furthermore a beginner's advice is always somewhat dangerous because as a beginner you still don't know what you're doing wrong. It is therefore easy to offer well-intentioned but dangerously wrong advice. And even easier to offer bad examples of how to do things.

    As an example, I'm in the process of learning how to play beach volleyball better. It is easy to find well-intentioned beginners who are willing to pass on tips. Easy - and useless. I far prefer getting advice from a course that I'm taking. Even though the instructors may have forgotten what is hard to learn, they know from experience what people usually need to hear. Furthermore they have the experience to see and tell me what I'm doing wrong.

    Think of this another way. It is very difficult to learn to be better than your teacher. Why, then, would you want a beginner for a teacher?

    But there is still value in the exercise. What you'll find is that trying to teach someone else something is a good way to force you to organize your thoughts and learn it better for yourself. You might mislead the other person and give them bad habits, but you'll likely learn something in the process. So at least try to put your thoughts down into a tutorial. Present it to some friends to keep yourself honest. Then put it aside and come back to it in a year or two. At this point you'll probably see my points - in the writing of it you learned something, but you were telling people to do things that you now know they shouldn't be doing.

      The best way to learn a subject is to write a book about it?

      (Incidentally, does anyone know who the originator of this quotation is? I only find one single mention of Serge Lang.)

      Makeshifts last the longest.

        Incidentally, does anyone know who the originator of this quotation is?

        The general attribution I've seen over the years is to Benjamin Disraeli...quoted below:

        "The best way to become acquainted with a subject is to write a book about it." - Benjamin Disraeli (1804-1881)


Re: A tutorial for Perl to teach Beginners
by KeighleHawk (Beadle) on Sep 08, 2004 at 15:56 UTC
    I think you can tell from the responses you have both hit on a good idea and that you probably have your work cut out for you. Might I suggest you cheat?

    By that I mean, rather than try to decide what is good for a tutorial, just go grab a book and write a tutorial to accompany it. This does several things:

    1. It gives you a good starting point as well as a way to focus your efforts
    2. As Brian d Foy said, you can't show them everything at once. So show them a little and let them reference the book in an obvious manner for more information. Let the book and tutorial leverage each other
    3. Maybe your efforts will start a trend for other language texts and not just beginner texts.
    4. Your initial work can be expanded on later to provide more advanced tutorials on the same subjects.

    Personally, I've always hated examples in books as they tend to be excissively simplistic or just plain contrived. Then of course, sometimes they just don't work :-) Having running code examples that walk through and explain each and every action showing side effects, etc. would sure be more interesting than a static code snippet that may or may not even run as printed...

    Some may consider this dangerously close to copyright infrignement. I don't think it is but won't go any closer than this to that discussion other than to say if the book can be used as a text for a class, this use should also be acceptable.

    Obvious suggestions are the O'Reilly books, "Learning Perl" and "Programming Perl". For a slightly more advanced and disjointed tutorial, "Mastering Algorithms with Perl".

      Please start with an introduction to perldoc in your tutorial. For most 'starter' questions answers are immediately available. A must read is regex tutorial.

        I agree this should be right at the top but as has been discussed here before, the docs aren't written for beginners; or non-programmers for that matter. They take a great deal for granted. So assuming they answer beginner questions isn't necessarily a good idea. Even when the answers are there, they are often unintelligible to the neophyte. A beginner seeing things like split /PATTERN/,EXPR,LIMIT is as unenlightened as if she'd seen nothing at all.

        I'm a newbie with perl, but have been hacking assembler since the 6502 so not really a beginner in the sense of 'non-programmer' -- if only i'd found perldoc (and knew how to use it) learning perl would be much simpler. Point to the things that perldoc can tell beginners, and give example code. What IS in perldoc? I still don't know how to find out.
        Another point where i find difficulty is OO --too old to have grown up with OO-- so a simple intro to that would be extremely useful to me at least :-)
Re: A tutorial for Perl to teach Beginners
by artist (Parson) on Sep 09, 2004 at 17:44 UTC
    Emacs has a very good tutorial for beginners built in. I had seen 'learn' on some version of unix. I think such program could be useful. If taught in modular version ex.. "regular expressions", it would be very useful. We can make a combined effort to make such 'interactive' tutorial. Once people start, they can refer to all type of resources.
      The way I plan this project it is to have a tutorial for those who prefer reading or to look up things with lots of explanations and exercises and a practical part (a program) like the emacs or vi tutorial for those people that prefer interactive learning... The prob is that I only have til end of 07.2005! to complete everything. So i really have to get started from net week onwards. (See this node for extracts of the tutorial, so you can comment on them or if I hope this will never happen some code might not be good or working to tell me so). Of course any help is greatly appreciated.
Re: A tutorial for Perl to teach Beginners
by techgirl (Beadle) on Sep 28, 2004 at 19:32 UTC

    This has come up before. I would be interested in helping, and think I can point you to a few others who might be as well.

    This thread: 324924 contains some discussion. We wondered whether the best way to teach newbies is through a wiki, a parallel XP system for completing Perl challenges, or an RPG... Any of those might be fun to work on, or use.

    I thought this thread was also related, but perhaps because I'm very interested in the subject: 325375

    I suppose the only two really useful approaches would either be something simple that would very intelligently evolve, or something very well planned out that could be useful without a huge amount of content. (It seems the two biggest drawbacks would be not enough content, or not finding a working/popular teaching approach. (I presume teaching people who are not forced to learn; as you're the professor, you may not need to worry.)

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://388753]
Approved by ysth
Front-paged by Old_Gray_Bear
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others taking refuge in the Monastery: (10)
As of 2014-07-28 17:21 GMT
Find Nodes?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:

    Results (204 votes), past polls