When I learned Perl I started with the Llama (Learning Perl), continued with the Camel (Programming Perl) and then the Big Horn Sheep (the Perl Cookbook) and the Timber Wolf (Algorithms in Perl). It took about three years.

I have used the same tactic with other Technical subjects: languages (Python, Javascript, Haskell), operating systems (Unix, Linux, FreeBSD, Solaris, zOS), tools (Vim/Vi, Nagios, Apache, SQL, shell), etc.

This is the way that I learn. I don't really know anything, I just remember where I can look it up. It's a principal I stole from Unix, keep only the bare minimum code necessary in main memory, page everything else out to auxillary....

Hello 5plit_func,

I have two pieces of advice:

1. Focus

   Many years ago I read about an experiment in which two groups of students were each given the same book to read. The first group was just told to study the book and learn as much from it as possible. The second group was told to study the book with a view to answering a specific question. Then both groups were tested on their general comprehension of the book. The second group showed a greater knowledge of the material, not just as it related to their specific question, but across the whole range of topics covered. The researchers concluded that study is more effective when has a definite focus.

   So, as you try to improve your Perl skills (and your programming skills in general), you will derive greater benefit from your reading if you have a specific problem or question in mind as you study. Pick a programming exercise — one that challenges you, but is not too ambitious — and work on it incrementally, keeping it in mind as you read and meditate. This will improve your comprehension, as well as giving you positive feedback as you see your study leading to practical results.

2. Improve your own code

   We’ve all had the experience of writing a sentence that becomes hopelessly muddled in syntax and meaning. Sadly, we often push ahead with the sentence, rather than starting again. I think the same thing happens in programming, and we become mired in a swamp of our own making. Indeed, many questions to the Monastery ask, “How can I make this work?”, when the best answer is, “Don’t! That’s not what you should be doing. Do this instead.”

   I find it a useful exercise to go back over my old(er) scripts to see how they can be improved. It can be surprising what you find when looking at your own work with fresh eyes! Or take a question from Seekers of Perl Wisdom and develop an answer — then compare your solution to the answers given by other monks. That’s a great way to learn best practices and idioms.

   Don’t be afraid to try new things and change things around. (And use version control so you don’t lose anything.) Ask always, not only How can I make this work? but How can I do this more clearly/concisely/elegantly? Keep on the lookout for useful coding tips, and make it a point to incorporate them into your own code. In this way, the good practices will soon become your own.

Hope that helps,

Thank you for this really nice node. I don't suppose after many years that you would have more information on how to find that study? I'd really like to read it and be able to cite it directly myself later.

You’re welcome. I don’t think I ever knew the details of the study, only its outline and conclusion. And at this remove I can’t even remember where I read (or heard?) about it. :-(

Sorry I can’t help,

Athanasius <°(((>< contra mundum

Iustus alius egestas vitae, eros Piratica,

Thanks Discipulus, Thanks for your reply, and thanks for your advice on how to move forward. Thanks for the links you provided. Also thanks to all that replied to my post.

The point i was trying to find out or convey was how do you spend your day at home when not programming or before you jump on the computer to programm or do anything.

You completely missed the point but your message and reply was timely and helpful.

When I first started to learn programming, the Internet was ARPANET / MILNET, and the digital computer would not become “personal” for another seven years.   (It would not become “wired” for another twenty years beyond that.)

My “very first program:   was 7 lines long, took me 6 months to write, and had a bug in it.   But ... thirty years and nearly a million source-code lines later, I haven’t stopped doing it, or sincerely enjoying it.   I continue to be fascinated with the prospect of making a digital computing-machine do useful things.

The key realization that you must make is that:   “there are really only two parties here ... you, and a microprocessor that is much smaller than your thumbnail which knows nothing at all.” Pick your language, pick your application, pick your poison ... the fundamental rules of this game have not changed in fifty-plus years.   It’s become a whole lot more well-known, even to the point of becoming “trendy,” even “glam,” and computing-resources have moved from being precious to being abundant, from being “locked in a glass-walled room” to “sharing the bathroom with you,” but the task of the digital-computer programmer has not changed!

If I told you that “all you need to do is to ‘learn how to write code,’” then I would be lying to you:   I’d be saying to you, in effect, that the only thing you need to do in order to become a Master Carpenter is to buy a hammer and a great-big bag of nails.   I would be indulging in a deceit that is “technically true, yet totally false.”   Perl, like any and every other programming-language, is a tool, and “mastery of a Tool” is merely the Beginning.   It is not the End.

The journey that you are embarking upon is a Trade.   If it captivates you enough to endlessly fascinate you, then it can become a Career that you consider yourself very privileged to have.   But if not ...