Hey there,

I was reading in the Camel book today, about packages. Lately I have been forced, in a good way, by a project thought up at high command, to learn Object Oriented Programming in Perl.

So I went to read in the Camel book on the subject. Since then, I have been swung from left to right in the world of Perl. As one little tidbit of information would lead to another, I was propelled to basic knowledge and Perl peculiarities like a rubber ball in a closed compartiment.

Of course folks in the CB were more than helpful to answer my growing amount of new questions, thanks again - you know who you are - , but something began to burn in the back of my mind, insecurities as always - am I doing this right?

See, I could do this in two ways (afaik), which is more than one, as usual in the Perl world. These would be:

Both have advantages and disadvantages. Would I learn what I think I need to know - it will take time before I can start the actual programming, but at least I start prepared. In any case though, I will probably end up at the other choice. Plus, I've noticed that trying to understand the subroutine chapter in the Camel book is not in my league yet.

If I would start with what I know now, I would be faster on my way but would also be slowed down by constantly having to look things up. The good thing about this choice is that maybe there's not much more for me to learn, thus it would quicker than the other choice.

Or maybe I am seeing bears, wolves and lions where there are actually none.

At least I got this off my mind. Thanks for reading.


Replies are listed 'Best First'.
Re: How to start. || Ramblings of a confused mind.
by theorbtwo (Prior) on Jun 09, 2005 at 00:59 UTC

    If your perl is half-decent, with the exception of not knowing packages and OO, then you are largely worrying over nothing. The beauty of perl's OO and packages is their tinyness. OO is just bless, @ISA, and a little bit of syntax. Past that, it's things you already know, mostly hashrefs.

    Warning: Unless otherwise stated, code is untested. Do not use without understanding. Code is posted in the hopes it is useful, but without warranty. All copyrights are relinquished into the public domain unless otherwise stated. I am not an angel. I am capable of error, and err on a fairly regular basis. If I made a mistake, please let me know (such as by replying to this node).

      I might have focused on that too much. The main thing is that there's just so much information available, how much should there be learnt, when is one "fit enough" to start on a project.

      I can just start coding now, but perhaps I will find much better ways of writing the same code, I might have to rebuild/update a lot of my scripts, which would take time. Time I might have saved by starting well prepared.

      That is kind of what I'm getting at.

        If you take that attitude, then you'll never start coding.

        Besides, if you keep reading you'll run into a lot of apparently (or actually!) contradictory information. There is no way to sort this out without having an experience base of your own to draw from. And other things that you'll read you will likewise not understand unless you have some experience under your belt. Finally all of the theory in the world does no good unless it becomes reflex, which again takes practice.

        So there is a chicken and egg problem here, you don't want to start until you have the skills, but you cannot develop the skills unless you start.

        The answer is to do all things at once. Be aware of what you don't know or don't know that well, and proceed. Be sure to re-evaluate periodically. Continue to learn, practice, read and grow. At some point this is the only way that I know to learn a practical skill.

        However, if you can, it is good to make the first few projects that you do be things which are unimportant, so the inevitable mistakes are not a big deal.

        You may or may not really save time doing that. The problem is that you understand things so much faster when you use them, or at least you do when your brain works like mine. So yes, you will rewrite things when you discover better ways, but you won't spend time scratching your head, not really getting it.

        If at the end of a project, I don't know anything that I didn't at the beginning -- if I would have done it all the same way -- then it's a sure sign I didn't learn anything, and that's a bad thing.

        Warning: Unless otherwise stated, code is untested. Do not use without understanding. Code is posted in the hopes it is useful, but without warranty. All copyrights are relinquished into the public domain unless otherwise stated. I am not an angel. I am capable of error, and err on a fairly regular basis. If I made a mistake, please let me know (such as by replying to this node).

Re: How to start. || Ramblings of a confused mind.
by Aragorn (Curate) on Jun 09, 2005 at 08:18 UTC
    I'd recommend Object Oriented Perl for learning the details of Perl OO programming. I expect that the "rubber ball in a closed compartment" feeling will be much less when armed with that book.


Re: How to start. || Ramblings of a confused mind.
by zentara (Archbishop) on Jun 09, 2005 at 10:45 UTC
    Learn everything I think I need to know beforehand

    Go with what I know, learn as I go

    Learn as you go is the only sane approach. There is just too much knowledge out there, for you to decide what you need to know before hand. You end up filling your mind with useless details which ends up being discouraging.

    My approach, "get the big picture first" and get a hold on the vocabulary and words that are involved. Then find a simple example which forms the basis of what you want, and go from there. Now you can start digging for details on how to deal with your immediate problem.

    I'm not really a human, but I play one on earth. flash japh
Re: How to start. || Ramblings of a confused mind.
by johnnywang (Priest) on Jun 09, 2005 at 04:49 UTC
    Of course it's the second choice: get started with what you know now. This is not really specific to perl, not even to programming, it's the way to learn anything.

    It's like learning a natural language, say English. Do you wait until you learn all the English words and grammar before starting to use it? Of course not, just look at the kids.

Re: How to start. || Ramblings of a confused mind.
by radiantmatrix (Parson) on Jun 09, 2005 at 15:37 UTC

    Writing code is, in many ways, no different than writing prose. The best piece of advice I ever got in both cases is ot just start writing. Remember, in both prose and code, writing is an iterative process. You'll rewrite things -- maybe even several times -- before you get them the way you want them.

    Also, the first few things everyone writes are crap. That's ok. Write crap that no one else needs to use, but that helps you; I cut my teeth writing horrible little automation scripts to handle some thing on my home Linux machine. They are embarrassing now, but I learned a lot by doing them.

    Pick a problem, and see how much of it you can solve with the skills you have. Look up what you can't solve on your own, and ask the community for help when you're stuck. Then, go back and try to make it faster, more reliable, etc. Then, refactor into another Way To Do It.

    For example: write a script that emulates the basic functions of the UNIX ls command. Now, do it with subroutines of no longer than 10 lines each. Now, split groups of subs out into modules (you might have to learn about modules to do that). Now, make those modules OO instead of exporting. At each point, update your main ls script to use the new system.

    Exercises like this tend to teach you a lot, because you can solve a problem you already know a bit about (listing files), and you have a reference for what "correct behaviour" is (the ls command). Revising will make you see where some things are difficult, but more importantly, it will help you see a few different ways to do things, and what some of the tradeoffs are. If you do this with a few simple projects, then you can start on something a little bigger.

    And remember, when you're done, it will probably be crap. ;-) That's OK: writing crap is how you get comfortable with writing, and as you get more comfortable, you write better. I've been coding in Perl for several years, and most of what I write is still crap -- but it's less crappy than it was when I started, and someday I might actually write good code. Very few people write truly good code.

    Yoda would agree with Perl design: there is no try{}

Re: How to start. || Ramblings of a confused mind.
by wfsp (Abbot) on Jun 09, 2005 at 05:35 UTC
    I'm an avid supporter of the "get something up and running school". Anything.

    I can see a snag though. When the boss says, "Yes, that's very good but what has the Flinstones got to do with it?".

    Nod sagely and say, "Ah, all will become clear". And keep your fingers crossed!

Make a plan
by Anonymous Monk on Jun 09, 2005 at 19:22 UTC
    When you write an essay, you don't just "dive in and write". You make a plan, called an outline, figure out what your major themes will be, how they'll prove your thesis, and how they'll link. You design an introduction and a conclusion, and then you put all the pieces together.

    Coding is the same. Build an outline. Figure out what the job is. Break that job into smaller concepts. Figure out how those concepts relate, and what the inter-dependancies are. That will tell you something about the data you need to pass between them. Work top-down and bottom up towards the middle, and know what the plan for each section is before you start. Draw block diagrams, and see how each block fits together with the others.

    Document your design: both in your code, and outside of it. Six months from now, you'll forget what you were trying to do. Write comments first, then write code that matches what the comments say. Make sure the comments explain what you're trying to do, and not just how. Keep them up to date.


    # Bad comment example # get characters 5-14 of DIALED into $y $y = substr($DIALED,4,10); # Good comment example # Extract the destination phone number from the dialed # digits field. # Skip over the speed dial digits. $dest_phone = substr($DIALED,4,10);
    Sure, by all means, do small scale, proof of concept experiments, try stuff, and learn what you can "by doing". But don't forget to practice designing your code: it's an important part of the craft of programming..

    Finish reading the chapter on subroutines! Subroutines are arguably the most important idea in programming. Learning to break a big problem into sub-problems, and carefully solve each piece one bit at a time is an imporant life skill; and not just when it comes to programming.

    Good luck, and keep learning! Keep asking questions; of yourself, and of others. The most important part of the learning process is to keep learning. :-)

    Ytreq Q. Uiop