4 ms·

I have to admit, although I use domain specific debuggers sometimes (gdb, debuggers of IDEs), I mostly debug via print-statements, as it just works in most scen

I have to admit, although I use domain specific debuggers sometimes (gdb, debuggers of IDEs), I mostly debug via print-statements, as it just works in most scenarios. Am I missing out? AFAIK step-back debuggers are still more research (I think Elm has something like this), but otherwise I just want to have system snapshots and there print($foobar) works very well for me across languages.

ves 9y ago
Elm used to have a crazy time-traveling debugger in elm-reactor[0], but that's been replaced by session-event-export[1]. This is really, really easy to do well when every function is pure and every data structure is immutable, and you use an MVC/Event-sourced/FRP architecture for (more-or-less) all control flow. Of course, Elm enforces all of these things. I've written / worked on other systems (e.g. accounting / transaction pipelines) in other, less safe languages and implementing a shoddy version of this is really straightforward and immensely useful. That said, with pure functions and immutable data structures, you don't really need a debugger for the same reasons, or indeed nearly as often, as in less safe languages. [0]: http://debug.elm-lang.org/ http://debug.elm-lang.org/ [1]: http://elm-lang.org/blog/the-perfect-bug-report http://elm-lang.org/blog/the-perfect-bug-report
justinclift 9y ago
Yeah, you're missing out. :) Print statement style debugging can (with effort) get a lot of stuff figured out. But :), it's often fairly slow to go through that iteration cycle with non-trivial bugs, compared to using a debugger. With a debugger, you start from the same place in your code you'd put your print statements. But instead of modifying the code to spit out values, the debugger will pass control of the running program to you. You can then go forwards through your program, seeing how the variable values change, which branches are taken, etc. It'll get you to the same end result as the print statements, but faster. Also, for complicated/hairy/weird bugs, being able to follow the actual execution can be enlightening which print statements don't really do.
- zeptomu 9y ago
  :) Some time ago I did more Java and used Eclipse heavily and its debugger was really nice, so I share your opinion that you get nice features. However if you are working on a project (at least that has been my experience so far) that does a lot of multiprocessing (let's say a web service with a processing scheduler in the background calling into processes implemented by different languages) and you may have bugs on several layers using different programming languages, I like the fact that I can use the same concept for all of them and write some custom "debug.log" that I can later analyze (obviously good logging in the first place can help a lot). But I may check them again: Do modern debuggers work across languages (assuming available source), let's say web-request -> Python -> FFI -> C++? Previously such scenarios have been non-trivial to debug (although there are some pretty advanced multithreaded code analyzers now), but maybe it has changed for the better.
  - justinclift 9y ago
    > But I may check them again: Do modern debuggers work across languages (assuming available source), let's say web-request -> Python -> FFI -> C++? Gah... no idea. I'm still doing mostly doing single language stuff. :D The kind of request path you're mentioning there... yeah, I'd probably go back to using print statements too, as I'd have no idea how to hand off from one language to another in some kind of meta-language-debugger. Which would actually be nifty if it exists.
  - pjmlp 9y ago
    They do for Java-> C++, .NET -> C++ and Swift->Objective-C->C++.

ves 9y ago

Elm used to have a crazy time-traveling debugger in elm-reactor[0], but that's been replaced by session-event-export[1]. This is really, really easy to do well when every function is pure and every data structure is immutable, and you use an MVC/Event-sourced/FRP architecture for (more-or-less) all control flow. Of course, Elm enforces all of these things. I've written / worked on other systems (e.g. accounting / transaction pipelines) in other, less safe languages and implementing a shoddy version of this is really straightforward and immensely useful. That said, with pure functions and immutable data structures, you don't really need a debugger for the same reasons, or indeed nearly as often, as in less safe languages. [0]: http://debug.elm-lang.org/ http://debug.elm-lang.org/ [1]: http://elm-lang.org/blog/the-perfect-bug-report http://elm-lang.org/blog/the-perfect-bug-report

justinclift 9y ago

Yeah, you're missing out. :) Print statement style debugging can (with effort) get a lot of stuff figured out. But :), it's often fairly slow to go through that iteration cycle with non-trivial bugs, compared to using a debugger. With a debugger, you start from the same place in your code you'd put your print statements. But instead of modifying the code to spit out values, the debugger will pass control of the running program to you. You can then go forwards through your program, seeing how the variable values change, which branches are taken, etc. It'll get you to the same end result as the print statements, but faster. Also, for complicated/hairy/weird bugs, being able to follow the actual execution can be enlightening which print statements don't really do.

zeptomu 9y ago
:) Some time ago I did more Java and used Eclipse heavily and its debugger was really nice, so I share your opinion that you get nice features. However if you are working on a project (at least that has been my experience so far) that does a lot of multiprocessing (let's say a web service with a processing scheduler in the background calling into processes implemented by different languages) and you may have bugs on several layers using different programming languages, I like the fact that I can use the same concept for all of them and write some custom "debug.log" that I can later analyze (obviously good logging in the first place can help a lot). But I may check them again: Do modern debuggers work across languages (assuming available source), let's say web-request -> Python -> FFI -> C++? Previously such scenarios have been non-trivial to debug (although there are some pretty advanced multithreaded code analyzers now), but maybe it has changed for the better.
- justinclift 9y ago
  > But I may check them again: Do modern debuggers work across languages (assuming available source), let's say web-request -> Python -> FFI -> C++? Gah... no idea. I'm still doing mostly doing single language stuff. :D The kind of request path you're mentioning there... yeah, I'd probably go back to using print statements too, as I'd have no idea how to hand off from one language to another in some kind of meta-language-debugger. Which would actually be nifty if it exists.
- pjmlp 9y ago
  They do for Java-> C++, .NET -> C++ and Swift->Objective-C->C++.