Recursion?
 

I was wondering if anyone knew whether the 2k4 robot controller and/or the edu controller would support a recursive algorithm. Obviously, it'd have to be small due to the limitations, but I just want to know if it could work. Thanks!

Re: Recursion?
 

You would probabally have some trouble with the limitations... If you could use the recursive algorithm you might run into a lot of problems... why are you so interested in using it?

-Greg The Great

Re: Recursion?
 

Yes, it would definately work. The only realy problem I see is that the PIC controller doesn't have an overly large stack space, meaning you should make a point of not getting too deep into the recursion. Otherwise, a function call is a function call is a function call, regardless of whether it originated from itself or from a separate function.

Re: Recursion?
 

unfortunatly, i realize that i cant go too deep. thank you.

but, given the language/compiler i'm also wondering, when i do the recursion, will the variables within the function allocate new memory every time? or will it use the same memory address for the local variables for all the calls?

Re: Recursion?
 

Yeah, I think the hardware stack is 32 bytes, so subtract a few from already nested CALLs and you can get about 28 recursions. I doubt you'd need or use that many though.

For your second question, it depends on what modifier the variables have in front of them. See the compiler docs in your mcc18/docs folder.

The auto modifier is the default one (it's default by default, you can make static default if you want). Auto variables are the ones you are used to. They just get shoved somewhere in memory when you declare them and go away when they lose scope. So with recursive functions if you have a bunch of auto variables you allocate new memory for them each recursive call. That way when you leave the recursive function the original varaibles are still intact.

The static modifier defines them globally, but they have the same scope as an auto variable. So if you define them in a function you can only access them in that function, but the variable never gets deallocated, so you can transfer the same value from one function call to the next.

The above 2 are the same as ANSI specs. The compiler also adds one called overlay, which is like static except you can reinitialize it each time the function is called. If you have "static int a = 1;" in a function, a is only given the value 1 when it is declared, and not every time the function is called. "overlay int a = 1;" will set a to 1 each time. There is more stuff on overlay in MPLAB-C18-Users-Guide.pdf. Note that overlay cannot be used in functions called recursively (from the docs).

Re: Recursion?
 

The stack size is actually 31 words, not 32 bytes, but the principle is the same. Also keep in mind that you probably can't do the full 31 calls since chances are the initial call to your recursive function already had some stuff on the stack. For example, in the following sequence of calls, 3 stack frames are already used before it even gets to the recursive method. Also, be careful when using interrupts, since an interrupt will also push a frame onto the stack, and if you've already used up the entire stack with recursive calls, you'll get a stack overflow exception.

int main(){
user_code();
}

void user_code(){
doAuto();
}

void doAuto(){
recursiveFn();
}

void recursiveFn(){
recursiveFn();
}

Re: Recursion?
 

Oh right, I don't know why I stuck the word bytes on there. I meant 31 locations, each which store 21 bits.

Re: Recursion?
 

recursion
recursion is
recursion is evil
recursion is evil I
recursion is evil I tellya

I agree recursion is evil.
 

Recursion is a bad pracice on any platform and should be avoided. The PIC will crash after something like 28 levels of function calls. You should read up on the stack and how it works. Basically there is something called the stack, which can be thought of as well... a stack. A stack of books or plates or whatever floats your boat. The stack is used to keep track of function calls interrupts etc. Whenever a function is called, the memory address of whatever the processor was doing before the function call is "pushed" onto the top of the stack. The processor then jumps to the function and executes its code. When the function returns the stack is "popped", cuasing the processor to jump back to where is was before the function call. When functions are called inside of functions, multiple entries are made to the stack. The problem with recursion is is that the stack is a limited resource and eventually it overflows.

Re: I agree recursion is evil.
 

That statement is completely false. The use of recursion completely depends on the problem at hand.

For example, the non-recursive solution to the classic Towers of Hanoi problem is significantly more complicated than the recursive solution.

Or, a non-recursive program to find and show the correct path through a maze is significantly more difficult to implement than the recursive solution.

Recursion is an essential technique for any application which uses a tree data structure. I've written several web application that require directory traversal... without recursion, these would have been near impossible.

I'm not going to disagree with you that recursion is a bad practice on the robot controller due to its limited memory and stack, but to state that recursion is a bad practice and should be avoided is completely false. There are advantages and disadvantages to recursive algorithms vs. iterative algorithms - in some cases, the recursive solution is better than the iterative solution, in other cases, it isn't. It depends completely upon the problem at hand.

Re: Recursion?
 

Sorry, but I must put my two cents in as well. You must not program in Scheme! It's a very lovely langauge, but as far as iterative algorithms go, you're dead in the water -- you must use recursion (well, there is a difference between recursive procedures and recursive proceses, and scheme implements a lovely thing known as tail-end recursion). Anyway, my point, if you want to be schemer, you better recurse. Favorite quote: "To iterate is human; to recurse is divine."

Re: Recursion is evil
 

I totally disagree. When you have the resources, recursion is an invaluable tool. It's the heart of Deep Blue's chess game, Google's page ranking system, and the fastest sorting algorithm ever written. Although looping is usually more efficient, recursion is much simpler, and once you figure out how to do something recursively it's often very easy to write a loop that does the same thing.

That said, using recursion or looping in your FIRST code is probably a bad idea. Aside from recursion's stack problems, both methods can eat up a lot of time if you're not careful, which would slow down your robot's reflexes. Also, I can't see what you'd need it for! Most of what your robot does is reacting to stuff, not calculating.

~~Aaron

[edit]Oops, I just saw Dan's post where he says the same thing. Go Dan! Way to steal my thunder... ;)[/edit]

Re: I agree recursion is evil.
 

http://www.kernelthread.com/hanoi/

Yes, recursion is very helpful for the path finding algorithm. :)

Though, I am rather unimpressed with the stack size of the Microchip products. The 16 bit motorolla microprocessor that I implemented said pathfinding algorithm on was nice because the stack could be of any size (up to the limit of RAM).

Back towards the topic... Recursion can greatly simply many algorithms. Fibonachi is a good example of that. Infact implementing fibonachi as recersive and iterative tends to be a common problem given by CS-101 professors, to help illustrate recursion.

Though however, with recursion you can trade simplified code(and possibly faster) for increased memory useage. So, to sum up slightly, the use of recursion, iteration, (or anything else) really needs to be determined based on what your goals are (speed, size, time to impliment) and what resources you have available.

Of course that summary could be applied to any engineering decision.

Re: Recursion?
 

I dont think recursion has any real advantages - its simply a sloppy (lazy?) method of performing certain functions for people who forget that

SW = ALGORYTHMS + DATA STRUCTURES

if you use simple data structures, then yes recursion makes the code look cleaner and simpler

but with a well thought out data structure, there is nothing you can do with recursion that you cant do better without it.

The thing about recursion is, most SW programmers are oblivious to what happens when you call a function - more gets pushed on the stack than the return address, some processors or operating systems push a ton of junk on the stack, and then you have to pull it all back off

remember that the variables you see in higher level languages (like C) most likely are not registers in the uP, they are probabally memory locations assigned or created by the compiler.

Re: Recursion?
 

Ok ok. I can see we all seem to like recursion. The more i think about it, recursion may have advantages under certian circumstances, but don't do it on the RC.

Re: Recursion?
 

I bet you could simulate a stack on RAM and get one with more size. It would take some work, and you would need to know some asm to do it, but I think it's entirely possible. Rather than using call to jump to the function, which pushes the PC onto the stack, you could just use goto, which just jumps striaght there. Storing variables gets harder though.

I doubt it's worth the effort. Just watch STKPTR<4:0> and make sure your recursive function stops recursing if it sees the stack is near full.

useless commands
 

If we're talking about useless things, might as well hit on the GOTO command. Why use goto for that situation instead of just using a for or while loop or any of their variations (for(;;), while(1), do-while, etc.)? Goto is a useless command. I cannot think of one situation where the taske cannot be better performed with some sort of loop. As far as i know, there has only been one situation found where go must be used to get the desired effect, i.e. break, continue, or loops will not work, and that was discovered by some fulltime programmer who was dedicating his time to finding it. So, to close up a long winded soapboxing, don't use goto.

edit: ok, that's not supposed to be a winking smiley, but a semicolon then a closed parenthesese, just accept it. Smilies.... arggh!

edit #2: as i clicked ok, i realized there was a disable smilies button, so now it works.

Re: Recursion?
 

Break and continue are simply a goto command in disguise. Break and continue should be avoided for the same reasons that goto should. The reason that software engineers really hate goto (and break and continue for that matter) is that it generally makes code harder to read. However, there are times where a well-placed goto can simplify code and make it easier to understand than it would be if you had to wrap it in a bunch of if() or for() statements.



{soapbox}
I work full time as an embedded software engineer, and I still wouldn't feel comfortable making statements like these. While I agree that gotos and recursion are generally a bad practice, I know that there's a nearly infinite amount of software engineering situations that I haven't encountered yet, and one or both of these methods may be the best solution in that situation. I'm very encouraged to see so many young people on this board taking such an interest in engineering (and software engineering in particular), and the amount that you all know about these fields already is amazing. However, do you really feel that you guys have enough experience to back these statements up?

I hope that this post doesn't offend anyone, and if it does I apologize. I am really impressed at the level and intelligence of discussion that occurs on this board. I'm just concerned that the level of misleading information around here seems to be on the rise. There's a lot of teams that are going to go through a bit of a software engineering trial-by-fire this year with the C based controller, and I just don't want to see the situation made worse by providing them with bad information when they come here for help.
{/soapbox}

Re: Recursion?
 

By the way, I didn't mean the C command goto, I was talking about the asm command goto.

In asm the only way of "looping" is with goto's or branches.

I think the idea of goto being bad coding practice comes from BASIC. Programs with large numbers of gotos get incredibly confusing to read, since there really is no flow in the program. The program can just jump to any other point without warning and the reader is left wondering why, especially in BASIC with line numbers and statements like "GOTO 150."

for and while loops help to keep everything structured and easy to follow. Break and continue interrupt that flow, but they made their way into the higher level languages because they are useful and simplify code a lot.

Can you imagine trying to break out of a loop without break? You would need a flag, and all the code after the point you wanted to break from would have to be under an if statement to check to see whether the break flag has been set to true. It could get quite ugly.

Basically, a lot of goto's in a program is probably a bad idea, but they can be useful in certain situations. If you can find a way to do it without goto's that doesn't hurt performance a lot, do it.

Re: Recursion?
 

The reason that recursion is bad is that when it fails your stack overflows, and that is one of the failure modes that result in unpredictable behavior - its very difficult to debug, because the SW simply looses its mind

GOTO statements are bad because a function or subroutine should have one entry point and one exit point - GOTO is used when you dont really know what you are doing- when you havent really worked out the inputs, output and processing that has to happen to get the outputs from the inputs - its an indication that the programmer started writing code BEFORE he figured out what the code had to do (failed to do the high level design work first)

in all the SW programming classes I took, if you used a goto statement, or you used recursion, or self modifying code, you got an automatic F on whatever that code was for, a project, a quiz, or the final exam -

its not something to avoid, its something you should never use - if you cant figure out how to parse your input, or navigate your data structures without using these shortcuts, then you need to go back and work on your data structures and algorythms somemore.

There are HW equivalents too, like gating a clock, using one shot timers, or circuits that can generate glitchs. The shortcut you make is not worth the problems you will have when the system becomes unstable, or crashes, and you have no idea where to start looking for the cause.

Re: Recursion?
 

That depends entirely on what you mean by "better". If you mean using less stack space, then iterative is definately the way to go. If you mean faster running time, then this just simply isn't true. For example, the recursive quicksort procedure is generally significantly faster than it's iterative counter-part[1,2]. Also, for some algorithms it's next to impossible to write an iterative solution (alpha-beta searching, for example).

At the same time, some problems that may seem recursive (towers of hanoi[3], fibonacci, etc), often have much more elegant and faster iterative solutions.

The reality is that sometimes recursive algorithms are better for a task, and sometimes iterative ones are. Learn how and when to use both, and you'll be a much better programmer because of it.

[1] http://www.mathcs.carleton.edu/cours...aj/algory.html
[2] http://www.mvps.org/vb/hardcore/html...equicksort.htm
[3] http://hanoitower.mkolar.org/shortestTHalgo.html

Re: Recursion?
 

And thats why i retracted my previous statement. I try to speak only when i know know what i'm talking about, but please point it out if I or anyone else say something incorrect.

Re: Recursion?
 

(emphasis mine)

Well, sure, generally speaking goto should be avoided. But like in all things, extremities should be avoided, and one must be careful not to avoid doing something merely for the sake of avoiding it. There are some insightful discussions on the internet I will refer everyone to, that can clear up the issue somewhat. Knuth has an interesting paper on the subject, titled Structured Programming with 'go to' Statements:

(please, read on; the quality is somewhat sketchy, though, and bear in mind it was written in the 70s)

And if Knuth isn't a big enough name, Edsger W. Dijkstra has written a paper called Go To Statement Considered Harmful. (And, for those famiar with perl, there is a nice discussion at perlmonks.com).

Just remember that there are different goals in writing programs. Some programs you want to be really fast, while others you want to have a low memory profile, while others still, you want to be very readable. A goto statement might not fit into the "readability" column (and everyone remember that premature optimization is -- indeed -- the root of all evil), but it might make something go faster, which in some cases is a higher objective. You ask whether to use the goto statement? To give the "MIT answer" as my old teacher used to say all too frequently: It depends. I think it is only folly to take away a potentially useful tool from a programmers tool box (sure, the programmer has to pay extra attention to make sure he uses the right tool for the right job ... but that applies everywhere).

Re: Recursion?
 

things that seemed important back in the '70s are no longer an issue for SW. Back in the 70's mainframe computers only had 32 to 64 k (not megs, thousands) bytes of memory

you would be hard pressed to find appications today where memory utilization or processor speeds are really an issue

and in those cases, you dont code in C, you write assembly code for the critical functions.

the greatest expense in SW is debugging and code updates and maintance. Clarity and readability is EVERYTHING.

If you have ever been required to debug someone elses code, or modify it, you will know what Im talking about - goto statements turn your code into spagetti.

I wasnt kidding when I said the SW courses I took in college (6 semisters), you got an automatic F if you used them - there was no recourse or arguing with the professor either - THATS how serious of an issue these shortcuts are.

Re: Recursion?
 

Something like 90% of microprocessors sold are for use in embedded systems. The vast majority of those are still 8 bit. Many embedded systems are still constrained by the same issues as those in the '70s (obvious example: our new robot controller has only 1800 bytes of memory).
Maybe not in the desktop world. Embedded systems are still very concerned about these issues. Code execution speed is still a critical factor for things such as interrupt handlers and device drivers.
Not necessarily true. My above example of device drivers and interrupt handlers are quite often written in C, but still need to execute very quickly. In fact, I'm working with code for a device driver right now that's written in C and makes use of a goto (no, I didn't write it).
Of course. However, if you're trying to make a device that sells for $5 with an embedded processor in it, you may not have the option of using as much RAM as you like or having the fastest processor.
The same would have been true in my software engineering courses. However, that was because all of the problems on those homework assignments and exams could be done cleanly without gotos, and they didn't specify "make this code work in as few cycles as possible."

Re: Recursion?
 

Not that I'm a programmer by any stretch, (the last language I worked with was FORTRAN and not much of that) but it seems to me that college professors are not exactly known for their appreciation of the difficulties of life in the real world. In many cases they live in an ideal world of their own creation, even in software and engineering courses. (Remember "ideal fluids"?) So the strictness of how something is dealt with in school is not necessarily an indicator of its importance in the real world.

Computer languages do not happen by accident. They are constructed to serve specific purposes. Somebody put effort into developing the GOTO command and including it in the language. Since people don't usually do such things without a reason, I would say that there must be a reason for the GOTO to exist. I may not know what it is, and it is certainly not for common use, but I am pretty sure a reason exists.

Re: Recursion?
 

there is another aspect to shortcuts like goto and recursion.

In SW and HW you always want to keep your program sequence and flow control separate from your data processing

gotos and recursion violate that - what I mean is your code should look like

decision statement (will the flollowing code be executed?)
---data processing equation (outputs are a function of inputs)
---equation
---equation
---equation
---equation
---equation
---equation

decision statement (will the following code be executed?)
--- data processing equation (outputs are a function of inputs)
---equation
---equation
---equation
---equation
---equation
---equation
what goto statements do is inject a program flow statement in the middle of the data processing equations - intermixing your data and control leads to nightmares - and there really is no reason for it (which is why the professors would give you an F, there is no excuse)

humans can only think one or two steps ahead at a time - if you have a block of code, with a conditional execution statement at the top, and then two or more conditional exits (gotos) inside the data equations - it becomes impossible to look at the code and understand what its going to do in every case.

I cant put this in the right words, so here is a challenge. Next time you feel tempted to use a goto statement in a high level language, go back to the algorythm or flowchart, or bubble diagram, and figure out what you would have to do to get rid of the goto statement - and you will see how the change makes the code cleaner, simpler, and easier to read and debug.

Re: Recursion?
 

In most cases it is possible to convert any recursive algorithm into an iterative one. See if this is an option if you run out of stack space. An iterative algorithm will never run out of stack space, but may be slower in some cases.

Re: Recursion?
 

Ok.. maybe I should throw my two cents in here just for kicks...

I love goto! :)

LoL... ok, just kidding. Actually, I agree with umm.. some of the people here. Not going to take the time to figure out which ones....

Goto's are good in their place. Excessive use of goto is pointless. However, there are some instances where having a goto is good, the main one being to break out of loops in assembly language. Except we call them "JMP"'s :)

Obviously with higher level languages goto's aren't as necessary because of you have all these fun constructs you can play with to make it work, however, there is always a case where its just very easy to stick a goto in and forget about it.

Remember... programming is about laziness! The only thing that matters in the long run is whether the program actually does what its supposed to do... I'll take a working program with millions of goto's in it and bad programming practice over a non-working program that looks pretty. Of course, after I get the program I'd probably make it look prettier so I can do something constructive with it.... :D

Re: Recursion?
 

Wow... I'm almost speechless. Programming is not about laziness. Whether or not a program does what it is supposed to do is NOT the only thing that matters!!! Please get these notions out of your head. I'm sure you didn't mean it, but saying things like that could be very offensive to those of us who work as software engineers (if it didn't sound so ridiculous, that is).

I really don't know how to address those statements. If you're ever in a position to work on a project that's made up of hundreds of thousands or millions of lines of code you'll understand how absurd those two statements sound.

I'd highly recommend not saying things like that to professors, colleagues, potential employers, or on your resume... :ahh:

Re: Recursion?
 

Now wait... programs with hundreds of thousands of lines of code... thats quite different. You HAVE to have some organization otherwise that would be completely unmanageable. I'm deinfitely not talking about something like that... if the linux kernel had no structure to it then linux users would be in trouble...

However, for your own project that needs to get done, as long as it works that IS what matters. After it works, then you make it look pretty.

As for software engineering... obviously when you make code for your employer, your job depends on it being consistant with the companies coding standards and has to work with other peoples projects... but for small personal projects it isn't as necessary (unless you're perfectionist).

Theres a reason why programming traditionally has been called "hacking"...

And I still say programming is about laziness. Writing the least amount of code to get a task completed...

Re: Recursion?
 

I cannot believe you just said that. Hopefully your statements do not influence the beginner programmers that read these threads. It it absolutely untrue that the only thing that matters is that a program does what it's supposed to do (ie the function returns the correct value). Many factors are important to make a program good: speed, memory usage, readability, and maintainability are just a few. Maintainability is huge once you start working on projects that involve multiple developers and tens of thousands of lines of code. If I produced a bunch of inefficient garbage code that no one could understand or read, but it still worked, and tried to add it to my project at work I'd get reamed out. If I did it repeatedly I'd find myself without a job.

Please don't come on the boards and proclaim truth when it's merely your opinion, and worse yet, when it's absolutely wrong. Try turning in a bunch of 'working' crap for your next programming assignment and see what your professor and TA say. Then try your argument that the only thing that matters is if it works and see how far it gets you. Better yet, try it in a job interview and see if they call you back. You'll quickly discover how wrong you are.

Final note back on topic: I'm not anti-goto or anti-recursion, I think you should use whatever tool makes the most sense for the job. That being said I've never used goto since basic on my IBM PC Jr and never used recursion since my freshman year in college when we used scheme.

Mike

Re: Recursion?
 

a) read above :)
b) Actually, the way I do my assignments, and the way I program for the (admittedly small) projects at my work is first make the program work, then format it according to the assignment/project guidelines. And if you're giving the code to someone else, then it won't do them any good if they can't understand it. But I repeat myself. Stupid 56k...

[edit]
Also, if a program is too slow or eats up too much memory, doesn't that fall under "not working properly?"...
[/edit]

Re: Recursion?
 

Actually a lot of engineering is about laziness in this sense. Accomplishing the most with the least expended effort. One of the early Industrial engineers, Mr Frank Gilbreth, was known to walk into a factory he was to re-organize and ask the supervisor for his laziest man, the lazier the better. Obviously anybody that lazy who was still there had some smarts about how the job could be done better...

Re: Recursion?
 

That's a very misguided way to approach any problem whether it be a personal project or something for your employer, whether it's software, mechanical, or anything else. Quite frankly, attitudes about "personal projects" like that tend to carry over into one's professional activities. Conversely, making use of good engineering practices on personal projects will almost certainly make you a better engineer at work too. As they say, "practice makes perfect."
Do you really even know what "hacking" means? From the Hacker's Dictionary (seems only appropriate):
I don't see anything in there about sloppy, messy, or unstructured code. In fact, I think the definition above implies that a "hacker" strives to find the most elegant solutions possible. In any case, few people outside of high school, college, or Hollywood refer to writing software as "hacking".
Well, I certainly hope I never have the misfortune to have to work with any code you write. Being lazy may make it easier to write an initial version of a program, but then when you decide to add an additional feature you'll quickly burn up any advantage from being lazy in the first place. And then there's the case when you go back to code you wrote 5 years ago and want to modify it. If it's not done well, you'll end up spending a good deal of time just reading through it trying to get a grasp for what you were thinking back then. Nearly every software engineer I know has been through this, and none of us will ever make that mistake again. Sounds like you're unwilling to accept our warnings, though. Oh well, I guess some people just need to learn for themselves.

Re: Recursion?
 

Ok.. this has definitely gotten way off topic.. I think I'll just start a thread about it...

Re: Recursion?
 

Wow. Some of these comments truly baffle me. Computer Science/Software Engineering is NOT about laziness, it is NOT about writing as little code as possible, and it is definately NOT about being sloppy and fixing it later.

In the course of writing RoboEmu, RoboGUI, etc, I took a lot of shortcuts in order to crank out code at a seemingly blinding pace. That worked just fine while RoboEmu was about 5,000 lines and didn't support loops, multiple program slots, pbasic 2.5, project files, or any of those extra features that made RoboEmu so popular. As it turned out, somewhere around version 1.05, I had to go back and more-or-less gut the entire UI because I had done it in the least amount of code possible. Then, when I started the Linux port, I had to go through the same thing all over again because I didn't properly separate my UI code from my core code; I had originally started with them separate, but in order to crank out code, I took shortcuts, broke my encapsulation, and caused more headaches than I care to remember.

Similarly, I recently tried to go back and fix up RoboGUI, but I couldn't even read my own code. At this point, RoboGUI is all but dead because of my laziness earlier.

Fortunately, I've learned from these mistakes, and RE2 is being fully planned out on paper as we speak. I haven't written a single line of code for it yet, but I already have a better grasp on the "big picture" of it than I ever did on RoboEmu, despite hours and hours of coding it.

Go ahead and think that laziness is the way to go. Go ahead and think you'll just fix it up later. Go ahead and think that less code is better. Someday it will come back to bite you.

Re: Recursion?
 

My opinion on this whole subject is that there is a place and time for using gotos and recursion. They probably aren't things you should use on a daily basis if you can avoid them, but they can be a tremendous help.

An example of the need for recursion is this. I was writing a Perl/Tk script and needed a way to be able to change the color scheme of all my widgets (GUI elements).

The heirarchy of widgets in Perl/Tk is similar to that of Java, where widgets are packed into other widgets to get the desired layout. I needed to be sure that all subwidgets of the main widgets were affected by the color change. The problem was those subwidgets could have subwidgets, and those could have subwidgets, and so on.

I decided to use a recursion technique to allow processing of an infinite tree of widgets and subwidgets. This allowed this function to be placed in a library as something that could be called whenever and wherever it was needed.

This is an excerpt from that code. To do this iteravely would be nearly impossible.

Re: Recursion?
 

Rob - This is one of the major keys to software engineering, and I'm glad you were able to realize it early on. There is a ton of documentation that goes along with complex projects.

I am working on a small feature right now, and have over 30 pages of requirements for it. That then translates into 40-60 pages of design before into thousands of lines of code.

Software engineering is more focused on the design of the system rather than the code itself. If a system is well designed, the code is simply an extension of the design.

Re: Recursion?
 

Laziness? Well, seing as perl was, at least in passing, mentioned earlier, I can't let this escape me ... while programming in general might not be about laziness, laziness, impatience and hubris are at least somewhat what Perl is about (well, they call them the three virtues of a perl programmer).

That said, certainly "laziness" here isn't to imply that you are sloppy, or merely "hack" something together. Trust me: from all too agonizing of experience, I've learned again and again what I should have already known ... before you ever write a line of code, you should have not only thought it out extensively, but have written out with pencil and paper the data structure, the program flow, and any other pertinent things. Systems need to be organized, big or small -- and you need to allow for extensibility/code reuse. Writing code quickly is one thing ... being able to quickly fix an error at competition, however, is -- in my most humble opinion -- slightly more important! (and the two are typically in conflict).

Re: Recursion?
 

i don't think trashing an entire program just because it contains a single kludge is a very good practice. the things you mentioned are ill-advised in most situations, but saying that you must religiously avoid them under all circumstances can make life needlessly difficult in the few situations when they are needed.

In Practical C++ Programming for O'Reilly, Steve Oualline wrote
don't get sloppy, but don't be afraid to break the rules when it makes sense to do so.

~Aaron