Steve Kurtz wrote:
>
> Thomas once again has given us his insightful, sobering commentary on a
> unidimensional, rather ephemeral perception of the human predicament. It
> is not realistic to continue discussing the future of work without
> including the future of the caloric input required for brain activity -
> a requirement in a knowledge based or any other sort of economy. Water,
> shelter, fuel, & security must be included as well.
I think we need also to add the enormous entropy of the
obsolescence of knowledge. This is sometimes stated
more "positively" as a shortening "half-life" of
knowledge, so that by the time an engineer has
been out of college 10 years, 50% of what (s)he
learned is no longer current (or whatever the exact numbers
are in each case). (The especial affront of this is that
it is not a consequence of "natural processes" outside
human control, but of human symbolizing activity.)
I have seen this *with a vengeance* in computer
programming. I have found it discouraging to
have to keep learning new ways to be able to keep on
doing what I was previously able to do quite well with
programming knowledge that can no longer be used
because the new computers do not recognize it.
It reaches the level of absurdity that programs
written in the presently "sexiest" (<-- perverse locution)
programming language, Java, which hardly existed
in 1996, had to be signifcantly rewritten by
1998 because one of the most important and
pervasive parts of the language (the
"event model", i.e., the program's ability
to respond to something happening) was
incompatibly redesigned.
I worked on a big educational website (just a
lot of HTML an Javascript -- pretty "simple"
stuff, as computer programming goes!), where,
every time Netscape came out with a new
"maintenance release" of their web browser, it
was time for me to find out how it would
cause my application to break "this time", so
that I'd expect to spend from a few hours to
a few days getting back to where I had been
before. In general, data processing
departments live with the pervasive
"confidence" that upgrading anything will
break something that nobody could have guessed
it would, and which, to fix, may break even more
things (Joseph Weizenbaum's notion of
"incomprehensible programs", from his now
over 20 year old, but by no means outdated
book: _Computer Power and Human Reason: From
judgment to calculation_, W.H. Freeman, 1976).
The switch from "command line" oriented
computer programs to "graphical user interface" has
come at the price of at least one and maybe two
"orders of magnitude" jump in the amount of
disconnected detail knowledge (facts that
cannot be reduced to guessable
specifications of a few easily grasped "models")
a programmer has to master. The information
is nowhere available in a form that assures:
"These are the complete answers, and there are no
surprises hiding behind them." --> this
is a *big* problem with, e.g., programming for
Microsoft's Windows operating systems.
Oh yes, then there is the librarians'
nightmare of the rapid deterioration of
"electronic media", coupled with the
fact that even if the media can be
preserved, it becomes ever more
difficult to find media-readers (tape
drives, etc.) that can *retrieve* the
information.
So much *waste* and (to borrow Nietzsche's
phrase:) "the eternal recurrence of the same"
(which Buddhists call:) "the wheel of karma"....
So much contribution to the Gross(sic) National
Product....
If computer programs are among the free-est constructions
of the human mind (they aren't much constrained by
things like laws of physics...), they certainly
are rarely models of *lucidity* (there
are exceptions, of course -- Ken Iverson's APL
programming language, e.g.; IBM's original MVT/360
operating system was pretty good in this regard...).
It's like we got a chance to be G-d and blew it
(and, yes, surely "the force of the market" has
been a powerful factor, rarely rewarding programmers
for quality craftsmanship, but just expecting
it as a no cost given, no matter how much
deadline pressure the programmers are
subjected to...)....
And why not note the barbaric working
hours (both in duration and in deviation
from a 9 to 5 bell-shaped curve)
to which computer workers are
frequently subjected?
--
Once when I was in IBM, I overheard two business
planners talking as they walked down the hall in
front of me. They were not happy. One said to
the other: "Fishkill is not bringing in the
inventions on schedule."
\brad mccormick
--
Prove all things; hold fast that which is good. (1 Thes 5:21)
Brad McCormick, Ed.D. / [EMAIL PROTECTED]
914.238.0788 / 27 Poillon Rd, Chappaqua, NY 10514-3403 USA
-------------------------------------------------------
<![%THINK;[XML]]> Visit my website: http://www.cloud9.net/~bradmcc/
