# PCT and the design of computer programs
**URL:** http://discourse.iapct.org/t/pct-and-the-design-of-computer-programs/8354
**Category:** CSG2009
**Created:** [February 26, 2009, 11:23am UTC](http://discourse.iapct.org/t/pct-and-the-design-of-computer-programs/8354 "2009-02-26T11:23:42Z")
**Posts on this page:** 3
**Page:** 1
### Author:  [@Bill\_Powers1](http://discourse.iapct.org/u/Bill_Powers1)
#### Post date: [February 26, 2009, 11:23am UTC](http://discourse.iapct.org/t/pct-and-the-design-of-computer-programs/8354/1 "2009-02-26T11:23:42Z")
[From Bill Powers (2009.02.26.0300 MST)]
It's amazing how long it takes my brain to see something obvious.
I've been struggling for days with a computer that has things wrong
with its operating system, and spending hours looking up remedies on
the Web and trying to figure out how to carry them out, or simply
trying to understand what they mean. And making mistakes that cure
one problem and cause another. It has finally dawned on me why this
is such a frustrating problem.
Suppose I want to build a control system that will turn on a light
when a room gets dark. If I were to design this system the way
operating systems are designed, I would get a photocell to measure
the light level in the room, and hook it up so that when room gets
dark, a relay closes and turns on a printer which prints
THE ROOM IS DARK. PHOTOCELL HAS ENCOUNTERED A PROBLEM. LIGHT SUPPLY
FAILED. CANNOT START ELECTRON FLOW INTO LIGHT BULB. ILLUMINATION
SERVICE IS CORRUPT AND UNSTABLE. SWITCH.DLL NOT FOUND.
I would package this device with a printer and sell it for lots of
money so people who bought it would understand why it doesn't turn
the light on when the room gets dark, although it was sold as a
device for accomplishing that purpose. On the back of the package
under a label, of course, in small print, there is a notice saying
that opening the package is equivalent to accepting the End User
License Agreement, which clearly states that this device is not sold
with any assurance that it does anything useful, and anyway all you
are buying is a license to try to use it.
On the other hand, if I wanted to make sure this device would,
indeed, turn the light on when the room is dark, I would use the
photocell to active a relay when the room gets dark, and hook up the
relay so it turns on the light.
There is something very peculiar about a machine that delivers error
messages to its user. It's one thing for the user to try to do
something with the machine and have it not happen or have the wrong
thing happen. That is an error that the user doesn't need to be told
about. But it's another thing for the user to be told "I know what is
wrong, but I'm not going to fix it and I'm not going to tell you how
to fix it." This isn't information, it's mockery. If you know
something is missing or broken, I ask this machine and its designer,
why don't you know where to get another one? If you know how to fix
the problem, why don't you just fix it instead of telling me all
about it? If you don't know these things, what are you doing
designing machines anyway?
Fred Nickols has been asking about practical applications of PCT. I
can see a great big one here. Let's take all those error messages and
throw them in the trash, and in their place build little programs
that fix errors when they are detected.
How does a program know that, for example, "igfxtray failed because
hccutils.dll not found"? Obviously, it tried to find that dll and
didn't. But how did it know where to look? Obviously, it knew where
that dll was supposed to be. It's like the worker who comes on the
job and sees that a tool is missing. How do you know something is
missing? You try to use it and it's not where it's supposed to be.
So what is the worker who finds the tool missing supposed to do? Give
up and go home? Write out a complaint and drop it in the suggestion
box? How about going to the place where tools are kept and getting
one and putting it in the tool rack, or calling up whoever has that
responsibility and telling them to bring the tool? Any worker who
wants to do his job finds the tool somehow and gets on with it.
Well, this worker isn't in charge of seeing to it that the tool rack
is properly equipped -- that's the job of the people in the cage on
the other side of the factory. But what's to say that the tool rack
can't have a little printed notice in the space where each tool is
supposed to be, saying "If this tool is missing or damaged, dial 3333
for a replacement." Either the tool rack has the tool in it, or you
can see the notice. Heck, there could be a microswitch on the rack
that automatically signals the toolroom after a suitable delay.
What I'm saying is, let's build these systems like control systems.
Let's give them perceptions so they can tell what is happening, and
reference signals telling them what is supposed to happen, and
comparators that can see when there is a difference between those
things and generate an error signal. And let's hook up the error
signals not to send error messages, but to bring the perception
closer to the reference state, or to alter reference signals in other
systems that will take care of doing that. If the error correction is
going to take a while, we can allow one message to be delivered to
the user: "WORKING." If that message goes on too long, it gets
replaced with "CALL THE DOCTOR."
Obviously, somebody knows what to do when hccutil.dll is not found.
The user of the program doesn't, but when the machine is taken to the
repair shop the repair person knows, or knows how to find out. If the
repair person knows, that knowledge can be put into a data base and
the error detection program can use it. The data base doesn't even
have to be in the computer (except for the parts relating to internet
communication). It can be in Bellevue, Washington.
Let's start a letter-writing campaign: NO MORE ERROR MESSAGES!. Every
time there is an error and it gets fixed, make a sketch of the
control system that could do it and mail it to Bill Gates or Steve Jobs.
And Fred, maybe you can start doing that with industrial designs.
Best,
Bill P.
No virus found in this outgoing message.
Checked by AVG - [http://www.avg.com](http://www.avg.com)
Version: 8.0.173 / Virus Database: 270.11.3/1973 - Release Date: 2/26/2009 7:03 AM
---
### Author:  [@Fred\_Nickols1](http://discourse.iapct.org/u/Fred_Nickols1)
#### Post date: [February 27, 2009, 3:21am UTC](http://discourse.iapct.org/t/pct-and-the-design-of-computer-programs/8354/2 "2009-02-27T03:21:30Z")
[From Fred Nickols (2009.02.26.2017 MST)]
I think Bill's ideas about building repair routines into software is a good one. I see reason why such fixes couldn't be included in periodic updates as the problems and solutions are discovered.
Seems like a simple enough algorithm to me.
As for doing the same for industrial designs, Fred no can do. I don't have access to the folks who run the shows.
> **···**
>
> --
> Regards,
>
> Fred Nickols
> Managing Partner
> Distance Consulting, LLC
> nickols@att.net
> www.nickols.us
>
> "Assistance at A Distance"
>
> -------------- Original message ----------------------
> From: Bill Powers \
>
> > [From Bill Powers (2009.02.26.0300 MST)]
> >
> > It's amazing how long it takes my brain to see something obvious.
> > I've been struggling for days with a computer that has things wrong
> > with its operating system, and spending hours looking up remedies on
> > the Web and trying to figure out how to carry them out, or simply
> > trying to understand what they mean. And making mistakes that cure
> > one problem and cause another. It has finally dawned on me why this
> > is such a frustrating problem.
> >
> > Suppose I want to build a control system that will turn on a light
> > when a room gets dark. If I were to design this system the way
> > operating systems are designed, I would get a photocell to measure
> > the light level in the room, and hook it up so that when room gets
> > dark, a relay closes and turns on a printer which prints
> >
> > THE ROOM IS DARK. PHOTOCELL HAS ENCOUNTERED A PROBLEM. LIGHT SUPPLY
> > FAILED. CANNOT START ELECTRON FLOW INTO LIGHT BULB. ILLUMINATION
> > SERVICE IS CORRUPT AND UNSTABLE. SWITCH.DLL NOT FOUND.
> >
> > I would package this device with a printer and sell it for lots of
> > money so people who bought it would understand why it doesn't turn
> > the light on when the room gets dark, although it was sold as a
> > device for accomplishing that purpose. On the back of the package
> > under a label, of course, in small print, there is a notice saying
> > that opening the package is equivalent to accepting the End User
> > License Agreement, which clearly states that this device is not sold
> > with any assurance that it does anything useful, and anyway all you
> > are buying is a license to try to use it.
> >
> > On the other hand, if I wanted to make sure this device would,
> > indeed, turn the light on when the room is dark, I would use the
> > photocell to active a relay when the room gets dark, and hook up the
> > relay so it turns on the light.
> >
> > There is something very peculiar about a machine that delivers error
> > messages to its user. It's one thing for the user to try to do
> > something with the machine and have it not happen or have the wrong
> > thing happen. That is an error that the user doesn't need to be told
> > about. But it's another thing for the user to be told "I know what is
> > wrong, but I'm not going to fix it and I'm not going to tell you how
> > to fix it." This isn't information, it's mockery. If you know
> > something is missing or broken, I ask this machine and its designer,
> > why don't you know where to get another one? If you know how to fix
> > the problem, why don't you just fix it instead of telling me all
> > about it? If you don't know these things, what are you doing
> > designing machines anyway?
> >
> > Fred Nickols has been asking about practical applications of PCT. I
> > can see a great big one here. Let's take all those error messages and
> > throw them in the trash, and in their place build little programs
> > that fix errors when they are detected.
> >
> > How does a program know that, for example, "igfxtray failed because
> > hccutils.dll not found"? Obviously, it tried to find that dll and
> > didn't. But how did it know where to look? Obviously, it knew where
> > that dll was supposed to be. It's like the worker who comes on the
> > job and sees that a tool is missing. How do you know something is
> > missing? You try to use it and it's not where it's supposed to be.
> >
> > So what is the worker who finds the tool missing supposed to do? Give
> > up and go home? Write out a complaint and drop it in the suggestion
> > box? How about going to the place where tools are kept and getting
> > one and putting it in the tool rack, or calling up whoever has that
> > responsibility and telling them to bring the tool? Any worker who
> > wants to do his job finds the tool somehow and gets on with it.
> >
> > Well, this worker isn't in charge of seeing to it that the tool rack
> > is properly equipped -- that's the job of the people in the cage on
> > the other side of the factory. But what's to say that the tool rack
> > can't have a little printed notice in the space where each tool is
> > supposed to be, saying "If this tool is missing or damaged, dial 3333
> > for a replacement." Either the tool rack has the tool in it, or you
> > can see the notice. Heck, there could be a microswitch on the rack
> > that automatically signals the toolroom after a suitable delay.
> >
> > What I'm saying is, let's build these systems like control systems.
> > Let's give them perceptions so they can tell what is happening, and
> > reference signals telling them what is supposed to happen, and
> > comparators that can see when there is a difference between those
> > things and generate an error signal. And let's hook up the error
> > signals not to send error messages, but to bring the perception
> > closer to the reference state, or to alter reference signals in other
> > systems that will take care of doing that. If the error correction is
> > going to take a while, we can allow one message to be delivered to
> > the user: "WORKING." If that message goes on too long, it gets
> > replaced with "CALL THE DOCTOR."
> >
> > Obviously, somebody knows what to do when hccutil.dll is not found.
> > The user of the program doesn't, but when the machine is taken to the
> > repair shop the repair person knows, or knows how to find out. If the
> > repair person knows, that knowledge can be put into a data base and
> > the error detection program can use it. The data base doesn't even
> > have to be in the computer (except for the parts relating to internet
> > communication). It can be in Bellevue, Washington.
> >
> > Let's start a letter-writing campaign: NO MORE ERROR MESSAGES!. Every
> > time there is an error and it gets fixed, make a sketch of the
> > control system that could do it and mail it to Bill Gates or Steve Jobs.
> >
> > And Fred, maybe you can start doing that with industrial designs.
> >
> > Best,
> >
> > Bill P.
---
### Author:  [@Wang\_Bo](http://discourse.iapct.org/u/Wang_Bo)
#### Post date: [February 27, 2009, 4:45am UTC](http://discourse.iapct.org/t/pct-and-the-design-of-computer-programs/8354/3 "2009-02-27T04:45:18Z")
Interesting.
I think the market talks. This is just how they are making money. The
businessmen would say, "You want higher stability? Why not try our
workstation xxx? You will get 7-24 tech support and bla bla bla"
If computer manufacturers care about end users as much as NASA care
about spacecrafts, we would "enjoy" more services. They will identify
the error and fix it remotely.
Best regards,
Bo
> **···**
>
> 2009/2/26 Bill Powers \:
>
> > [From Bill Powers (2009.02.26.0300 MST)]
> >
> > It's amazing how long it takes my brain to see something obvious. I've been
> > struggling for days with a computer that has things wrong with its operating
> > system, and spending hours looking up remedies on the Web and trying to
> > figure out how to carry them out, or simply trying to understand what they
> > mean. And making mistakes that cure one problem and cause another. It has
> > finally dawned on me why this is such a frustrating problem.
> >
> > Suppose I want to build a control system that will turn on a light when a
> > room gets dark. If I were to design this system the way operating systems
> > are designed, I would get a photocell to measure the light level in the
> > room, and hook it up so that when room gets dark, a relay closes and turns
> > on a printer which prints
> >
> > THE ROOM IS DARK. PHOTOCELL HAS ENCOUNTERED A PROBLEM. LIGHT SUPPLY FAILED.
> > CANNOT START ELECTRON FLOW INTO LIGHT BULB. ILLUMINATION SERVICE IS CORRUPT
> > AND UNSTABLE. SWITCH.DLL NOT FOUND.
> >
> > I would package this device with a printer and sell it for lots of money so
> > people who bought it would understand why it doesn't turn the light on when
> > the room gets dark, although it was sold as a device for accomplishing that
> > purpose. On the back of the package under a label, of course, in small
> > print, there is a notice saying that opening the package is equivalent to
> > accepting the End User License Agreement, which clearly states that this
> > device is not sold with any assurance that it does anything useful, and
> > anyway all you are buying is a license to try to use it.
> >
> > On the other hand, if I wanted to make sure this device would, indeed, turn
> > the light on when the room is dark, I would use the photocell to active a
> > relay when the room gets dark, and hook up the relay so it turns on the
> > light.
> >
> > There is something very peculiar about a machine that delivers error
> > messages to its user. It's one thing for the user to try to do something
> > with the machine and have it not happen or have the wrong thing happen. That
> > is an error that the user doesn't need to be told about. But it's another
> > thing for the user to be told "I know what is wrong, but I'm not going to
> > fix it and I'm not going to tell you how to fix it." This isn't information,
> > it's mockery. If you know something is missing or broken, I ask this machine
> > and its designer, why don't you know where to get another one? If you know
> > how to fix the problem, why don't you just fix it instead of telling me all
> > about it? If you don't know these things, what are you doing designing
> > machines anyway?
> >
> > Fred Nickols has been asking about practical applications of PCT. I can see
> > a great big one here. Let's take all those error messages and throw them in
> > the trash, and in their place build little programs that fix errors when
> > they are detected.
> >
> > How does a program know that, for example, "igfxtray failed because
> > hccutils.dll not found"? Obviously, it tried to find that dll and didn't.
> > But how did it know where to look? Obviously, it knew where that dll was
> > supposed to be. It's like the worker who comes on the job and sees that a
> > tool is missing. How do you know something is missing? You try to use it and
> > it's not where it's supposed to be.
> >
> > So what is the worker who finds the tool missing supposed to do? Give up and
> > go home? Write out a complaint and drop it in the suggestion box? How about
> > going to the place where tools are kept and getting one and putting it in
> > the tool rack, or calling up whoever has that responsibility and telling
> > them to bring the tool? Any worker who wants to do his job finds the tool
> > somehow and gets on with it.
> >
> > Well, this worker isn't in charge of seeing to it that the tool rack is
> > properly equipped -- that's the job of the people in the cage on the other
> > side of the factory. But what's to say that the tool rack can't have a
> > little printed notice in the space where each tool is supposed to be, saying
> > "If this tool is missing or damaged, dial 3333 for a replacement." Either
> > the tool rack has the tool in it, or you can see the notice. Heck, there
> > could be a microswitch on the rack that automatically signals the toolroom
> > after a suitable delay.
> >
> > What I'm saying is, let's build these systems like control systems. Let's
> > give them perceptions so they can tell what is happening, and reference
> > signals telling them what is supposed to happen, and comparators that can
> > see when there is a difference between those things and generate an error
> > signal. And let's hook up the error signals not to send error messages, but
> > to bring the perception closer to the reference state, or to alter reference
> > signals in other systems that will take care of doing that. If the error
> > correction is going to take a while, we can allow one message to be
> > delivered to the user: "WORKING." If that message goes on too long, it gets
> > replaced with "CALL THE DOCTOR."
> >
> > Obviously, somebody knows what to do when hccutil.dll is not found. The user
> > of the program doesn't, but when the machine is taken to the repair shop the
> > repair person knows, or knows how to find out. If the repair person knows,
> > that knowledge can be put into a data base and the error detection program
> > can use it. The data base doesn't even have to be in the computer (except
> > for the parts relating to internet communication). It can be in Bellevue,
> > Washington.
> >
> > Let's start a letter-writing campaign: NO MORE ERROR MESSAGES!. Every time
> > there is an error and it gets fixed, make a sketch of the control system
> > that could do it and mail it to Bill Gates or Steve Jobs.
> >
> > And Fred, maybe you can start doing that with industrial designs.
> >
> > Best,
> >
> > Bill P.
> >
> > No virus found in this outgoing message.
> > Checked by AVG - [http://www.avg.com](http://www.avg.com)
> > Version: 8.0.173 / Virus Database: 270.11.3/1973 - Release Date: 2/26/2009
> > 7:03 AM