Subject: "Trial and Error" vs. "By the Book" programming

From: Shlomi Fish <[email-masked]>
Date: Sun, 9 Dec 2001 13:57:51 +0200 (IST)

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
I:

1. Think.

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
was:

1. Signal all the threads to exit by setting a "global" (i.e: thread pool
scoped) variable.

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

Regards,

	Shlomi Fish

----------------------------------------------------------------------
Shlomi Fish        [email-masked]
Home Page:         http://t2.technion.ac.il/~shlomif/
Home E-mail:       [email-masked]

If:
1. A is A
2. A is not not-A
does it imply that
1. B is B
2. B is not not-B

---

From: Arik Baratz <[email-masked]>
Date: Sun, 9 Dec 2001 16:46:39 +0200

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
code-form overnight.

It's a matter of preference.

-- Arik

-----Original Message-----
From: Shlomi Fish [mailto:[email-masked]]
Sent: Sun, December 09, 2001 1:58 PM
To: Hackers-IL
Subject: [hackers-il] "Trial and Error" vs. "By the Book" programming

1. Think.

3. I implement it.

Regards,

	Shlomi Fish

If:
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:
[email-masked]

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/