Path: utzoo!attcan!uunet!samsung!crackers!jjmhome!banyan!gil
From: gil@banyan.UUCP (Gil Pilz@Eng@Banyan)
Newsgroups: comp.arch
Subject: Re: The CPU with 3 brains---486 compatibility with 8008
Message-ID: <1113@banyan.UUCP>
Date: 14 Nov 90 17:13:11 GMT
References: <42737@mips.mips.COM> <1990Nov4.014901.23819@zoo.toronto.edu> <1990Nov6.223738.13265@ux1.cso.uiuc.edu> <9333@b11.ingr.com> <PCG.90Nov10145452@odin.cs.aber.ac.uk> <1106@banyan.UUCP> <6706@uceng.UC.EDU>
Reply-To: gil@banyan.com
Organization: Empire of the Senseless
Lines: 66

In article <6706@uceng.UC.EDU> dmocsny@minerva.che.uc.edu (Daniel Mocsny) writes:
>If the people who make up that market had "simple and elegant" problems
>to solve, no doubt they would be pleased with software that was
>similarly "simple and elegant". The market consists of people who are
>in business to make a profit. They base their purchasing decisions
>on what their experience shows to yield the largest profit.
>If they are making the wrong decision, then someone should be able
>to go into business in competition with them, and prevail. 

Well no one operates in a vacumn. If I wanted to try and beat the
competition in "industry X" through the use of cheaper, smaller
systems that needed less maintenance, were easier to use and
understand (perhaps after some non-minimal startup education), and
continued to maintain their usefullness even when the nature of
"industry X" changed I would first need to _find_ such systems. I
would need to find employees who were willing to, in some limited
sense, "become their own programmers".

>Simplicity and elegance occur primarily in textbooks. The real world
>has enormously complex problems to solve, under severe time constraints.
>The market can't afford to ignore reality just to satisfy the aesthetic
>sense of a cloistered, lazy programmer ("lazy" is not a pejorative term;
>nobody wants to work harder than necessary, else we wouldn't demand
>salaries). To sell into a real market, one must roll up one's sleeves 
>and do a lot of real, detailed, and tedious work.

It's not just "aesthetic sense" it's "good sense". It's been shown
over and over again that the best overall approach to tackling a wide
range of complex problems is to provide a minimal set of powerfull,
simple primitives and an easy way to link these primitives together
into useable wholes. This is the real lesson of UNIX that seems to
have gotten lost in all the "yes, but does it support the FOO-remote-
file-munger ?"  Users who _understand_ the paradigms of the system
they are working with (NOT the low-level stuff mind you) and can play
with these paradigms will probably come up with much better solutions
to their _particular_ problems than Joe-the-isolated-programmer will
_ever_ be able to build into some monolithic, pop-down-windows, here's
the 3000 page user manual, application. But they won't be able to do
this as long as the systems we keep presenting them with have their
underlying paradigms obscured with 7 million conflicting "features".

>Experience has shown repeatedly that "simple" and "elegant" quickly
>become synonymous with "incapable". Look at the C language. It was
>designed initially to be small, but it is uncompetitive for most real
>problem-solving until you add hundreds of functions in libraries. C
>can't stay "small" in practice and survive, else it would have. C
>survives because it provides a set of base concepts to begin with,
>an effective mechanism for expansion, and the ability for the customer 
>to select the expansion (s)he wants. In practice, the farther 
>this expansion goes, the more potentially valuable the system becomes.

I think this arguement supports my position. I'm not necessarily
talking about "small" in the memory usage sense, but rather "small" in
the cognitive space sense.  The idea is not to try and force users to
work at a lower level for the sake of simplicity. The idea is to
provide them with a simplicity they can work with so they can spend
their time thinking about their real problems and not why "feature X"
works so much differently than "feature Y".

>The limiting factor is the programmer's ability to manage complexity.

It's our job to keep the complexity _down_ while increasing the power
of the underlying primitives.

Gilbert Pilz Jr.  "I don't believe in nihilism, anarchy is too confining
gil@banyan.com     for me, I have no opinion about apathy." - g. panfile