nelson_p@apollo.HP.COM (Peter Nelson) (02/26/90)
( Long rant follows.... )
Copyright (c) 1990 by Peter Nelson
Peter Nelson (that's me) posts (RE a Desqview problem)...
> I've tried various suggestions in the manual to no avail. Of course
> there's a lot of material there, between the 2.2 manual, the 386
> addendum, and the QEMM material. I haven't got time to become an
> "expert" in their product; I just want to be able to run my
> programs.
>
> Desqview's troubleshooting guide was no help. They have a section
> for developers which talks about writing "Desqview oblivious"
> programs. There they provide a list of "don'ts" which basically
> amount to "don't write your program as though it owns the machine"
> and which consists of specifics about buffer and stack sizes and
> interrupt handling and not 'going around' DOS, etc.
If you write your programs in a high-level language you are not
likely to KNOW what the run-time code does, how it allocates
buffers, uses interrupts, accesses devices, etc.
Earlier, in reference to a Zortech problem, I was flamed for not
knowing that "ctrl-c" is only interrogated during DOS calls and
that flash graphics makes no DOS calls. ( contrary to many flames,
this info was NOT in the manual )
Both of which raise the question of what constitutes a "reasonable"
level of knowledge?
My mother-in-law has a PC. She has no idea what RAM or a CPU is.
She doesn't know a single DOS command but some kind soul changed
her autoexec.bat so it invokes an application menu and she can run
her programs in blissful technical ignorance. She's never had a problem.
She also drives a car. She knows nothing about engines or mechanics
but this has never been a problem in the 43 years she's been
driving.
I sometimes tinker with my car. Just little things like replacing
or gapping the plugs or changing the oil and filters or adjusting
the timing. I have a general understanding of how cars work and
the "architecture" of engines. I am confident I could learn enough
to do major engine overhauls *if I wanted to*, but I don't.
I make my living as a computer programmer. For the first 10 years of
my career I programmed in nothing but assembler and my early background
is mainly in hardware. About ten years ago I even programmed 8086's
(not for PC's) in assembler. So I'm confident that *if I wanted to*
I could become a complete expert in everything having to do with
DOS programming, and I could disassemble the run-time code that
my compiler generates and figure out why it won't work under Desqview.
I could also become an "expert" in say, QEMM and memorize every line
in the manual.
But I don't want to. It's not fun. And it's not why I own a PC.
All I want to do is write application programs in a high-level
language and run them on my computer. But it doesn't work that
way: if you're just an applications USER like my mon-in-law you're
"allowed" to draw a line below which you don't have to venture.
But once you decide to PROGRAM your computer you are expected
to know everything there is to know about the product down to the
lowest interrupt handler. And if you have a problem, you can't
take it to the software equivalent of an garage mechanic and
pay him to straighten it out. Of course you could hire a contract
programmer who knows DOS real well but this would be the equivalent
of hiring an automotive engineer to replace your water pump.
One reason for this was summed up by Edsger Dijkstra in his, by-now,
famous essay "On the Cruelty of Really Teaching Computer Science" in
the December 1989 issue of "Communications of the ACM"...
The town is made up from neighborhoods that are structured by
streets, that contain buildings, that are made from walls and
floors, that are built from bricks, etc., eventually down to the
elementary particles. And we have our specialists all along the
line, from the town planner via the architect, to the solid state
physicist, and further. [...]
The programmer is in the unique position that his is the only
discipline and profession in which such a gigantic ratio which
totally baffles our imagination has to be bridged by a single
technology. He has to be able to think in terms of conceptual
hierarchies that are much deeper than a single mind ever needed
to face before. Compared to that number of semantic levels
the average mathematical theory is almost flat.
If I want to write a cellular automaton program it is no good
for me to just think in terms of "cells" and "states" and
"colors". It is not even sufficient to conceive of my program
in terms of the arrays or numeric values of Pascal or C. Instead,
there seems to be a wide assumption that once I cross the line
to "programmer" I should be willing to go all the way down to
the hardware in conceptualizing my task. I'm expected to know what
interrupts are being used, how segment registers are allocated
on 80x86 machines, whether the compiler's run-time code goes
through DOS or the BIOS or accesses hardware directly, and so forth.
I may use a high-level language for my convenience, but I'd better
not assume that it will somehow insulate me from knowing what
goes on below.
Of course I may be able to get away without such knowledge, and I
often have. But if I run into trouble, woe is me. There are just
too many instance where NOT knowing these things is very risky: too
many unpredictable hangs, too many bloody clashes between different
programs and too many things that mysteriously go "bump" in the code.
If Dijkstra is right then we are not just seeing the growing pains
of a PC industry with too few standards. Instead, we are facing a
fundamental problem of the art and science of programming.
---Peter