> It's high school printf debugging all over again
If your C++ application is even semi complex or uses Qt you are basically in printf land again. I mean sure go ahead use the debugger for stacktraces and such but anything beyond that is finicky.
In 10 years of C++ I have never dropped back to pouring over logs once I have an idea of where the problem is. Drop a code breakpoint, inspect the stack, find the variable that ain't what it's supposed to be. The next step is to watch every change to that variable over its lifetime and figure out what went wrong.
The dumb way to do this is to drop printfs in the code on every state change of that variable. The tooling way is a data breakpoint. If you have a decent test suite for the codebase that can replicate the fault, the data breakpoint is IMHO always faster.
If you can't replicate the fault, you're going to need logging. So logging isn't obsolete in all cases, but with Haskell (at least in my experience) the excessive logging approach is your only option really.
With time travel debugging, data breakpoints become even more useful, because you can backtrack to the root cause once you've recorded the fault (rather than needing to run forwards and hope to replicate a corruption at the same location as last time).
I'm not quite sure what a meaningful functional equivalent would be given, semantically, no state is actually mutable in Haskell - but "where did this value come from?" still ought to be useful.
> If your C++ application is even semi complex or uses Qt you are basically in printf land again. I mean sure go ahead use the debugger for stacktraces and such but anything beyond that is finicky.
UDB, the time travel debugger I work on, supports C++ via GDB and there seem to be certain things that make life really awkward.
One of my team has been looking into the combination of GCC's debug info and and GDB's behaviour around inline frames. There are a number of quirky things we see there, which boil down to "inline functions make the debug experience go wild".
My understanding is that GCC isn't providing as helpful debug info as we'd like but GDB also isn't handling it in the best way. There are corner cases that can be very confusing from a user's PoV.
Even in C, this is quite visible. In C++, where inlining matters even more, we'd expect it to be exaggerated further.
I'd be really interested to know what things you find finicky (and are you even Linux / GCC / GDB, or is this a wider problem?)
If your C++ application is even semi complex or uses Qt you are basically in printf land again. I mean sure go ahead use the debugger for stacktraces and such but anything beyond that is finicky.