On Tue, 30 Jan 2001, Bruce McCulley wrote:
>> The point was, how do you define "correct"?
>
> doesn't matter how you define "correct", a program is correct when it mets
> the applicable definition of correctness, and not before.
Ummm... huh? It does not matter how one defines correct, but a program is
correct when it meets the definition of correct? I got an error code EMLINK
on that one, Bruce. :-) Still, I think I know what you mean. (Scary!)
> But using locality of reference for the definition of correctness means
> you can both be correct :-)
Right. And before one can understand recursion, once must first understand
recursion. ;-)
[RE: testing a program before using it to control millions of dollars]
> Usually, there is rigorous testing.
This reminds me of a Dave Barry quote, regarding an official Pentagon
response to an inquiry about Y2K bugs in Strategic Air Command systems: "Am I
the only one who gets worried when the words 'reasonably confident' and
'nuclear weapons' get used in the same sentence?"
> Sometimes it just gets slighted. No big deal, when you misplace a billion
> or two it gets noticed and fixed pretty quick :-)
While somewhat cavalier, this can actually be a legitimate method of
operation (although I wouldn't my money in that bank, myself).
On the other hand, some systems do require a more... detailed approach to
software engineering. For example: A team develops a specification. An
independent team reviews that specification. Two more independent teams
create two completely separate implementations of that specification. Each
member of each team has a partner whose job it is to scrutinize each change to
ascertain that it is doing what the programmer things it does. Two *more*
independent teams audit the code, line-by-line. These two implementations are
then installed on a total of five redundant hardware systems. Should any
inconsistency occur, the systems vote amongst themselves to determine the
correct course of action.
This is how NASA's Space Shuttle operates. When you're accelerating at
thirty meters per second per second with over half a million gallons of highly
explosive liquid fuel strapped to your ass, one cannot take time out to debug
the code. :-)
To go back to the quote that started all this, if one were to simply throw
together a two-line Perl script and submit it to NASA as a fix for some
problem on the Space Shuttle, I expect one's boss would fire you right quick.
Getting the job don often does include a great deal more then simply
generating a program that runs to completion. I guess I was ass-u-me-ing that
was implicitly understood.
On Tue, 30 Jan 2001, Bruce McCulley wrote:
> you just hit one of my hot buttons, so no, it can't die.
Well, since you restarted it, Bruce, I'll go ahead and post this reply that
I originally withheld. (What, me, not post something? I know, I know... I
must be slipping. ;-)
On Tue, 30 Jan 2001, Kevin D. Clark wrote:
> For example, I know quite a bit about the internal structure of Perl.
You have my sympathies. I looked at the Perl C source once. I still have
nightmares about it.
> Up until a few years ago, the manner in which Perl handled signals was
> kindof {ad hoc} (this has recently gotten a lot better).
And this is different from any other part of Perl how...?
J/K ;-)
> Now, signals are notoriously difficult to deal with, and they're even
> more notorious to deal with in a portable way (and by "portable" I
> mean dozens and dozens of platforms). I mean, if you truly grok the
> problem here, you might want to stab your eye out with a pencil...
My solution for portability is typically to bypass the problem by installing
Linux. This is not always terribly practical or politically correct, but it
does keep things interesting. ;-)
> ... one of the chief implementors of Perl ... argued that Perl's signal
> handling code was "good enough" and that even though it had problems, it
> was "good enough" for his purposes and that he'd be willing to live with
> the occasional failure.
Well, for his purposes, he was probably right. It likely wasn't going to
get him fired or keep him from getting the job done. Now, obviously, that
decision, if followed by all, would affect a great many people. Fortunately,
as you say, others considered signal handling more important.
There are a few lessons here.
One is: Where you stand depends on where you sit. In the context of the
current discussion, whether a program is correct or not depends largely on how
important it is to you. (This is Bruce's point, I believe.)
Corollary to that: Never trust anything further then the guy who built it
does.
Another lesson is one of the ways Open Source wins. If this was a
proprietary product being engineered by a closed team, that decision would
have stood, and there would be nothing anyone could do about it. Because it
was open, people could say, "No, signal handling *is* important to *us*, and
we're going to do it right, thank-you-very-much." Try that with Microsoft.
> But sometimes, in the Perl community, I think that some people say "good
> enough" a little bit too quickly. And I like to resist that notion a
> little bit.
Don't forget, there are at least three Perl communities, albeit with heavy
overlap between them. One group hacks the internals of the
compiler/interpreter, and the language itself. The second group implements
modules, contributes Perl code, writes poetry, etc., but generally doesn't go
near the C code that actually makes it all happen. Then there is the group
which just uses Perl as a tool or a means to an end.
(Another political aside: With your typical closed-source product, only the
last group really exists as a community. If you're lucky, you might get a
"third-party additions market". You'll never touch the internals.)
The appropriateness of that Larry Wall quote is inversely proportional to
one's proximity to the Perl core. :-)
Well. That should keep Kenny happy for a while. ;-)
--
Ben Scott <[EMAIL PROTECTED]>
Net Technologies, Inc. <http://www.ntisys.com>
Voice: (800)905-3049 x18 Fax: (978)499-7839
**********************************************************
To unsubscribe from this list, send mail to
[EMAIL PROTECTED] with the following text in the
*body* (*not* the subject line) of the letter:
unsubscribe gnhlug
**********************************************************
