From mboxrd@z Thu Jan 1 00:00:00 1970 From: "philw" To: <9fans@cse.psu.edu> Subject: RE: [9fans] code complexity Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0000_01C1AE40.1B10F280" In-Reply-To: <37088672ac32055400db1684d3dfae65@plan9.bell-labs.com> Date: Tue, 5 Feb 2002 12:24:47 -0800 Topicbox-Message-UUID: 4cdb0582-eaca-11e9-9e20-41e7f4b1d025 This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C1AE40.1B10F280 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit 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 ------=_NextPart_000_0000_01C1AE40.1B10F280 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [9fans] code complexity

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

------=_NextPart_000_0000_01C1AE40.1B10F280--