3 ms·
The article doesn't mention the additional problems with stateful software, which account for a lot of the worst problems in practice. Consider an application
by jeff-davis 5y ago
The article doesn't mention the additional problems with stateful software, which account for a lot of the worst problems in practice.
Consider an application with persistent state. Version 1 has a bug that introduces some slight inconsistency in the state file. Version 7 reads the state file, assumes that the state file is consistent, and ends up producing crazy results. Version 7 is "correct" but still fails.
One answer is to always validate the state file, but that may be impractical due to size or complexity.
A better answer is to use a database that offers declarative constraints that help prevent inconsistencies. This is such a good solution that something written in PHP could be very robust in practice if it uses a good database, whereas something written in haskell that uses a database without good constraints might fail miserably.
- zozbot234 5y agoYou don't need a full database, you just need well-specified serialization/deserialization. Typically this includes explicit versioning mechanisms, so the app can be aware of what version it is dealing with and convert the format accordingly.
- jeff-davis 5y agoser/de only solves parsing problems and not much else. What about using duplicate user IDs? Or maybe many objects in the system need both the employee ID and the name (and the employee ID determines the name, obviously), and the employee changes their name, but it only updates some objects and not all? There are lots of ways data can be subtly inconsistent and a database is a big help preventing it.