"understanding" pshaw

[Raoul Duke]

the same complaints about undebugability of black box neural nets frankly rings true for stuff humans write themselves. eg randomly this printer driver starts forgetting the printer can do color and one has to uninstall reinstall and chant chants to get it working again. wtaf. it is all a freaking joke. 

what would it even mean to say we could ever actually "understand" software??!!!

(hint: entire state space, including all the hardware and its bugs, and all possible interleavings/timings, thermal conditions, cosmic ray bit flips, user inputs, etc.)

[David Barbour]

A big state space can easily hide bugs. Race condition non-determinism easily results in bugs that show up on some machines and not others. Exceptions or failures can easily leave a system in an unpredictable state - i.e. there are often only a few final success states, but the number of failure states is essentially the entire potential set of intermediate states.

Transactional memory would probably help with a lot of these issues. At the very least, we could prevent non-deterministic interference within a transaction, and reduce the number of failure states by simply aborting the transaction on failure. We'd need a more asynchronous API for effects so we can easily 'undo' writes/sends by deferring them until commit.

Additionally, better access to the state would be very useful for exposing or potentially repairing state bugs without a full restart. Instead of hiding state within program loops, closures, and objects, we should be able to inspect state at runtime and create useful debug dashboards for live applications or systems. This suggests an external database for state, separable from the application that manipulates it. The unhosted.org concepts are indirectly related. Separation of state and application would also make it easier to fix application errors without losing useful state.