Re: 6502 Programming Is Not Interested?

[mjmahon@aol.com (Michael J. Mahon)]

Chris Morse wrote:

>On Sun, 10 Aug 2003 04:32:42 GMT, "desiv" <desiv@attbi.com> wrote:
>
>>Now, there can be art in programming today.  There are some programmers who
>>are that good, and I'm sure you are one of those..  But any one who programs
>>or works with programmers knows that there are a LOT (as in huge percentage)
>>of bad point-and-click programmers out there.  People who learn 1 tool (VB
>>for instance) and drag and drop code.
>
>I have to admit this too Dave.  I do fully agree that the "art" of
>programming is not dead.  The way I see it, back in the days of the
>Apple II, a "real" program had to be developed by pretty much "real"
>programmers.  Almost all commercial software was written in assembly,
>which pretty much forced the programmer to have a decent idea of what
>he was doing.

(Actually, it is "desiv", not Dave, who is quoted above.)

In my original post, I did not say that the art of programming was dead,
I said that "the age of art and craft in programming is over".

By that I meant that the standards by which programmers are judged
and the goals that they are charged with by their employers have
shifted from "take your time and get it right" to "get it working by
the end of the week".  And this is economically (if not esthetically)
justified by the rising cost of labor and the falling cost of hardware.

A real craftsman today will usually be at odds with his programming
team.  He will generally not be satisfied with the first way he tries
to do something, but will want to measure the code's behavior and
alter its design to improve it--often in radical ways.  (One of my
favorite saying is: "The most underutilized design tool is the
wastebasket."  ;-)

The time pressure under which most commercial code is developed
militates against the less predictable "learning process" whereby
a problem is eventually solved with elegance, not brute force.

Of course real software craftsmen still exist--thank goodness--but
they are now considerably outside the mainstream of programming.
Many are working on embedded systems and in other resource-
constrained, high-value environments.

>>Of course, there were bad programmers "back-in-the-day", but there's a much
>>higher percentage now.  Why?  It's easier to be a bad programmer now.
>>Better tools, excess RAM and drive space.  It's very easy in todays world to
>>write bad sloppy bloated code and get away with it...
>
>Yes, it was harder to be a "bad" programmer before, if you were doing
>it for a living and writing commercial software.  Commercial
>applications were almost NEVER written in BASIC. 
>
>I think, also, back in those days 20 years ago there were A LOT fewer
>professional programmers than there are today.  Those few that did
>program professionally 20 years ago most likely were keen and in tune
>with their machines.  
>
>Today, I am surprised when I discover how many placed employ
>programmers who couldn't program out of a wet paper bag.  Visual Basic
>is all they know and even then it's sloppy and inefficient.
>
>But there are a lot of programmers out there that are the complete
>opposite, too.  It's more of a mix than it was before; today it's
>easier to be sloppy and get away with it.

I have been in system programming for many years, and I don't see
"a lot" of code craftsmen.  I see a few--perhaps five out of a hundred--
and that's among _system_ programmers!  If we extend the sample
to _all_ programmers, I would be surprised if it's more than five in a
thousand.

The point is that programming has become an industry, driven by
market pressures and the need for lots of "bodies".  This inevitably
causes a shift in the distribution of skills.  Today, the few people
who actually understand the meaning of code optimization on a
multi-level cached, multi-execution-unit, pipelined machine are
not writing application code.  They are (hopefully) writing the
optimizers that will enable mainstream coders to get reasonably
good code out of their compilers.  Sadly, much of the code fed
_into_ those compilers is so naive as to make mere code
optimization relatively worthless in the face of algorithmic
inefficiency.

Admittedly, it was a simpler world many years ago, when just
a table of cycle counts would allow a programmer to know how
his or her code executed.  Most optimization was done at one's
desk with pencil and paper.  But some of the results were
stunning in their elegance and efficiency.

In the 60's, I could generally pick up any listing and, by reading,
find clever things to appreciate in it, and perhaps add to my own
bag of tricks.  Today, looking at random samples of code seldom
produces admiration or learning--except perhaps by "bad example".

Of course, there is still literate code around--there must be!  But
it has become harder to find.  I hoped that the Open Source
movement would bring more "great code" into the light, and
perhaps it has, but the programmer's objectives have changed.

The art of "doing more with less" has largely given way to
the art of "doing more with lots more".  This is, I suppose,
a natural consequence of Moore's Law--making human effort
the constrained resource, and hardware resource relatively
unconstrained.

In the 70's we dreamed of constructing modular operating
systems, with layered abstractions.  But while these were
excellent design ideas, any _actually_ layered implementation
gave up a big factor in efficiency for its structure.  Most systems
were forced to adopt a quasi-monolithic implementation of the
abstract, layered design, to obtain clean abstractions combined
with run-time efficiency.

Now, virtually all system implementations are based upon much
deeper layered abstractions, and the consequent context-switching
and calling overhead is simply taken for granted.  If the past is any
guide, and if the code internal to each layer were efficient, this
layering is costing almost a factor of ten in pathlength compared
to a more monolithic implementation.

But it is unlikely that the code in each layer is really efficient, and
it would be a maintenance impossibility to have a "merged"
implementation of a modern system.  We have concluded that
the cost of modularity, however high, is a "sunk cost", and now
cannot build systems without paying it.

Ack!  All of this sounds like fogey-mode!  ;-)

I enjoy the functionality (however fragile ;-) of modern systems,
but still, from time to time, I wonder what these supercomputers
we call PCs could do if programmed "on the metal".  Of course,
the answer is "not much", since no "one" could produce enough
code to make a difference (Linux supporters may object.  ;-)
But it would be fun to send one back in time to see what
wonders might ensue...

-michael

Check out amazing quality 8-bit Apple sound on my
Home page:  http://members.aol.com/MJMahon/