Ospreys and Complexity

The radio is full of talk about the Osprey that came down the other day.

Yesterday, the US military told us that the refueling hose got caught in the blades. Blown into the blades by turbulence.

It was over the ocean, at least, not over populated areas. Of course, the wounded bird needs a place to land, and Okinawa doesn't have any non-populated places to land a wounded bird.

What were they doing practicing refueling in bad weather? Hmm. Practicing refueling in bad weather, I suppose. You can't guarantee good weather for military operations, you see.

My wife's radio talk show host points out this morning that, even though the crash was operator error rather than machine malfunction, the Osprey has more than its share of crashes.

The Osprey is an example of designing beyond the edge of the envelope. We think we need a machine like the Osprey (to maintain our military advantage, I suppose), so we accept that part of its operational profile includes stuff that is not safe. (Look at the Osprey taking off or landing, then ask yourself whether you want to practice refueling that bird in good weather. Heh.)

If you accept the logic of military activity in self-defense, eventually you have to accept the logic of using dangerous machines in military activity.

(While I was listening to the radio, I was thinking about the tendency we have, these days, of accepting dangerous behavior as commonplace, thinking about poorly designed embedded controls programs, and the ascendance of the x86 CPU.

Thinking about a LISP programmer who re-wrote a Forth interpreter in LISP for the space program because he didn't understand how Forth works, and couldn't read 6809 assembly language. And the irony of this was that he was lamenting the move from LISP to C.

Trading a Forth controller on 6809 for a LISP controller on 80x86. For the space program. And not understanding that the reason that C gets the new designs is precisely that Forth and LISP are too easy to customize, and that the programmers fail to be able to communicate their customizations in standard jargon.

[Woops. Having just posted this, I decided to try find the anecdote again.]

He couldn't read the Forth because learning Forth was not in his priorities. [Actually, he really did not have time.] -- Forth is not hard, you just have to re-think things. -- He would have had to recognize that there are other ways to process lists than the LISP way. [Specious conjecture on my part, there.]

The next engineer to read that programmer's LISP is going to have an even worse time, unless he is someone like me, interested in both Forth and LISP, in addition to C and the C standard run-time, etc.

[I didn't find the anecdote I had read, but I found a related one. (Link here. Some of the links in that post might take you to the anecdote I am thinking about. I need to do some real work, today.) It wasn't NASA, it was JPL. And some other irrelevant details, including that the engineer I am referring to did, too, understand the larger problems. He just couldn't figure out a way to communicate them to management. Mea culpa. I was wrong in the details, but it doesn't change my conclusions, whatever they are.]

Thinking about how scary it would be to fly a rocket being controlled by x86 CPUs. :-<

Thinking about how everybody is a slave to the arbitrary deadline, how we give up things of real value because of that deadline.

There is a lesson in here somewhere, but it got lost in the details. And the Osprey example is a good example, but not strictly because of the hardware in the controls circuitry. We must quit teaching engineers in every field, including economics, that engineering is a field where morality can safely be ignored.

Yes the problem is not the Osprey itself. It's the mindset that requires it.

The arbitrary deadline.

Who is going to be the first to back down when brinksmanship puts other people's jobs and lives in danger?)

Classes of Machines, Revisited

I think I've found a place to get some traction.

Although I will have to write under the assumption that I will be misunderstood. There is no way to avoid that, however, and keeping silent is not an option any more.

Instead of four levels of complexity, I'm going to go for just two. There are two classes of machines:

• Machines that can be understood, and
• Machines that cannot be understood.

Now there is a nice division, and a proper binary partition, I think. Except, it's semantically incomplete. Understood by whom? Is it

• Machines I can understand, and
• Machines I don't understand.

Or is it

• Machines that some human somewhere can understand, eventually, and
• Machines that no mortal human anywhere could ever understand?

Okay, it's neither of the above. Not only have I moved the boundaries of the partition, but I have failed to make proper partitions in either of the latter two. Let's try this:

There are machines that a human might reasonably expect to understand in a lifetime of attempts to characterize them, and there are machines that would take longer to understand than any human is either willing or able to devote the time to understanding.

Now the boundary is fuzzy, but it provides a better working basis for discussion.

The next problem is to try to characterize the boundary.

Woops. There are two ways to cut this boundary. One is the boundary between real machines and ideal machines:

• A human might understand an ideal machine.
• A human can never fully describe and understand a real machine.

This is an important division, and it has serous implications in the patent office as well as in the laboratory. It's a hard fact for proud humans, whether engineers, sales crew, customers, managers, bureaucrats, or monarchs. It's a bitter pill to swallow.

Fortunately, we can understand many real machines sufficiently for practical purposes. That is, we can build understandable models of ideal machines that match real machines closely enough for many practical purposes.

That makes the pill a little easier to get down. Unfortunately for patent examiners, judges and juries, plaintiffs and defendants, the question of which practical purposes remains open for any specific machine.

There is another division, somewhat orthogonal to the division between engineering specifications and mathematical models on the one hand, and actual machines on the other.

It applies to our engineering models. and projects onto the real machines modelled thereby.

Again, the boundary is a bit fuzzy, but it involves an arcane device from computer science called a stack.

A stack is a place to remember things. We push facts onto the stack, do some work that might make us forget those facts, and then come back to the stack. The "last-in, first-out" nature of the stack helps us keep our work organized and flowing. Until we find that something in our work alters a fact we have buried down the stack somewhere.

So it's useful to have another stack, and we can shift facts from one stack to the other, keeping them in order, and then shifting them back where we are done.

Some people don't like stacks. Too many constraints. It's easier to have a pigeon-hole rack of boxes to keep those pesky facts in, and then you can just grab whatever facts you need when you need them. Pigeon-hole racks are useful for many things, like post-office boxes and such. But they really don't provide a basis for remembering what you need to work on next in solving a problem, or in maintaining control of a machine. Stacks provide that organization.

This is the best basis for the partition that I know of:

• Machines that only have to track a few facts (operating states) can usually be understood. But they aren't very flexible. Think of a simple light switch.
• Machines that have a single stack to track facts can be described and understood in most cases. The stack provides our basis for understanding. If we or the machines lose track of what we are doing, we can go back to the stack to remind us.
• Machines that have two (or more) stacks are a bit trickier, but still are generally within reach, as long as we don't end up shifting too many things from one stack to another.
• Machines that keep too many facts (states) randomly accessible are easy to lose control of, easy to think we understand when we don't.

And the partition between machines which we can understand and those we can't falls between the last two classes.

Unfortunately, human language, when analyzed mathematically, falls into the latter class. So does pretty much every machine, tool, or system with enough flexibility to be useful. Animals, also, when we try to analyze them in some methodical way, fall into the last class. Humans? Of course we fall into that last class. Simply feels free, but we quickly find simple to confining. Free of cares is not freedom.

The tools we call computers? Well, that's a good topic for discussion and consideration. Later.