I was going to write a whole diatribe, venting rage, trying to
prove you wrong etc, etc... and then I got to the last paragraph
and realised we probably actually agreed:
>This doesn't mean that PHP should be changed to allow strong typing.
>It may mean though that PHP isn't the right language for rigorous
>applications like financial transactions.
The main problem with the Oxy-Acetylene analogy is that there is very
little that anyone does with PHP that could even vaguely be considered
life threatening - in most cases the worst case scenario is that if
something goes wrong, someone will get a bit annoyed. Even with
financial transactions - an error going wrong there is really BAD,
but generally it CAN be tracked down and fixed, and no one is going
to die as a result.
This has always been a problem with Software - it has never truly
been "component" based. On some level it is always like being given
the same ball of string to solve every problem, whether it be a fence,
a clothesline, or an inter-planetary catapult system.
Anyway - you talked about having a series of hurdles for things
to get past. So, "strong typing" has been removed as a hurdle - fine,
lets just add in a few more like "rigorous testing" and "rigorous
code reviews" and "careful design" and "rigorous design reviews".
The MOST mission critical software ever written is, I think, the
software that controls the space shuttle as it gets launched. Once
the final ignition sequence goes off, nothing can stop it and the
only thing controlling it is the software. That graceful takeoff and
roll it does on takeoff would be impossible for a human to control.
That software is as close to bug free as you will ever get. It is
also incredibly expensive because EVERY change is reviewed, analysed,
studied and tested incredibly thoroughly to review it's impact and
to make sure it will have no roll on effects.
At 01:43 13/07/2001 +0000, Dr. Evil wrote:
>As you know, gases such as oxygen and acetylene are distributed to
>welders in pressurized containers. As you can guess, it is very
>important to put the right stuff in the right container. Let's say
>you have a container of acetylene, and you accidentally top it up with
>some pure oxygen. This is likely to be a life-altering exerpience,
>and not in the New Age chanting-in-a-sweat-lodge sense if you know
>what I mean.
>
>The naive solution to this problem is to put a big sign up that says,
>"Warning: be very careful about which gas you put into which tank."
>I'm sure that was the first approach that was tried when pressurized
>tanks for welding were first developed. After a few people died by
>putting the O2 in the C2H2 tank, someone came up with a brilliant
>solution: Let's put reverse threads on the O2 tank attachments. That
>way, the tank, and all the hoses and connectors that go with it, can
>never be attached to a C2H2 tank, because of a physical contraint in
>the connections themselves. O2 uses left-hand twist and C2H2 uses
>right-hand twist, and so the two will never meet. No matter how
>asleep, negligent, or incompetent the filling operator is, he'll never
>end up with O2 in the C2H2 tank. Even the sharpest, most cautious
>tank filler will eventually make a mistake if he does it enough times,
>but never if the threads are reversed.
>
>Data structure contraints are exactly the same idea. In my DB I have
>a table for "payments". Every time Alice pays Bob, a row gets added
>to this table, with one of the columns being "amount of transfer". Of
>course, on the PHP side, I put in a check:
>
> if($amount <= 0) { // error condition }
>
>but, in addition to that, in the database itself, I have
>
> CONSTRAINT amount > 0
>
>built into the table definition. That way, no matter what goes wrong
>on the PHP side, Bob will never be able to say, "Pay alice -$1mil",
>and find his account $1mil richer. The value is checked (several
>times) in the PHP side, but the right behavior is built into the data
>structure (table) itself.
>
>Strong typing is a sort of constraint. Just like I don't want to be
>using O2 when I think I'm using C2H2, I would like to be sure that
>I've got an INT and not a STRING when I expect an INT. Saying "write
>a bunch of functions to check user input, and don't make any mistakes"
>is just like putting up a sign that says, "Be very careful to not put
>O2 in the C2H2 tank." Yeah, if I were perfect, that would be enough,
>but in the real world, when you're dealing with serious things like
>exploding tanks and money, you want some built-in constraints in the
>system. You want correctness to be enforced at several different,
>independent layers.
>
>This same design principle applies in many different realms: my
>motorcycle has completely independent front and rear brakes, so even
>if one system fails entirely, I can still stop. My Glock has three
>independent safety systems (trigger block, firing pin block,
>decocking) which must each be operational for it to fire. It's just
>good design to have redundant constraints to achieve high reliability
>and safety. Strong typing is one of those contraints.
>
>This doesn't mean that PHP should be changed to allow strong typing.
>It may mean though that PHP isn't the right language for rigorous
>applications like financial transactions.
>
>
>--
>PHP General Mailing List (http://www.php.net/)
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>To contact the list administrators, e-mail: [EMAIL PROTECTED]
-------------------------
Brian White
Step Two Designs Pty Ltd - SGML, XML & HTML Consultancy
Phone: +612-93197901
Web: http://www.steptwo.com.au/
Email: [EMAIL PROTECTED]
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
