> 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:
Yes, I think so too. Different languages for different things. Even
COBOL has a valid reason for existing. In fact, most of my app is
written in pl/pgsql, which is a lot like COBOL in that it has very
limited capabilities and a very clear syntax and strong typing. It's
hard to make mistakes in it.
> >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.
That's true for old-style financial apps, where a check can be
bounced, transactions reversed, etc, but in a modern real-time gross
settlement system, errors can be very expensive, and hackers are
always on the prowl. Spending $100k to make sure the code is
rock-solid is probably cheaper than letting some errors or
uncertainties creep through.
> 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".
Good point. Another point is that this software will not suddenly be
used for billion-dollar payments. It will start with a small user
base and small values, where mistakes won't be fatal, and then it will
grow, and as it grows, there will be more code reviews, design
reviews, etc.
> 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.
Interesting story. Fortunately, financial transactions are actually
simpler than shuttle launches. Really, the whole thing consists of:
1. Is the user authorized to make this transaction?
2. Does the user have sufficient funds/credit to make the transaction?
3. Is the recipient authorized to receive the transaction?
4. Lock the sender's account.
5. Check the funds/credit again.
6. Make the transaction.
7. Unlock and inform the user.
It's simple, but mistakes are expensive.
I will look into JSP.
Even on the same website, we could have two different languages: Maybe
we'll use JSP for the transaction stuff, and PHP for customer support
pages, where things are less critical.
--
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]
