5 ms·

That's quite a bold promise, when in theory any statement could "launch the missiles". Just like software transactional memory, this idea, AFAICT, really needs

That's quite a bold promise, when in theory any statement could "launch the missiles". Just like software transactional memory, this idea, AFAICT, really needs pure functional programming to work well.

seanmcdirmid 9y ago
No way, I’ve implemented a few of them myself (my research area is in love programming), and none of the languages I’ve done were functional. All you need to do is checkpoint, which is true for non trivial FP programs as well.
- naasking 9y ago
  Checkpointing is more fine-grained and yet, essentially free in pure functional languages though. The tooling has got to be simpler for that reason alone.
  - deleted 9y ago
    [deleted]
  - seanmcdirmid 9y ago
    You should no better than that. It is only free in pure functional languages if they keep every single world around, then the overhead of checkpointing is nil because they are basically doing it already! So choose between "save the world because that's what we already do" or "save the world after the fact," it is pretty much the same.
    - naasking 9y ago
      > You should no better than that. It is only free in pure functional languages if they keep every single world around Which a debugger for a purely functional language would do for you. Which is why I said it would be almost trivial to create this kind of tooling in such a language. > So choose between "save the world because that's what we already do" or "save the world after the fact," it is pretty much the same. Not sure I agree. Save the world after the fact would seem to require much deeper integration with the abstract machine to capture the evaluation context. I was merely pointing out that this integration is shallow in a purely functional language, and such a tool would be easy to create.
      - seanmcdirmid 9y ago
        > Which a debugger for a purely functional language would do for you. Yes, you are already checkpointing if you have such an interpreter, not that I think many programs would actually qualify. > I was merely pointing out that this integration is shallow in a purely functional language, and such a tool would be easy to create. Most production language reverse debugging techniques are similarly shallow because they work mostly at the OS level (GDB), it isn't hard to capture evaluation context when you capture everything. How is reverse debugging working out for Haskell then? I assume, since it is trivial over there, it must be common?
        willtim 9y ago
        > How is reverse debugging working out for Haskell then? The Elm debugger I posted above is a perfect example. Unlike your GDB example, it doesn't only work for a subset of x86 instructions or require monumental effort to implement. It's a high-level domain-specific debugger, that was simple to specify and build. For those of us that want to write high-level code with many layered abstractions, working one-word-at-a-time using GDB is simply not a great way to debug, even if it does now sometimes work backwards. We want to easily build our own debuggers.
FreeFull 9y ago
http://rr-project.org/ http://rr-project.org/ does it by recording the execution. If the bug occurs rarely, you can keep retrying your recordings until you get one that exhibits the bug, and then you can step forwards and backwards through it at your leisure.
jcelerier 9y ago
"and yet, it works"
tathougies 9y ago
They build up a persistent (i.e., functional) structure, under the hood, so that stepping back and forward again doesn't redo the actions.

seanmcdirmid 9y ago

No way, I’ve implemented a few of them myself (my research area is in love programming), and none of the languages I’ve done were functional. All you need to do is checkpoint, which is true for non trivial FP programs as well.

naasking 9y ago
Checkpointing is more fine-grained and yet, essentially free in pure functional languages though. The tooling has got to be simpler for that reason alone.
- deleted 9y ago
  [deleted]
- seanmcdirmid 9y ago
  You should no better than that. It is only free in pure functional languages if they keep every single world around, then the overhead of checkpointing is nil because they are basically doing it already! So choose between "save the world because that's what we already do" or "save the world after the fact," it is pretty much the same.
  - naasking 9y ago
    > You should no better than that. It is only free in pure functional languages if they keep every single world around Which a debugger for a purely functional language would do for you. Which is why I said it would be almost trivial to create this kind of tooling in such a language. > So choose between "save the world because that's what we already do" or "save the world after the fact," it is pretty much the same. Not sure I agree. Save the world after the fact would seem to require much deeper integration with the abstract machine to capture the evaluation context. I was merely pointing out that this integration is shallow in a purely functional language, and such a tool would be easy to create.
    - seanmcdirmid 9y ago
      > Which a debugger for a purely functional language would do for you. Yes, you are already checkpointing if you have such an interpreter, not that I think many programs would actually qualify. > I was merely pointing out that this integration is shallow in a purely functional language, and such a tool would be easy to create. Most production language reverse debugging techniques are similarly shallow because they work mostly at the OS level (GDB), it isn't hard to capture evaluation context when you capture everything. How is reverse debugging working out for Haskell then? I assume, since it is trivial over there, it must be common?
      - willtim 9y ago
        > How is reverse debugging working out for Haskell then? The Elm debugger I posted above is a perfect example. Unlike your GDB example, it doesn't only work for a subset of x86 instructions or require monumental effort to implement. It's a high-level domain-specific debugger, that was simple to specify and build. For those of us that want to write high-level code with many layered abstractions, working one-word-at-a-time using GDB is simply not a great way to debug, even if it does now sometimes work backwards. We want to easily build our own debuggers.

FreeFull 9y ago

http://rr-project.org/ http://rr-project.org/ does it by recording the execution. If the bug occurs rarely, you can keep retrying your recordings until you get one that exhibits the bug, and then you can step forwards and backwards through it at your leisure.

jcelerier 9y ago

"and yet, it works"

tathougies 9y ago

They build up a persistent (i.e., functional) structure, under the hood, so that stepping back and forward again doesn't redo the actions.