Newsgroups: comp.lang.smalltalk
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!news.mathworks.com!uhog.mit.edu!news.kei.com!eff!usenet.ins.cwru.edu!howland.reston.ans.net!math.ohio-state.edu!jussieu.fr!jabba.fdn.org!uunet!psinntp!psinntp!pls.com!usenet
From: Tom Donaldson <tomd@pls.com>
Subject: Re: Smalltalk in CS 1
Message-ID: <1994Oct26.171305.13385@pls.com>
Sender: usenet@pls.com
Nntp-Posting-Host: mactom
Organization: Personal Library Software
References: <9410211433.AA13245@sci.brooklyn.cuny.edu> <mackinto.35.0018FE55@biologysx.lan.nrc.ca> <tms-251094103822@stambaugh.tiac.net>
Date: Wed, 26 Oct 1994 17:13:05 GMT
Lines: 69

> In article <mackinto.35.0018FE55@biologysx.lan.nrc.ca>,
> mackinto@biologysx.lan.nrc.ca (David Mackintosh) wrote:
> 
> > Do high-level language programmers really need to know that the CS:IP is 
>   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > connected to the... ?  A printf() is a printf().  Hardware people, on the 
> > other hand, need to know all about interrupts, registers, bus protocols etc 
> > because they will actually use them. 

> Finally, and only half-jokingly, how do you, for example, install a CD-ROM
> player in Windows without knowing about all those ugly details? Surely this
> is a "high level" task? I just walked into ComputerCity and bought the damn
> thing. I spent days tracking down EISA configurations, DMA interrupt
> levels, hi-mem and lo-mem (or some such stuff), and so on.

I think this illustrates an important point.  To install a CD-ROM drive on
a Macintosh, you take the drive out of the box, maybe set a SCSI 
address, and drag a driver from the installation disk to the system
folder.  It has never taken me more than 15 minutes to install one,
including reviewing the packing list, opening the box, and disposing
of packing materials.  You spent days installing one on a MSDOS machine.

The difference?  The Mac engineers spent the time to develop a 
reasonable abstraction, and implemented in a way that hides 99.9% of
the cruft from the user, sysadmin, etc.  Even MicroSoft is talking
about plug'n'play; maybe someday it will even be possible on MS/Intel
platforms.

So, how do you deal with developing software without knowing the 
ugly details of the processors registers, interrupts, etc.?  Work
with tools that provide clean high level abstractions whose
implementations "do the right thing."  Of course the software
developers who implement the tool need to get close to the hardware.

Thus, "system" level programmers need to be more aware of the grit;
or do they?  Operating systems themselves are providing increasingly
higher levels of abstraction, pushing grit-knowledge requirements
down to ever smaller numbers of system software developers.

Also, with RISC processor architectures, you really NEED to rely 
on the language system to "do the right thing."  If you TRY to 
deal with the processor at too low a level, you end up destroying
performance because you cannot optimize the instruction stream
nearly as well as a compiler could.

> So, although I may just be a crotchety old fossil, 

As one crotchety old balding/greying fossil to another, I'd rather 
see co-op students, and fresh-outs, who can deal with the high level 
abstractions, do good analysis and design, work well in a team 
environment, etc., than I would someone who is great at bit-twiddling
but cannot see the forest because those danged trees keep getting in
the way.  They can deal with the performance problems of a particular
environment once there is a working product that CAN be optimized.

Thus, I'd like to see first semester freshmen getting Smalltalk,
rather than IBM-370 assembler as I did.  Given that one role of
undergraduate training is to provide students with an overview and
survey of possible career paths and skill sets, sooner or later
the student should deal with low-level development skills and
architectural issues -- just for the "awareness" and the option
to select "systems" level work.  However, I am more and more of
the opinion that low-level skills are of little value in computing
except in certain specialty areas.  I would not cry if students
got their batchelors without ever having written a multi-tasking
excecutive in assembler (although it sure was fun).

Regards,
Tom
