I admire your philosophy! I purchased Learning Perl on win32 Systems by Schwartz, Olson & Christiansen read and worked the exercises and use it daily but now at a point where I want more. I want to get a hard copy of the perl reference, but not sure what and how to print it out. I'd like to start with the Perl Manpage, POD's (Supporting Manpages) and Perl Module Library. I can only print individual segments from perldoc.com. Does anyone know of an easier way to obtain this? There's a lot to be said for having a hard copy. Can't take my computer to bed but sure would like to fall to sleep skimming through perldoc.
Jeff -----Original Message----- From: Michael R. Wolf [mailto:[EMAIL PROTECTED]] Sent: Saturday, December 29, 2001 12:35 AM To: [EMAIL PROTECTED] Subject: Re: Good CS Literature Luke <[EMAIL PROTECTED]> writes: > I bought the Learning Perl by Orielly but I returned it > after realizing thats its almost the same as > perldoc/manuals... "Learning Perl" is a tutorial perldoc is a reference [...] > My problem with programming is that i dont know if im > doing the right thing... It sounds like you need a tutorial to start with. The references are good once you've got a lay of the land, but a reference is different from a tutorial. The organization of a tutorial is to start at nothing, and build understanding in logical steps. The organization of a reference is for finding out the particulars of a given function or operator if you already know that's what you want. Perhaps you should reconsider working through the tutorial. It's how I got started with Perl over 5 years ago. I worked through it *once*, then never looked at it again. It's a "disposable" jump start into the reference (which is dog eared and very heavily marked and used). > Yes the program/script works but Im not sure if its > effecient or not... I, too, started programming as a senior in HS. Hard to believe that's 20+ years ago. Time flies like an arrow (but fruit flies like a bannana). One of the things I've learned in that time is that most jobs have two steps. 1. get it right 2. get it fast Most jobs don't have the luxury of getting to step 2. Apply the rule of ducks - if it looks like a duck, quacks like a duck, and possibly flies like a duck -- it's probably a duck. Translated: If it looks like it's working software, and it acts like working software -- it's working software. (i.e. who cares if it's not effecient? If you care next week, you can re-work it next week.) And, as a training exercise, you can take working software, make some changes and see what happens. If you break it, restore it and try something different. What did you learn? If it still works, what did you learn? The basic idea here is to have *working* software to muck around with. You don't learn as well with broken software. Get it to work (dirty, ugly, slow, whatever....), then keep it working as your refine it into clean, pretty, fast software, and learn lots along the way. If you work with broken software, you're not sure that what you did to transmute broken software into broken software is something worth remembering. We call it playing with code, but it's really a code word for learning -- take a look at my signature file, and have fun. Computers have been a continual mental exercise, and larning adventure for me. Good luck on your adventure, Michael -- Michael R. Wolf All mammals learn by playing! [EMAIL PROTECTED] -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
