My company barely existed in the 90s - it was some research project at Stanford.
And feature sets like "processes transactions" absolutely do go away because technology (and its applications) moves forwards. This was a large part of the success of MySQL: relational databases started getting used in applications where transactional integrity really wasn't that important, and they were better off working around it (or just showing inconsistent data to the user) rather than paying the price for transactions.
Or look at this recent discussion surrounding Google Megastore:
Megastore suffers a large latency penalty for ACID semantics. In many applications, it's better not to take that latency hit and instead settle for eventual consistency instead.
Arguably, this is just that new domains appear or grow from what used to be niche areas into big ones. The old problem domains requiring ACID transactions still remain.
Financial apps are a different story. I interned on Pay.gov in college, and then spent the first 2 years of my career at a financial software startup. The standards are much different when you're handling money (or avionics, or medical devices, or anything that's "mission critical"). And even in the finance world, the standards vary a lot depending on whether you're doing analytics or transaction processing.
But while that software will never go away, it becomes a smaller part of the whole software industry. Much of the interesting growth is in areas of software that have nothing to do with money, other than being able to make it. It's silly to apply the same standards to software that processes $10M/sec (as one program I once wrote did) as to software that lets you throw virtual sheep at each other.
Comments
My company barely existed in the 90s - it was some research project at Stanford.
And feature sets like "processes transactions" absolutely do go away because technology (and its applications) moves forwards. This was a large part of the success of MySQL: relational databases started getting used in applications where transactional integrity really wasn't that important, and they were better off working around it (or just showing inconsistent data to the user) rather than paying the price for transactions.
Or look at this recent discussion surrounding Google Megastore:
http://glinden.blogspot.com/2011/02/comparing-google-megasto...
Megastore suffers a large latency penalty for ACID semantics. In many applications, it's better not to take that latency hit and instead settle for eventual consistency instead.
Arguably, this is just that new domains appear or grow from what used to be niche areas into big ones. The old problem domains requiring ACID transactions still remain.
I meant transactions as in actual exchanges of money, not as in the computer science / database term.
Financial apps are a different story. I interned on Pay.gov in college, and then spent the first 2 years of my career at a financial software startup. The standards are much different when you're handling money (or avionics, or medical devices, or anything that's "mission critical"). And even in the finance world, the standards vary a lot depending on whether you're doing analytics or transaction processing.
But while that software will never go away, it becomes a smaller part of the whole software industry. Much of the interesting growth is in areas of software that have nothing to do with money, other than being able to make it. It's silly to apply the same standards to software that processes $10M/sec (as one program I once wrote did) as to software that lets you throw virtual sheep at each other.
I also think that it's silly to assume that all software follows the same rules as software that allows you to throw virtual sheep at each other.