Jump to content
  • Advertisement
Sign in to follow this  

theory vs reality

This topic is 4746 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Do any of you find that, after you write a large program which you have thought out carefully, it works differently than expected?

Share this post


Link to post
Share on other sites
Advertisement
Sometimes. I sometimes forget to unit-test small libraries, like one I wrote recently which wraps OCaml byte-stream channels to give bit-stream capabilities.

When I got around to testing, I'd writtne both the input and output wrappers, but there was a mistake in my input_bit_channel wrapper; it was reading the bits of each byte backwards (from lowest-significance to highest), although the output wrapper was working correctly. I found the bug after another 5 minutes of code inspection and a bit of theory-work on paper, though.

Share this post


Link to post
Share on other sites
Now you tell me (lol)

I made tic-tac-toe, and it puts the marker on a different square then where you clicked. Now I get to spend hours tracing the code flow (yay).

Share this post


Link to post
Share on other sites
If you're also considering AI related works, unexpected behaviour can be a good thing. [smile]

Share this post


Link to post
Share on other sites
You should test each step of the way. Write just one more thing in code; make it build and run; put a breakpoint at the new code; step through it to make sure it works right. Then go back; write the next thing; ...

For the tic-tac-toe problem, I would suggest adding some logging where you print the mouse coordinate you get in and the values you use in your calculation, and then examine them for behavior. That should be significantly faster than "hours" with a little luck.

Share this post


Link to post
Share on other sites
If the design doc is detailed enough so that no unexpected flaws are found, then the design doc is metacode for the program. In that case, you might as well have just written the darned thing to begin with. LISP is good for such ideas.

I'm evolving my own library in C++ without ANY up front design and I'm really enjoying the productivity. Yeah things get messy, so I stop and clean up often. The result: my helper code is truly helpful, its not based on a "well the user might want this, and in that particular case we might need this entire other widget manager class" talk. Its all proven and heavily used. The effect is that I spend less time thinking about my code structure or design, and more time plunging into the heavy logic. When I stop and clean up, consolidating stuff into classes, the design is based on real helper functions that I collected over the past few hours.

I think that extreme programming has alot going for it, ive also designed the hell out of programs in the past and usually threw away more design than used, because by the time i got around to implementing stuff, i already had a better idea. Aweful, just aweful!

Share this post


Link to post
Share on other sites
Quote:
Original post by Diton9000
Do any of you find that, after you write a large program which you have thought out carefully, it works differently than expected?


I find I only get this problem when I think the problem through carefully, and then ignore that when actually implimenting it [usually due to interruption, or lengthy delay between pondering and typing]

Share this post


Link to post
Share on other sites
Quote:
Original post by Diton9000
Do any of you find that, after you write a large program which you have thought out carefully, it works differently than expected?


If you are making a program to do something you've never done before, (non-blocking server) then it might no work with your design. Many times I've found myself saying "Now all I have to do it this...", only to find out I can't do that, which changes the design, which makes you try to do yet another thing that you can't do, which changes the design... [oh]

These are just my thoughts.

  1. Designing a system up front should be abstract enough that is doesn't cover the how, only the what and the why. If you have no design, then you could be wasting your time. On small projects, most people do this, but they do it in their head before coding. Deciding to include an undo feature in a sprite painting program, or deciding on a way to handle version 1.0 files when there is a version 2.0 released. These things cannot be added at the end without a lot of trouble. Sometimes simply writting down what the system will do ensures that it does it.

  2. If you've never done it before, write a small test program to see how it works.

  3. Sometimes the best thing to do is just start coding, and throw it away.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!