Re: The need for strong typing...

> 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.