Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ihnp4!ptsfa!ames!elroy!cit-vax!oberon!bloom-beacon!husc6!bbn!rochester!udel!gatech!ukma!uunet!nuchat!uhnix1!sugar!peter
From: peter@sugar.UUCP
Newsgroups: comp.lang.misc
Subject: Re: software ICs vs. libraries
Message-ID: <951@sugar.UUCP>
Date: Fri, 30-Oct-87 21:08:25 EST
Article-I.D.: sugar.951
Posted: Fri Oct 30 21:08:25 1987
Date-Received: Wed, 4-Nov-87 19:52:02 EST
References: <3405@ece-csc.UUCP> <638@its63b.ed.ac.uk> <1811@watcgl.waterloo.edu> <1270@csib.csi.UUCP>
Organization: Sugar Land UNIX - Houston, TX
Lines: 115

In article <1270@csib.csi.UUCP>, jwhitnel@csi.UUCP (Jerry Whitnell) writes:
> Having programmed the Macintosh, I'll have to disagree with the last two
> comments.  The toolbox is complicated, but not hopelessly so, since there are
> a large number of programmers using it to develop software.

I'll have to disagree with that. The MAC toolbox violates a fundamental law
of O/S design: FIRST, make the easy things easy. You should be able to
operate like this (enter fantasy mode):

	Window = OpenWindow(x0, y0, x1, y1, xmax, ymax, 0);

This gives you a minimal window. It gives you a window of size (x1-x0) by
(y1-y0) into a virtual screen of size xmax by ymax. Scroll bars are provided,
so the user can pan around the area. A sizing button is provided, so you
can rezise the window. You can then twiddle your thumbs for all the
user cares. The window is up there. Other programs windows may cover it up
and make it visible again. You don't care... it's all handled transparently
by the operating system. You can draw into the window, write text, and the
operating system will handle clipping and rendering into offscreen portions
of the bitmap. This is the default.

	Window = OpenWindow(x0, y0, x1, y1, 0, 0, FIXEDSIZE);

This gives you a window of fixed size, like a Mac dialogue box.

	AddButton(Window, x0, y0, x1, y1, function, 0);

This adds a poke point to the window, size and co-ordinates (relative to window)
as above. Imagery is handled by drawing it in beforehand. When the button is
poked, the named function is called asynchronously (as in a UNIX signal).

You get the idea. None of this business of calling SystemTask as often as
possible. None of this business of having to redraw the screen yourself. The
operating system has to figure out WHEN to redraw the screen... why not let it
do the work as well?

Any idiot can put together an oscillator circuit with a 555. Any idiot should
be able to put together a well-behaved windowing application.

I don't know of any system that's this sophisticated, though the Amiga
SuperBitmap windows are fairly close. Maybe XWindows or NewS.

> As far as
> programmer improvement is concerned, 99.9% of the programs on the Mac use
> some portion of the interface, and 99.8% of them use the Toolbox rather
> then write it themselves (there's always one who wants to write it himself
> anyway :-)).  Compared to the cost of doing it all themselves, there is
> certainly a large improvement in programmer productivity.  One might argue
> that the Mac interface itself is detirmental to programmer productitivty,
> but since it greatly enhances user productivity, we programmers will have to
> bite the bullet and use it.

I'm not gonna. There's no good reason to make any system more complex than UNIX
for the programmer in this day and age.

> My defintion of a "software-IC" is a follows:
> 
> 1) Simplicity of function:  An IC should have one and only one function.  This
> function could be just to sort data or as complicated as converting 3d-objects
> to 2d-display.  This relates directly to the hardware IC which implements a
> single function (whether it is an AND or a Multiplexer).

Yes.

> 2) Layered.  Not only should the calling function interface be defined, but
> also the called functions interfaces should be defined.  The programmer can
> mix and match pieces to achieve the desired set of features.  A example of
> where this concept is not used but should be is the UNIX malloc function.  
> Malloc is implemented using several queues and OS calls.  There is no reason
> while the programmer couldn't replace these with other equivalent functions
> if needed, except that unless he has access to the source code, he has no
> idea what the called functions do.

Maybe. The programmer can certainly replace malloc, though. Besides, the
complete source to malloc is listed in the C bible (K&R).

> 3) Well documented.  If you looks at a 7400 book, you can see the wealth of
> information provided about ICs.  Everything from pin-outs to time charts to
> tempature specs.  You look at any software libary spec and you'll usually
> get half a page of incomplete information, usually wrong :-).  Complete
> documentation in a standard format is a necessity.

Software is easier than hardware. You need more info than IBM gives you, but
I don't see how (for example) malloc needs more info than is provided in the
UNIX Programmer's Manual.

> 4) Machine/OS/Language independent.  For a hardware engineer, all of the
> iterfaces are standard (TTL), as are the ICs (7400).  This means that
> an engineer can mix and match with no worry about the enviroment the final
> product will end up in.  Different choices can be made for reasons of costs,
> speed, power consumption all without changing the base design.  For software
> ICs the same should be true.  If you need a sort, you should be able to go
> to your "42-series" catalog, look up sort routines and pick the one that
> meets your needs for speed/memory consumption/... independent of whether
> your working on a Mac, a PC, a UNIX box or an IBM mainframe (well, maybe not
> there :-)).  

Nope. If you're working with CMOS, you don't expect to be able to go to your
TTL catalog. Same for ECL. These correspond to different languages, if you like.
Some are positive logic, some are negativce logic. Some can handle a lot of
fan-in, some a lot of fan-out. Some are fast, some are slow.

> I disagree, semi-custom and custom are really a step backwards on the hardware
> side, as far as engineers are concerned.  Whereas before one could depend on
> each IC being a black box (chip?) whose implementation you didn't care about
> (mostly), now the implementations will be right in front of you with nothing
> to prevent from aliasing this function to that global over there...  Just
> as bad as software is now!

But, like the Mac Toolbox, it does make things easier on the user (more power
and functionality). (notice how I came 180 degrees on that one, folks?). But
you don't expect your home hobbyist to work with a silicon foundry...
-- 
-- Peter da Silva  `-_-'  ...!hoptoad!academ!uhnix1!sugar!peter
-- Disclaimer: These U aren't mere opinions... these are *values*.