4 ms·

Functional programming actually opens up more opportunities for debugging, as we are better able to both reason about and transform programs. The caveat is that

Functional programming actually opens up more opportunities for debugging, as we are better able to both reason about and transform programs. The caveat is that often we need to build domain-specific debuggers, to effectively debug our high-level domain-specific code. Even in imperative languages like C++ and Java, the standard word-at-a-time debugger gets increasingly less useful as abstractions are piled up. Multiple threads really throw a spanner in the works. Here's an example functional debugger that can step forwards and backwards in time, as well as modify code at any time: http://debug.elm-lang.org http://debug.elm-lang.org

seanmcdirmid 9y ago
Backward step debuggers aren’t limited to just functional languages, they’ve been available for imperative languages as well (e.g. via gdb).
- willtim 9y ago
  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
  - 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

Backward step debuggers aren’t limited to just functional languages, they’ve been available for imperative languages as well (e.g. via gdb).

willtim 9y ago
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
- 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.