Subject: RE: [hackers-il] A Programmer's Sixth Sense

From: Chen Shapira <[email-masked]>
Date: Sat, 11 May 2002 12:22:08 +0300

> I'm definetely against "feeling" rather than knowing and reasoning
> assertions. But I suppose some experts can have first 
> impressions that can
> eventually be reasoned, and usually found to be correct.

The one consistency I found is that any piece of code *I* write, will look
like junk to me in a month.
Its natural, I learn a lot in a month...

The only exception is a report generation system, which I wrote half a year
ago. I've been maintaining this system for 6 month now, and I'm still
suprised that I wrote something that grows so well.
After 3 years of writing report generators, I've managed to strike that
delicate balace between generality and simplicity.

I found that I'm a very bad judge of other people's code. I can't tell
anything at all at a quick glance.
Time after time my first impressions are changed after a week of
maintainance. 
What looks like a mess at first glance, turns out to be an elegant solution
to a difficult problem. What looks elegant and impressive, turns out to be
unmaintainable spagetti of objects and templates.

IMO the most important things in a program are the functions and objects. 
A function should do one thing well, diffrent functions should work together
without depending on inner implementation details.
An object should define a clear area of responsibility, control it well, and
stay away from the responsibilities of other objects.
All those things are extremely important, and rarely are they revealed in
one glance (or ten).

---

From: Shlomi Fish <[email-masked]>
Date: Sat, 11 May 2002 18:30:06 +0300 (IDT)

> Its natural, I learn a lot in a month...

I have felt similarily when working on Freecell Solver. Of course, part of
the reason, is that I keep thinking of new features to add, and then see
that the code cannot accumudate them well. So, I refactor it a bit and
make it more modular, while adding new features in the process. (albeit
I heard that refacoring is defined as changing the internals without
changing the behaviour) And then, I'm relatively happy from it, until I
think of new features.

Of course one can argue that the "Hello World" program should be much more
modular. Check:

http://www.ariel.com.au/jokes/The_Evolution_of_a_Programmer.html

for a funny spoof of this fact.

> delicate balace between generality and simplicity.

Surprisingly enough, throughout all the time I maintained Freecell Solver,
I did not have the need to re-write it from scratch. The code now is very
different than version 0.2.0, and much larger in scope. But some code was
kept very much the same from the beginning. (with the standard changes of
changing myvar into instance->myvar, and other stuff like that).

Throwing out your entire codebase, just because you have to do a major
re-work is usually a bad idea, IMO. (and naturally, Joel Spolsky's) It's
workink, so you'd better start from it, than from a clean gvim buffer.

> unmaintainable spagetti of objects and templates.

Hmmppf. You are write that I rarely had the need to maintain other
people's code. I did it several times for commercial software, and several
time for open-source one, but usually I'm starting from something I
originally wrote on my own. The problem is that many times I like to see
if my software design theories will work, and I write a piece of code to
test it. And sometimes it grows into a monstrosity that can do so much
besides that.

> without depending on inner implementation details.

Right. And an important thing are the side-effects. I do not advocate
writing programs in pure functional style, but each function should do
what it is supposed to do, and have well-defined and rationalized
side-effects. Otherwise, everything can become very messy.

Of course, this is easier said than done.

> stay away from the responsibilities of other objects.

I sometimes like to have a bi-pole of two objects that each has a
reference to the other, rather than inheriting them. Multiple-inheritance
should not be abused.

> All those things are extremely important, and rarely are they revealed in

Perhaps you are right. There is a problem that it is a good idea to write
a software incrementally rather than one big, integrated code that does
too many things. And then in the next revisions, you realize things that
you did not take into account. But I guess that would be the case, until
someone writes good programs that will be able to generate code
automatically based on some algorithm templates.

In Star Trek TNG and friends, programming seems to be such a non-issue.
In one episode of "Deep Space Nine", O'Brian generates an entire sub-system in
one day, and one that is "more interesting" for an intelligent computer
program, than the normal computer system of the station. Either he is a
supreme programmer, or he could hack something very quickly using existing
tools. Maybe he just installed a Linux distribution on a virtual machine
there and made sure the computer program started to study it and hack
on it... ;-)

But the most important question still remains: who is John Galt?

Regards,

	Shlomi Fish

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

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

"Let's suppose you have a table with 2^n cups..."
"Wait a second - is n a natural number?"