Chief Delphi - Recursion?

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)

- Programming (http://www.chiefdelphi.com/forums/forumdisplay.php?f=51)

- - Recursion? (http://www.chiefdelphi.com/forums/showthread.php?t=23052)

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...

Quote:

Originally Posted by randomperson

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

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

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]

Quote:

Originally Posted by randomperson

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

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...

Quote:

Originally Posted by randomperson

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.

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."

Quote:

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

Do you really even know what "hacking" means? From the Hacker's Dictionary (seems only appropriate):

Quote:

hacker n.

[originally, someone who makes furniture with an axe] 1. A person who
enjoys exploring the details of programmable systems and how to
stretch their capabilities, as opposed to most users, who prefer to
learn only the minimum necessary. 2. One who programs
enthusiastically (even obsessively) or who enjoys programming rather
than just theorizing about programming. 3. A person capable of
appreciating hack value. 4. A person who is good at programming
quickly. 5. An expert at a particular program, or one who frequently
does work using it or on it; as in `a Unix hacker'. (Definitions 1
through 5 are correlated, and people who fit them congregate.) 6. An
expert or enthusiast of any kind. One might be an astronomy hacker,
for example. 7. One who enjoys the intellectual challenge of
creatively overcoming or circumventing limitations. 8. [deprecated] A
malicious meddler who tries to discover sensitive information by
poking around. Hence `password hacker', `network hacker'. The correct
term for this sense is cracker.

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".

Quote:

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

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.

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

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.

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.

Code:

sub globalColorChange

{

  my ($w,$bg,$fg) = @_;

# Change the top level widget

  $w->configure(-bg => $bg,-fg => $fg);

# Set the color of the children

  SetColorChild($w,$fg,$bg);

}



sub SetColorChild

{

  my ($widget,$fg,$bg) = @_;

  

# If the current widget has children

  if($widget->children)

  {

#  Loop over the children of the current widget

    foreach my $child ($widget->children)

    {

# Process the children of the current widget

      &SetColorChild($child,$fg,$bg);      

    }    

  }



#  Change the color of the current widget here

   ....

}

Quote:

Originally Posted by rbayer

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.

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.

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).

Quote:

Originally Posted by KenWittlief

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

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

Quote:

If the rules get in the way, get rid of them. I have seen one program with a single statement that spanned more than 20 pages. However, because of the specialized nature of the program, this statement was simple and easy to understand.

don't get sloppy, but don't be afraid to break the rules when it makes sense to do so.

~Aaron