RE: [hackers-il] "Trial and Error" vs. "By the Book" programming
- I like to think everything over, run simulations in my mind, perhaps trace
an algorithm a few times on a piece of paper, and then dump it all in
It's a matter of preference.
From: Shlomi Fish [mailto:shlomif@...]
Sent: Sun, December 09, 2001 1:58 PM
Subject: [hackers-il] "Trial and Error" vs. "By the Book" programming
Nadav made an interesting point in which he contrasted those two
viewpoints. However, my viewpoint is something in between.
The way I see it when I have to come up with a technique or a methodology
2. After I came up with an idea, I try to "prove" that it will achieve
what I intended it to. This is a rather informal proof in which I cover
all the places where it may fail.
3. I implement it.
4. I run it and see if it performs OK.
5. If it fails from some reason, I debug it, see where it fails. If it's a
trivial bug, I fix it.
6. If the bug is inherent, I think of an elegant workaround.
So far this scheme worked wonderfully for me. I'll give you an example
(this time not with Freecell Solver - :-)).
During my "Structure of OS" course, my partner and I were given an
assignment. We had to scan a directory structure for files, while
allocating one thread for every directory, sub-directory,
sub-sub-directory, etc. Then we had to keep a catalog of the files and
use it to perform a substring search on the file names. (a very stupid
strategy inherently, but that was what we were supposed to do.)
Now, the user-interface thread could have received a command that would
have told it to terminate the program. We wanted all the
who-knows-how-many threads we initiated to exit prematurely (naturally),
but we wanted the main thread to know when all of them did. What we did
1. Signal all the threads to exit by setting a "global" (i.e: thread pool
2. The threads checked this flag in their main directory scanning loop.
3. When a new thread was created it incremented a mutex-protected counter
by 1, and when it terminated (either pre-maturely or maturely) it
4. The main thread looped on until this counter was set to zero (it too
locked and unlocked the mutex in order to retrieve the value).
Now, we did not learn this particular technique in the course, but it
worked very well. Of course, if one if the threads is killed pre-maturely
(somehow) there could be a deadlock, but I think most synchronization
algorithms are not immune to such errors.
I'll bet this technique or something similar is well-documented in the
literature, but I came up by it myself. Actually, I did thought about it
for something I wanted to implement for Freecell Solver, but have yet to
do. But I made a working implementation of it for my class assignment.
I love to think. And usually, I am feeling quite exhilirated when I come
up with an interesting algorithm or mathemtical proof or technique or
whatever. And if I eventually find out that somebody thought about it
before me, it does not reduce my sense of achievement. I respect the "book
worm" approach, and while I have read some technical books in my time, I
acknowledge that it's not for me.
Shlomi Fish shlomif@...
Home Page: http://t2.technion.ac.il/~shlomif/
Home E-mail: shlomif@...
1. A is A
2. A is not not-A
does it imply that
1. B is B
2. B is not not-B
To unsubscribe from this group, send an email to:
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/