How DO those monks do it?

Replies are listed 'Best First'.
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.	[reply]
RE: RE: How DO those monks do it? by jptxs (Curate) on Oct 20, 2000 at 07:54 UTC
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. -- I'm a solipsist, and so is everyone else. (think about it)	[reply]
(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=http://www.iarchitect.com/lotus.htm">"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. Cheers, Ovid Join the Perlmonks Setiathome Group or just go the the link and check out our stats.	[reply]
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.)	[reply]
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: Although high general intelligence is common among hackers, it is not the sine qua non one might expect. Another trait is probably even more important: the ability to mentally absorb, retain, and reference large amounts of `meaningless' detail, trusting to later experience to give it context and meaning. A person of merely average analytical intelligence who has this trait can become an effective hacker, but a creative genius who lacks it will swiftly find himself outdistanced by people who routinely upload the contents of thick reference manuals into their brains. (During the production of the first book version of this document, for example, I learned most of the rather complex typesetting language TeX over about four working days, mainly by inhaling Knuth's 477-page manual. My editor's flabbergasted reaction to this genuinely surprised me, because years of associating with hackers have conditioned me to consider such performances routine and to be expected. --ESR) 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.	[reply]
RE: RE: How DO those monks do it? by Caillte (Friar) on Oct 17, 2000 at 15:22 UTC
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.	[reply]
(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. redmist redmist.dyndns.org email::redmist	[reply]
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.)	[reply]
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. When you are just starting to write a program of any sort, do you have a specific way you go about 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...	[reply] [d/l] [select]
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!	[reply]
RE: How DO those monks do it? by lachoy (Parson) on Oct 17, 2000 at 17:37 UTC
In a different vein, there's a really excellent book out about programming in general -- it doesn't tell you DO IT THIS WAY but rather gives you guidelines about thinking about practical (rather than academic) programming. Check out The Pragmatic Programmer for info and some extracts. Bonus: It's broken into discrete, fairly short sections: a perfect bathroom book!	[reply]
RE: How DO those monks do it? by runrig (Abbot) on Oct 17, 2000 at 21:21 UTC
I STILL constantly refer to 'perldoc -f <perlfunction>'and find it invaluable. Just yesterday I had to look up the arguments for index() and their order. It was a happy day when I found out about the '-f' option and didn't have to search through 'perlfunc' anymore. I wish you could do that with all the perl modules too. At the more general 'how do I do something' sort of level, I've found the perlfaqs very handy. When I needed to fork(), there were examples in perlipc. Since I've scanned all the perldocs, I have a vague idea of most everything in there, and if I can't find it in there, then I'll go to a book (I have the Cookbook, and at my latest work we have all the other books also). I just wish I had all the animal books to refer to when I was just learning perl, all there was was one crappy book at work, so the perldocs were usually more helpful. (Why didn't I go get'em myself? I dunno...). I try to write code in small bits that can be tested separately whenever possible. I hate it when someone modifies a large application and breaks it when a small test case could have avoided disaster (which is becoming my latest justified pet peeve). I'll benchmark if I think its worthwhile and/or if I have time and/or if I'm just curious enough. Going back to that 'index' function, I was wondering how much faster using 'index' was versus a regex, because a co-worker wrote a split using a regex, and index() could have been used instead. It was something like: `my ($str1, $str2, $str3, $str4) = /(.)<tag1>(.)<tag2>(.)<tag3>(.)/;` I was fairly certain that using index would be faster, but not sure by how much. Even the regex could have been sped up by adding '?' after the '' in all but the last group. For the curious, on 500 iterations, using index benchmarked for me at ~0.1 seconds, the bad regex at ~6 seconds, the slightly better regex at ~3 seconds. So in 500 executions of this script, we can save 5-6 seconds, which may or may not be worthwhile in the big picture, but at least my curiosity is satisfied. Oh well, I don't know if that helps any or not, but Good Luck* to you.	[reply] [d/l]


Perl: the Markov chain saw
	PerlMonks