Re: Apple Computers-collector's items?

[Rod Stites <RodStites@i-link.net>]

Dave Althoff wrote:
> 
> Hokay, time for me to jump in here briefly...

(snip, snip)
> I'm still an Applesoft programmer at heart.  If I
> want to get something done quickly, that's what I use.  But the main point
> is that I learned how computers do things.  It's not the internal
> I/O<->CPU<->Memory details; I couldn't care less about that.  

(big snip)

Just to pass along the thoughts of an old-timer even older-timer than
you.  You are talking about the transferability of knowledge in
application programming and you minimize the need to comprehend i/o
calls, interrupts, etc.

Applications have always been too specific for my pleasure.  Anyone can
understand and write an application in many different languages.  The
real action is in operating systems, and they generally are not
portable, and are vastly different from one another.

To illustrate the point.  I worked for many years with an IBM operating
system called TPF (transaction processing facility) used primarily by
banks and airlines.  Most of the applications programmers who wrote code
for fare quotes, etc, thought knowing the operating system was banal.

But as you sit there now, not touching your keyboard and looking at the
monitor, do you have any idea how many lines of code are being exercised
quietly in the background, ready for any event?

The op/sys sits there, doing its job, waiting for interrupts
from any number of sources.  Say you hit enter twice.  The operating
system has to recognize the interrupt, determine what type it was,
branch to the appropriate code in the op/sys after it has dispensed
memory and buffered the entry, queued it, and prioritized it.  As it is
doing so, it has to go through its housekeeping routines and find which
queued entries have expired and release all devices, memory buffers,
police itself, police the system for generic application errors that
compromise the integrity of the op/sys.  If a queue is full, it has to
stop you from feeding it additional data and will not allow you (or any 
device) to feed additional i/o until it is ready.

Anyway, the point is that knowing i/o starts, stops, and what goes down
the pipe to wake up your idle devices is vital.  Operating systems are
the nucleus of any machine, and understanding hardware i/o is critical
to a broader understanding of computing in general.

Anyone can write an application.  The really GOOD application writers 
also know their operating system, policing routines, interupts, 
buffering routines, housekeeping routines, error handling routines, 
boots, start-up, queuing, and just why it is that your code can freeze 
the machine dead in the water.  The op/sys enables you. Your application 
doesn't enable the op/sys or the computer.  Your application simply 
takes advantage of an elegantly written operating system.  Otherwise you 
might as well be programming a rock.

Anyway, stare at your monitor for a second and try to think of all that
is going on while you are idle.  Your machine certainly isn't, it is
busy as hell!

FWIW...

(and apologies for the off-the-topic remarks)