CompuServe Thread

>I don't know whoever said it first, but I consider it >true: EVERY more or less big program contains several errors. Number of errors alone is of course inconclusive of anything, but in general I'll buy that. And no doubt EVERY more or less small program containsseveral errors. In a way, this is one of the roots of what this thread has been about. How can we go about expressing our designs, and their subsequent implementations, and their maintenance, reuse, etc, so as to reduce that reality, and make it more flexible. >Most of the time this is no problem for a program but, as far I am concerned >it is a problem if you are speaking about a programming language! Not sure I understand. Unless we're talking about throw away apps, or stochastic'y apps, I always consider an error a problem. I agree in some facets a weight can be put on things (say the difference between an malfunctioning ATM bank machine vs a malfunctioning pacemaker) but still, I'd make the effort for both of them. >The one thing no theory I know of takes into account are just plain, human >typing errors. Even if I didn't want it, bringing up this fact, has forced me >to ridiculize a few professors at a small university here in Brussels. The >reactions showed that people understood what I was saying but I was embarrassed >in their place. I consider there to be an arsenal of such things, and typos are certainly in there. In the grand scheme of things, I don't consider them to actually be of the highest priority (but they do have some priority and hence are not discarded). Again, things like the universe can made some things even less at the top too. For instance, typed languages, and/or language that force you to declare things (this doesn't cause the problem to go away, and in some way even artificially disguises — perhaps this was your point — but to the professional, a help not a hindrance or constant issue). And so on.