
go ahead... be a heretic

How DO those monks do it?

by jptxs (Curate)
on Oct 17, 2000 at 07:32 UTC ( #37088=perlmeditation: print w/ replies, xml ) Need Help??







Comment on How DO those monks do it?
Download Code
(Ovid) RE: How DO those monks do it?
by Ovid (Cardinal) on Oct 17, 2000 at 07:52 UTC
    Short answer: it depends.

    How I approach any given programming problem depends upon the nature of the problem. The first questions I always ask are "what needs to be done" and "why does it need to be done". That second question is crucial. Quite often programmers gather all their specs without asking "why" and return with an program that fits the specs, but not the needs. Users often are not able to accurately state what they want. When you understand why they want it, you usually can provide them with assistance in understanding their needs.

    After I've answered "what" and "why", I determine my available resources. Whether or not I'm forced to use a MS SQL database, have a dedicated file server, or am able to specify what tools my customers can use (usually in terms of browser) makes a huge difference in terms of what I can do. There's also schedule and budget, but I think that's beyond what you're asking.

    After I've gotten my users to sign off on the work, I start to dig in. If it's something simple, I often find a program that does something similar and modify it. However, for moderate-to-difficult tasks, I start from scratch. Typically, I'll do a rough heirachical sketch of the program functions. For tough jobs, I do a modified Warnier-Orr diagram of the components along with diagrams showing how different pieces interact. Of course, I also look for CPAN modules (if I'm using Perl) that will handle the functionality I have drawn up. No way in heck are you going to find me writing my own CGI parser.

    Then comes the programming, debugging, development of test plans, etc. If enough of the work is done properly up-front, the programming and follow-up is actually the easy part. Note that all through this phase, I want to go back to my customers (if possible) and say "is this what you want?" Too many times a programmer or company will go into seclusion for a month or two and come back with an unuseable product because they didn't bother to consult with their end-users (can anyone say <a href=">"Lotus Notes"? I knew you could).

    However, I think the most important thing is to learn fundamental concepts of structured programming. The beauty of a properly structured program is that you can revisit it later, break it down easily, and swap out portions with better code without interfering with the over-all functionality (at least, that's how it should work).

    The rest is just experience. Personally, I read the Perl Cookbook quite a bit. The code in there provides great examples of how to code and plan for eventualities.



(redmist) RE: How DO those monks do it?
by redmist (Deacon) on Oct 17, 2000 at 07:54 UTC
    What I usually do is take out a pencil and paper, go out on the porch, and write down what I want, why, and how. I then go back to my machine, sit down, collect myself, and then churn out little bits, debug, and continue. I find that debugging as you go along is very helpful because you can isolate errors easier that way. Also, writing down what you want before you begin is wise because you minimize the chance of locking yourself into a piece of code that you will have a hard time adding or taking away functionality from.

    As for the docs, I first go to Programming Perl, and then to perldoc, and then to the Net, but any way that you deem fit is the Right Way for you.

    Another thing is that there is no magical thing that you can do to become a guru. It is just a matter of time and persistence. Hope this helps.

RE: How DO those monks do it?
by chromatic (Archbishop) on Oct 17, 2000 at 07:57 UTC
    1. I've read seven or eight Perl books in the past year, and they're all within arm's reach. My memory's just photographic enough that I can sometimes recall the page I've read something on previously. In addition, once you've used perldoc to look up a function or a FAQ a few times, you'll remember it when you need it next time.

    Besides that, I'm not afraid to do a little testing on my own and figure things out. That comes with experience.

    2. I tend to go for the challenging or interesting parts first, doing a bit of pseudocode in comments just to get the algorithm and flow right in my head. Then I fill in the blank spaces, test, fix bugs, test, and keep up that cycle.

    I tend not to do much benchmarking and optimizing as a separate step. Sometimes you can get a feel for how code works, again with experience.

    If I were you, I'd get the Perl Cookbook and read through the FAQ a couple of times. Reading the function descriptions in Programming Perl wouldn't hurt, either. (You have to know what tools you have and you have to know how to pick the right tool, so you need to learn both at once.)

RE: How DO those monks do it?
by johannz (Hermit) on Oct 17, 2000 at 08:00 UTC

    Answer 1: I don't even try to memorize everything. I skim everything I can get my hands on. When I'm bored I've been known to take the Cookbook into the bathroom with me and open to a random section and just read. I peruse my various books and gather information and just let context establish itself.

    To quote the Jargon file:


    Then, when I have a problem present itself, I dig into my mental indexes and see what I can find. Then I go to the source and look up any details that might be relevant.

    Answer 2: I tend to not work on paper at first. I mull over the program, analyzing areas that I think I will need to concentrate on. Once I have the overview in my head, if I'm going to be working with someone else, I will write notes and then brief them. Then I start coding, only sketching stuff out if it looks hairy. I'm finding as I work more and more with others that I need to start changing my style and communicating better the vision in my head of where the program is going.

    I usually don't even worry about benchmarking unless the code is really running slow. I tend to write clean code and it can usually handle any amount of data I send against it. If I need to, I will review my algoritms with some of my fellow perl monks that work with me.

      Ditto, The Perl Cookbook is my favourite bathroom reading too. (And the wife thinks I'm mad ;))

      The route through the docs I take depends on wheither I'm on a linux or Win32 system. In linux its Perldocs then Camel book otherwise I read the HTML help from activestate before getting up and walking the terribly long yard that stretches between my computer and my bookacase.

RE: How DO those monks do it?
by Zarathustra (Beadle) on Oct 17, 2000 at 08:56 UTC

    First off, I am not a programmer either -- but striving to be.
    ( however I *am* very Lazy, Impatient and excessively pridefull of my code... )

    At any rate, I've picked up a few things along the way nonetheless.

    When YOU need to know something, where do you ( ... ) turn to for help first, second etc

    First place I go is perldoc, everytime. Perldoc rules - it's quick, it's on your system, it's informative.
    perldoc -f is one of my favorites - I use that numerous times throughout any given week.
    perldoc perl is of course all you *really* ever need to get you on the right track.

    After that comes dejanews power search -- I *really* like dejanews.
    When I have a question about something I'm not grasping, or want to find an answer to just about anything, I head
    on over to the power search, enter a few keywords, enter *perl* in the Forum field, start browsing, and
    almost invariably, within 20 minutes or so I'll either have found a direct answer to my question, or found something
    close enough that twiddles my mind into solving the problem on my own.

    The Camel comes in mostly when I just feel like getting away from the monitor and kicking back with some dead-trees.
    I bring the Camel with me everywhere I go. It's like a bible to me. I swear by it.


    My personal approach is very strange I believe. I first tend to just sit there and stare vacantly into space for some
    length of time, then fire up vi and just start typing stuff - kind of this pure stream of conciousness deal, it's
    pretty far out. Ultimately it looks like nothing more than a bunch of jumbled psuedo-code, comments, real code,
    and unformated notes just haphazardly strewn together.

    Then I sit and stare a little longer and attempt to make sense of it all. After that point, a new file is created -
    which begins with the line #!/usr/bin/perl -w

    Then comes alot of frantic typing into numerous xterms, followed by loud cussing, gnashing of teeth and the ruckus
    of various books and things getting thrown about -- this is my debugging stage. Which is then followed by more coding,
    more thinking, and more outbursts. Until I finally have something that works.

    At that point I clean up, make things as elegant as possible, reform/re-evaluate logic, modularize and abstract where
    possible, etc. etc. This stage lasts perpetualy. I *still* don't have any "perfect" code out there, and don't think
    I ever will. There's somehow just always something else I'd like to modify/add/drop or rewrite... It's a most vicious circle.

    I look forward to being a real programmer one day.

    But then again, I'll be happy to remain nothing more than just another perl hacker...

RE: How DO those monks do it?
by SamQi (Beadle) on Oct 17, 2000 at 09:50 UTC

    Caveat: I'm not an experienced programmer

    Now, with that out of the way...::grin::

    When I go about designing a program, I typically mull it over in my head for a while. This is a big conglomeration of thinking about what the program needs to be, why the program needs to be, what the specs are, what my resources are...a very holistic contemplation of the design. Then, once I've become accquainted with the program. I begin to figure out the best way to go about doing something. I tend to try and isolate the core bits and focus on them, knowing that the glue that brings them together will flow naturally if I write those parts well. I debug as I go. Writing the code in chunks and getting the bits and pieces to work a step at a time. Fortunately with Perl, this is a very speedy way of doing things. With C++ I tend to write more at a time, but I still use the same approach.

    It seems to do me well.

    As far as the other part of the question. I myself am fairly new to Perl. I have found, however, that in general it is better to know where to find things than to just know things. I use a mixture of co-workers, internet buddies, the Camel, perldoc, and other resources. I just put my feelers out, and usually get good info back.

    Hope that's helpful!

RE (tilly) 1: How DO those monks do it?
by tilly (Archbishop) on Oct 17, 2000 at 17:21 UTC
    First of all for technical information on core Perl, of course I go to perldoc first, secondly I cast my net wider. Thirdly I go to /usr/lib/perl5/5.005/pod directory and grep for it. :-) If it isn't core Perl I have other technical and non-technical resources, Google is a favorite. :-)

    But when I am starting to write a program, I start by asking questions and talking to people. I don't write the thing until I am good and ready. For instance I wouldn't dare try to automate a process that I had not done manually at least once, I just know that there are going to be things that I will notice which I won't be told, and things that I will see should not be done how I will be asked to do it.

    As for pointers, well there is a reason that I keep on recommending reading books like Code Complete, the Pragmatic Programmer, and other classics. The links on my home node contain some good nuggets as well. If a lot of them are not very Perl specific, well the sooner you understand that you are learning how to program first, and how to program in Perl second, the better you will be.

    In fact all of the cute tricks you do with Perl, well you can do most of them in other languages as well. Oh, you may have to do some background work, but based on Perl you know it is possible, you just have to figure out how to do it! :-) (And vica versa of course.)

RE: How DO those monks do it?
by swiftone (Curate) on Oct 17, 2000 at 17:25 UTC
    Disclaimer: While everyone else may be saying they aren't great programmers yet, so take their advice with a grain of salt, I'll flat out tell you that I'm the best dang programmer in the world. I can code by tapping stripped keyboard wires in binary, and if my monitor is out, I can just stick the plug in my mouth and read the signals that way. The internet is actually a rogue piece of worm code I once wrote that got out and converted a bunch of machines into routers. Larry Wall comes to me for advice, and Linus does my bidding. I broke Enigma so fast they invented a story about capturing a sub to let the Germans retain SOME dignity. If you didn't know any of this, you obviously aren't a programmer approaching my caliber yet.

    Anyway, to address your questions:

    I think the best thing you can do is get passing familiarity with a lot of things. Read all the perl FAQs. Read threads on Perlmonks that aren't directly relevant to you yet. Ditto for several of the comp.lang.perl.* groups. Subscribe to the Perl Journal, and skim those articles. Watch the "new CPAN modules" list, and read interesting sounding READMEs. Then, when you NEED to know something, you may recall where you saw something about it.

    As for starting to write a program, that has a lot to do with the size of the program, and the technique of the programmer. In general as you gain experience, you'll do less brainstorming and psuedocoding, because you'll have more experience with the little operations. (And programs are just big operations made up of smaller operations, made up of...)

    I recommend general experience. Code lots of projects. They don't have to be big, they don't even have to be great, but they'll be experience. If you can get feedback on those projects (ala Snippets Section, Code Catacombs, or Craft), all the better. In all honesty, my coding has progressed by leaps and bounds since I found PM and have learned many things from feedback given to me and others.

      You rule. I mean that. I have tears rolling down my cheeks. I havn't laughed that much at something on my computer screen since the first time i saw User Friendly.


RE: How DO those monks do it?
by lachoy (Parson) on Oct 17, 2000 at 17:37 UTC



RE: How DO those monks do it?
by runrig (Abbot) on Oct 17, 2000 at 21:21 UTC



Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://37088]
Approved by root
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
As of 2013-12-20 02:40 GMT
Find Nodes?
    Voting Booth?

    How do you parse XML?

    Results (413 votes), past polls