Alfredo writes:

> As background (or as "chile picante" or foil?), you might check:
>  http://users.adelphia.net/~lilavois/Cosas/Reliability.htm

Although I had never heard of Louis Savain before -- and my suspicions about
the credibility of anyone are automatically raised whenever they say, "the
experts are wrong" -- he and I do fundamentally agree when he writes:

"I will argue further that moving to a signal-based, synchronous software
model will not only result in an improvement of several orders of magnitude in
productivity, but also in programs that are guaranteed free of defects,
regardless of their complexity."

When he writes about a "signal-based, synchronous" model, he *is* describing
a finite state automaton. And in that regard, I don't mind a bit giving away
the two most important take-home lessons of the class:

The First Rule of Open-Loop Programming: "Never do it."
The First Rule of Asynchronous Programming: "Never do it."

All devices, whether they are software- or hardware-based, interact with
their environments through an alphabet of signals and triggers. You, as the
designer, want to expel every bit of probabilitistic behavior out of their design.
Everything you do, you want to make as simple as possible -- and you want it to
be 100%, fully deterministic.

To do this, you must know what state you are in at all times, and that
entails building a top-most "wait loop", which itself is often governed by a
heartbeat sequencing timer, attributes which occur in all synchronous machines. If
you do this, you can build systems of amazing behavioral complexity surprisingly
simply.

The primary difference between what Savain writes and I propose to teach is
that Savain resorts to a fair number of vague and mystical phrases in his
discussion, while I intend on being fairly hardnosed and pragmatic in the lectures.


>  I highly recommend Wirt's course.  Even though I have never taken this
>  particular offering, I have enjoyed learning about "a very pretty idea,
>  finite state automata theory" from Wirt for the last 25 years or so --
>  although I prefer to spell the topic thus: finite-state automata ;-)
>
>  This may very well be the best-invested $125 in your careers.

The class is the same thing that I've taught everyone here for the last 30
years. I know the process works because we've built about 100 large programs and
instruments, and for the most part, they've just fallen together, simply
because the same design has been repeated over and over again, and they have
consistently proven themselves to be exceptionally reliable systems.

I don't mind admitting that I have an ulterior motive in teaching the class
as an on-line experiment. We've developed a new product, QCShow, that we intend
on marketing as a long-distance education mechanism, but no product ever
demonstrates its worth (or its weaknesses) until it's used in circumstances for
which it was designed. I need to find out how well it does work in a classroom
situation.

Because of this guinea pig-like nature of the class, I'm only charging 1/3 or
1/4 what the same class would cost in more professional situations, thus if
you are even mildly interested, this might be the time to take the class.

You might say that the class really doesn't have any relevance to you or your
daily activity because you don't program at any deep level or design systems,
but in fact you do. When you connect one machine to another by writing
scripts, you are designing a finite state automaton, and if you do it right, you can
turn a "kluge" into a highly reliable structure.

Wirt Atmar

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *