On Mon, May 20, 2002 at 12:48:43PM -0700, Paul Makepeace wrote: > Without wishing to start an egregious flamewar, Java has done this for > quite some time and might go some decent way to explaining why folks > don't take perl seriously for "enterprise" type of work.
I believe our problems lay solely in not realising what we'd managed to build. The design mistake was actually in the stored procedure (the idea being that perl was just doing the presentation layer) so it wasn't really a perl screwup. Also, I think that the DBI modules let you do explicit commit/rollback if your program the thing in. But you have to know what you're doing. I'd suspect that a better reason for Java being favoured for enterprise work (and I've not looked at any Java libraries, or ever had need to learn Java, so I could be talking out of my backside here) is that perl doesn't have any of these sort of things already as nice, well designed, well thought through libraries with APIs that you can use. Instead, it, or its typical users, are far keener to roll their own (as we were doing) and get to make these sort of subtle mistakes. (I believe that this was the only subtle mistake with serious implications we made, and we (to be fair, not me personally) spotted it) It's not like datacash supply you with anything more than an API at the level of "take money" and "return money" - it's effectively an open invitation to knock together a few CGIs and go live with great haste. > As an aside, I'd tend to err on the side of *not* rolling back once the > user has hit submit. The Stop button, IMO, is not a UI widget for > cancelling e-commerce transactions. The user will get an email after the > transaction starts saying "cheers, your stuff's in the mail" and then if > they can call the support number and cancel the order. I quite agree. Our problem was not that we (the firm) wanted to be able to cancel the transaction if they hit stop, it was that we (the developers) had accidentally made a system that would debit the customer but have no record of doing so, for certain edge case situations. Instead of the classic comic book lightbulb blinking on, Craig had this steaming pile of brown stuff blink into existence over his head, as he realised the implications of the system currently in CVS. There was a chink in all his careful, defensive database work whereby it could not only fail to record data in some situations, but that the first we knew about it would we when some irate customer (or their credit card company) came complaining that we'd stolen their money. Mainly I wanted to get across that writing websites that take money is an order of magnitude more scary than websites that just deal in information. Nicholas Clark -- Even better than the real thing: http://nms-cgi.sourceforge.net/
