Russ's rant is academic. Many programmers write code
to make revenue. I care the code is simple because that
makes it maintainable. Program complexity has a lot to do
with style. It can be taught. I live with bad code often because
I have more work than I can possibly do in a given time and
I must buy lots of code that I integrate with my product. I am
rarely pleased with code from stack vendors. Good
programmers are expensive and my hiring follows a gausian:
some very good, some very bad most in the middle. I have few
chances to revisit anything since I could be writing code
which generates more revenue. That means I clean up what absolutley
must be maintainable then test and forget the rest.

Programming is an art - few people in industry have the luxury
of enjoying it on the macro scale because they work with a large
group that has unreasonable deadlines and business constraints
beyond the engineering.

Sometimes I pine for the good old days ....

phil

-----Original Message-----
From: Russ Cox [mailto:rsc@plan9.bell-labs.com]
Sent: Tuesday, February 05, 2002 8:35 AM
To: 9fans@cse.psu.edu
Subject: Re: [9fans] code complexity


I don't really feel like most of those line counts
are comparable, since it's not clear how much is 
there.  If you want something else that is not
really comparable, note that the TeX add-on package
for Plan 9 is almost the same size as the "everything else"
base package.

As for why, there certainly exists a small class of programmers
that actively believes writing complex programs is
just macho.  To them, I admit: I am not man enough to
keep up with your layers upon layers of complexity.
When I run into code they have written, I inevitably
complain to whoever will listen until I get fed up
enough to rewrite it.  To some extent, Mel is in this
class, although he understands programs as craft too.

At the same time, I think most programmers just don't
understand that programs are intended to be read by humans.
They fiddle until it works and then don't see the point
to doing it over again in a cleaner, simpler, more elegant
manner.  Especially if someone is being measured by some
bogus productivity metric like like lines of code written,
papers published, or problem sets handed in.

Good programming is like good writing in any subject;
it happens only by much revision and practice.  The sad
thing is that at least in my experience, introductory
programming courses just don't get that across.  (In fact,
in my experience most writing courses state that but then
do a poor job of backing it up.)  I helped to teach an
introductory computer science theory course for three years,
and we had the same problems there.  Students didn't
see any point to distilling a correct yet awkward proof
down to its essence; after all, it was correct, wasn't it?
(I don't know if this was natural or they got it from
taking intro to programming the year before.)
Even so, we didn't give much opportunity to help
them rewrite their proofs.  We did hand out the best
most elegant proofs we had on the solution sets,
and I think that helped somewhat, but I'm still not
sure how many internalized the message.

End of rant.
Russ