Warning: this post is a rambling whose content to noise ratio may be quite low.
Follow along with me as I consider a simplistic view of a little piece of software. The point of this story is how many little pieces of information have to be collected, and how quickly the logical complexity grows, with even this simplistic example. After the story I’ll draw my little connection between programming and the human mind, and how we might (at a high level) close the gap a bit.
I just got a docking station for my laptop. It’s the first time I’ve ever had one, and I like it. A new button has showed up on my Start menu next to Log Out and Shutdown named Undock Computer.
This button reminds me of those old icons in the system tray for “Removing a device,” which was usually a USB device. You could yank it out any time, and sometimes Windows would tell you, “You really should click Remove Device before doing that.”
Whenever there’s a software button to do something that is actually a physical action it makes me curious. What will happen if I just physically undock my laptop without pushing that button? In the USB case, nothing ever happened to me. In the docking station case, I don’t know yet, but I’ll find out before too long.
Enough set up: here’s the story. What if undocking without clicking “Undock” crashes miserably? How could Windows detect this and tell the user on next startup? Something like, “It looks like you crashed because you didn’t undock the right way. Click the button first.”
So here is my simplistic approach. Windows will need to track the following data points:
- A “Windows Crashed” flag. This flag itself is interesting, because when you crash you can’t write code to execute. So you’d have to set this flag to True when Windows starts up (storing it on a disk somewhere), and then set it to False when Windows shuts down properly. Windows can then check this flag on startup to see if it’s still True; if so, it means there was no proper shutdown, so you can assume it was a crash.
- We need another flag: “Windows Crashed shortly after the computer became physically detached from the docking station.” This is also tricky to catch, because once you crash, you can’t be setting flags. So, like the first flag, we need to manipulate information before the crash that we can analyze later to detect what probably happened at the point where we could no longer collect information. In this case, maybe we could have two flags; one would be stored at a very low level in the computer: the very first controller between the computer and the docking station which is simply, “Controller: Is Docked.” This has to be very close to the physical stuff, so the instant the contacts touch the dock, and the instant the contacts are removed from the dock, this flag is updated. We’ll need one more flag, “Windows: Is Docked.” Windows will update this flag last in its list of compensating actions when docking status changes. So finally we have our “Windows Crashed shortly after undocking” flag: If “Windows Crashed” = True and Controller:Docked = False and Windows:Docked = True, then we know we crashed sometime between pulling the laptop out and Windows compensating for that. Incidentally we also can detect if putting the computer crash during docking as well.
- Another flag, “User clicked Undock button before undocking.” Just set the flag to True when they click the button, and put it back to False when the computer becomes docked.
We might think this is all we need. If Windows Crashed AND Windows Crashed Shortly After Undock AND the user did not click Undock, then we display the message.
However, being an experienced programmer, I consider that there will be circumstances I can’t imagine where these flags will get set up this way but it’s not due to docking stuff; maybe Windows didn’t even crash, but somehow the logic above tells that it did.
My experience also tells me that this will not happen to very many people, but for those to whom it does, it will probably happen to them a lot. And they’ll get really sick of this message box accusing them of being stupid when nothing bad even happened whenever they start the computer up. So, one more flag!
- “Don’t tell the user about undock crashes any more.” This flag will default to False but will be set to True when the user clicks on the little checkbox we add to that message box, “Don’t tell me about this anymore.”
Now, on startup, all we have to do is:
- See if Windows crashed.
- See if the crash was due to an undock (using the two flags comparison described above).
- Make sure the user has not asked to ignore this message.
- If all the above are true, show this little message.
I could belabor the point: this is complicated. Thinking through all these things, and then taking for granted that it’s possible to even get a handle on this information, it’s still complicated.
The point is to illustrate how computer programmers today have to explicitly and meticulously gather and handle every piece of information. Data collection is explicit: if we want to know something, we have to get it and store it, and we put it in a little bucket (called a variable or a database record) with a little label on it, and we write logic to do different things based on what’s in all these little buckets.
Contrast this with the way the human mind works. Can you recall what you had for breakfast yesterday? Did you explicitly decide to store that information yesterday? Our minds gather tons of data, but it’s not explicit like a computer. (Interesting that good memorization techniques actually use explicit storage mechanisms through association.)
The processing we do on this data is also extremely complex, but not explicit. When making decisions on things we usually don’t run through a certain algorithm where we consider all the facts and come up with output. The reason, I believe, is that there are so many data points that go into most non-trivial decisions that if we tried to explicitly recall these data points and apply a known algorithm to these data points we wouldn’t be able to function. We would be locked in analysis paralysis.
Back to computer programming: my interest in Genetic Algorithms and Neural Net techniques comes from its similarity to our minds:
- The data points become less explicit: stuff that’s relevant is mixed in with stuff that’s irrelevant, and a human doesn’t have to tell the computer which is what.
- The processing on these data points, while they are very well defined, are not explicitly defined by the programmer.
Because of these two attributes, these non-traditional techniques can solve problems that are very difficult with much less human effort, and often times much less runtime computational effort.
A next step in this thought is to explore new ideas of programming models that are even less explicit in their data definitions and process definitions.