Thanks for reading the paper, the publish date is October 2014, I'll present it at onward! next month. It's a lot too go through so Ill need to pick through this more carefully. But the feedback is most definitely useful.
Haskell is data race free because they just avoid state. If shared state is involved, it has the same problems and needs to deal (e.g. Via STM). Glitch also gives you far more guarantees than data race freedom (consistency being the buggy).
(3) depends on the technique. There are bondage approaches, but there are approaches that allow more flexibility. Glitch is in between that.
Transactions have no notion of replay: the transaction fails and then what? Also, transactions are atomic, whereas tasks in Glitch are continuous: if something changes over time, a task will be replayed..a transaction has already been done and you have to manage change very time your self. This same replay mechanism also washes out data races.
Glitch doesn't suffer livelock problems because effects are not undone until "after" a replay (removing effects that haven't redone) whereas transaction just undo everything when they fail. This is a huge difference in terms of making progress! Glitch is not coming from the database field, but rather from general programming semantics where effect ordering requirements are quite common.
The problem with optimal orders is that you don't know what they are usually appriori. Many systems, like flapjax, require optimal orders because execution is not idempotent. Rather than make that requirement, we instead make execution virtually idempotent through logs. We "could" execute in a more intelligent order as an optimization, but it's not required (I've indeed found some tuning in scheduling necessary for performance).
The past is only remembered as long as it's needed for computing a consistent view; it can be thrown away after. You could also remember the last to do Bret victor style debugging, which is why the feature mostly exists (we could just make sure everything was consistent before processing the next event otherwise), or for distributed processing where computers might proceed at different paces (and therefore will have to agree in a baseline time where none has a task to replay that could change state before it). This is all quite standard in virtual time systems.
Pardoxes will cause continuous replay, like writing x = !x, it has no consistent interpretation. It doesn't freeze up the system, you can always change the statement to fix the problem (the UI remains responsive).
Comments
Thanks for reading the paper, the publish date is October 2014, I'll present it at onward! next month. It's a lot too go through so Ill need to pick through this more carefully. But the feedback is most definitely useful.
Haskell is data race free because they just avoid state. If shared state is involved, it has the same problems and needs to deal (e.g. Via STM). Glitch also gives you far more guarantees than data race freedom (consistency being the buggy).
(3) depends on the technique. There are bondage approaches, but there are approaches that allow more flexibility. Glitch is in between that.
Transactions have no notion of replay: the transaction fails and then what? Also, transactions are atomic, whereas tasks in Glitch are continuous: if something changes over time, a task will be replayed..a transaction has already been done and you have to manage change very time your self. This same replay mechanism also washes out data races.
Glitch doesn't suffer livelock problems because effects are not undone until "after" a replay (removing effects that haven't redone) whereas transaction just undo everything when they fail. This is a huge difference in terms of making progress! Glitch is not coming from the database field, but rather from general programming semantics where effect ordering requirements are quite common.
The problem with optimal orders is that you don't know what they are usually appriori. Many systems, like flapjax, require optimal orders because execution is not idempotent. Rather than make that requirement, we instead make execution virtually idempotent through logs. We "could" execute in a more intelligent order as an optimization, but it's not required (I've indeed found some tuning in scheduling necessary for performance).
The past is only remembered as long as it's needed for computing a consistent view; it can be thrown away after. You could also remember the last to do Bret victor style debugging, which is why the feature mostly exists (we could just make sure everything was consistent before processing the next event otherwise), or for distributed processing where computers might proceed at different paces (and therefore will have to agree in a baseline time where none has a task to replay that could change state before it). This is all quite standard in virtual time systems.
Pardoxes will cause continuous replay, like writing x = !x, it has no consistent interpretation. It doesn't freeze up the system, you can always change the statement to fix the problem (the UI remains responsive).