4 ms·

Bug-free software, possible?

2 points by ideas101 18y ago

pg 18y ago
You can certainly approach it. The problem is, you can't tell for sure when you're there, unless a program has so few execution paths that you can check them by enumeration the way you'd check a proof.
- ivankirigin 18y ago
  Are you familiar with techniques used in avionics software? The methods just ooze with pain for the developer. Examples include no dynamic memory allocation and always running network operations at full tilt so there is no notion of average & peak network usage. For the latter, let's say you want to make a messaging system where module 1 periodically sends a message to module 2. Rather than just sending a message when it is needed, you determine the maximum frequency you want to send a message, and send the latest message again and again. More deterministic, more verifiable correct, but 100% pain.
silentbicycle 18y ago
I don't have high hopes about the possibility of perfectly bug-free software. To be bug-free from an end-user's standpoint, it seems like such a thing would need to be completely free of errors at every level, from specification (understanding precisely what the program is supposed to do, whether in terms of problem domain or customers' requests) to implementation (the bug-free program itself) to the supporting system and hardware (an otherwise perfect program could still fail due to a bug in a floating point processor, for example). Each layer presents its own problems, many of which are far from trivial. Perhaps a more useful way to frame the question is to ask what approaches could better rule out different kinds of bugs. For example, the strong type system in ML languages (e.g. OCaml) is great for preventing bugs with extensive compile-time analysis (in part due to being derived from a theorem prover), but there is certainly room for improvement. Likewise, well-designed garbage collectors can rule out many kinds of memory leaks.

4 ms·

Bug-free software, possible?

2 points by ideas101 18y ago

pg 18y ago
You can certainly approach it. The problem is, you can't tell for sure when you're there, unless a program has so few execution paths that you can check them by enumeration the way you'd check a proof.
- ivankirigin 18y ago
  Are you familiar with techniques used in avionics software? The methods just ooze with pain for the developer. Examples include no dynamic memory allocation and always running network operations at full tilt so there is no notion of average & peak network usage. For the latter, let's say you want to make a messaging system where module 1 periodically sends a message to module 2. Rather than just sending a message when it is needed, you determine the maximum frequency you want to send a message, and send the latest message again and again. More deterministic, more verifiable correct, but 100% pain.
silentbicycle 18y ago
I don't have high hopes about the possibility of perfectly bug-free software. To be bug-free from an end-user's standpoint, it seems like such a thing would need to be completely free of errors at every level, from specification (understanding precisely what the program is supposed to do, whether in terms of problem domain or customers' requests) to implementation (the bug-free program itself) to the supporting system and hardware (an otherwise perfect program could still fail due to a bug in a floating point processor, for example). Each layer presents its own problems, many of which are far from trivial. Perhaps a more useful way to frame the question is to ask what approaches could better rule out different kinds of bugs. For example, the strong type system in ML languages (e.g. OCaml) is great for preventing bugs with extensive compile-time analysis (in part due to being derived from a theorem prover), but there is certainly room for improvement. Likewise, well-designed garbage collectors can rule out many kinds of memory leaks.