As for your claim that my examples aren't readable,
...I won't be blamed for your lack of effort.
Ahh. I had a feeling that you were an academic. In a world in which
money doesn't matter, I can see your point.
However, in my world money matters. Effort = time = money. Code that is
hard to read costs my business much more money than code that runs a
little slower but is easy to understand. (Note that I said "a little
slower" in order to discourage the inevitable straw-man attacks.) Every
minute I spend trying to decipher spaghetti code like yours is a minute
that my employer has paid me for doing something unproductive. Very
inefficient code, of course, costs my business more money, because it
has to blow more money on hardware. So, we don't write tight,
unreadable code, and we don't write grossly inefficient code. We shoot
for a balance between the two: whatever costs the least in the long
term.
In an academic environment, money is largely irrelevant, which means
that time is largely irrelevant, so producing readable code is also
largely irrelevant. In the business world there is tension between
time-to-market, maintenance cost, the cost for talent performance,
bugginess, software lifetime, and hardware cost. The word there is
"tension": all businesses play these things off against each other and
look for a workable balance: the least expensive balance. This means
that often code does not perform as well as it could, because
performance has been traded off for some other benefit.
In the academic world, time-to-market makes no difference, there is no
maintenance, and software lifetime is irrelevant unless it's an area of
study. That leaves only performance and (the related) hardware cost as
hard considerations, and performance and bugginess as points of pride.
Naturally, academics produce (and value) different code from that which
business users produce (and value).
That's why I liked the Big Ball of Mud academic paper that I posted
earlier. It was the first attempt I'd ever seen on the part of
academics to examine business practices on their own merits, rather
than throught the academic lens. What a pity that they later dumbed it
down for their academic audience.
The great failing I saw during my time in academia was the arrogance
that permeates university computing departments (I can't vouch for
other departments): the assumption that business programmers who make
compromises and ultimately produce large messy systems do so because
they're morons who don't know how to code.
The reality is quite different.
It's easy to produce beautiful little jewels of programs (within the
confines of your personal aesthetics, of course) if you drastically
limit the problem domain. Jeff posted a compact (unreadable) C++
program for doing something-or-other with HTML. (No, I didn't read it
through. My employer doesn't pay me to pore over code samples from
newsgroups unless I'm helping someone solve a problem.) The interesting
point, though is that he solved a well-defined problem within a tiny
problem domain. That's the kind of stuff we pay academics to produce.
Good on him.
Business programmers, however, are faced with large, poorly defined
problem domains. On top of being poorly defined (and no, there's no way
to clearly define them), they're constantly changing. Today's great
design is tomorrow's dead end, and there's no way around that, either.
Yes, we could sit in a corner and design some beautiful little jewel of
a program that solves one particular little problem within the
business, but then the business would effectively be paying $100,000
for a program that would give them $10,000 of benefit, and while we're
producing that one beautiful little program, we let hundreds of
thousands of dollars of benefit go by the wayside in the form of other
things we could have been producing. So, the business loses twice: it
pays big bucks to solve a problem that didn't need such an expensive
solution, and tied up its programming staff on one problem while there
were lots of other, more important (in monetary terms) things to do
Anyone who did that in my company would be sidelined and then
downsized, simply because the company would be realizing anything close
to a return on their investment.
There are different pressures in business and different needs. That's
why we need Visual Studio IDEs, piggish, inefficient application
servers, layers upon layers of class hierarchy as support, _and_
academics like Jeff and the folks in Redmond coming up with canned
solutions for us: because we're doing things far, far more complex than
academics are doing, and it's all we can do--even with all of these
tools and all of this support--to keep on top of constantly changing
business needs. Why do you think that Microsoft became the software
giant that it is? Yes, a big part of it was marketing, but not all of
it. MS understands business programming needs much better than, say,
Apple ever did. MS software isn't pretty, but it addresses needs that
academics don't recognize. In business, the best software is that which
saves the most money, either in the short term or the long term
(ideally both). Academics don't "get" this because they're using a
different yardstick to measure success. Gates, for all of his flaws (we
all love to hate him, don't we?
uses the correct yardstick to appeal
to a business audience and deliver stuff that business needs.
Comparisons are odious, but IMHO Jeff has, with the code he posted,
house-trained a puppy. Congratulations. I'm fighting a hydra, and every
time I slice off a head, two grow back. He can, if he wishes, claim
that I'm having such difficulty because I'm a dolt, and all I have to
do in order to succeed is adopt his solution and scale it up, but
you'll pardon me if I don't buy that for a minute.
