Re: What is the quintessential Apple II?

["mdj" <mdj.mdj@gmail.com>]

Michael J. Mahon wrote:

> In the computer engineering game, there were two popular allocation
> biases:  "put it all in hardware" and "put it all in software".  (Of
> course, now even the hardware is software!  ;-)  Which completely
> ruins my saying that, "The hardware is the easyware--the software
> is the hardware!")
>
> I tend to the "put it all in software" camp, as my projects clearly
> demonstrate.  Steve Ciarcia, for one, used to lean toward the "put it
> all in hardware" camp--until hardware became software.  ;-)  Of course,
> most real designs will not be all one or the other.  Each design point
> of view will see the designs of the other as "distorted" by bias.  But
> despite the difficulty of objectivity, experience shows that, under a
> particular set of circumstances, functions should be allocated (or
> partitioned) in a certain way to achieve a near-optimal result.

I've always felt a good rule was "do in software that which cannot be
done more efficiently in hardware". Doing too much in software can
compromise the performance of a design, while doing too much in
hardware compromises flexibility. Although, as you point out, not
anymore due to 'soft' hardware :-)

Of course, we the enthusiasts would prefer to assess designs based on
the design, and ignore the time constraints on the designer. It's also
reasonable that design 'quality' have the time investment involved in
its realiastion be a part of it's metric. And herein lies the problem.

> It's turning out that we are utterly dependent on a relatively small
> cadre of embedded system programmers who are increasingly driven to
> meet unrealistic time-to-market goals.
>
> We are currently in the process (nearly completed) of teaching this
> cadre that "Getting it first is better than getting it right.", and
> "Don't worry, the early adopters will put up with anything."

The problem is there's just enough truth in that to keep the cycle
going :-)

> You are beginning to experience the results of this training program.
> ;-)
>
> My saying:  "Never get version 1.x *or* version x.0."

A number of firms are beginning to experiment with delivering the last
iteration of a products major version as the first iteration of its
next version, and 'quietly' slipping the major changes in x.1. I
recently had to fight the early adoption of x.1 of a product due to my
workplace considering it as a bugfix/update despite the underlying
reality that it was far, far more than that.

> But don't worry--help is on the way!  As even tiny embedded machines
> get very fast with large memories, it is becoming possible to create
> 95% of what we need by parameterizing a standard framework (using a
> graphical interface that marketing can understand and manipulate,
> of course).

In a world where sub $1000 PC's have > 3GHz processors, more than one
of them, and multiple gigabytes of RAM, I'm mindful that promise was
made before. Each time a major improvement in design methodology came
along, demand (in terms of expected functionality of product) expanded
to match it. It takes seemingly no time at all for someone to come up
with an innovative product which pushes the limits of what's acheivable
with delivery technology X, and the rest of pack, in an effort to
scavenge whatever market share than can from the innovator, will push
the limits of any delivery methodology from a time perspective, with
the above mentioned consequences :-(

Matt