I know how to use a debugger, at least how to set a breakpoint and step through stuff. I'm sure there are features I'm not familiar with, but I at least understand the fundamentals.

I think part of it is that for the last 5 years , every single language I've used with any kind of professional capacity (JavaScript, Haskell, Erlang, F#, Clojure, Scheme) has had a REPL, so I can quickly play with and reload code, making debuggers a bit less necessary than if I were to do a purely-compiled language.

I definitely would benefit from learning more about performance profilers though. You've given me an idea of reading material for the weekend.

> I guess I was quite lucky with some of the teachers and professors that crossed my path.

Debuggers aren't exactly self-explanatory so the role of good teachers should not be underestimated

Sorta. I feel I was taught to program by basically being taught how to be my own debugger/stepper. That was literally a term's worth of tests. "Write down the state of the variables in this function when it is called with these inputs." was a common test question.

So, yeah, learning the keyboard shortcuts for how to step through something takes effort. However, it is doing basically what I was taught to reason about programming.

Functional idioms throw a lot of this a giant curve ball. Heaven help the person that was used to stepping through a for loop that steps over a map call. Oops. Worse if it is lazy.

That said, they are not competing ways of thinking. Just different ways. If you are having trouble with one, try the other.

(I do note that the difficulty of working in a debugger is ironically one of the major criticisms of macros in lisps.)

> Turbo Pascal 5.0 Is important to note how MUCH better some debuggers are than others. Pascal was amazing, specially if you compare to C.

Good debuggers:

- Pascal - Delphi - FoxPro /VisualFoxPro (the best of all, IMHO)

Others more common debuggers (Visual Studio, Xcode, IntelliJ, maybe others I don't remember), have issues, like the amazing "feature" of show opaque values, not allow to inspect stuff or requiere extra steps.

But the worse of all? Them are SLOW. Do "step" is slow. Waiting to see if evaluating values? slow.

Python have almost good, but mostly because python allow to see a lot. GDB sucks as is, but python make it look good.

Step being slow? How long you don't use debuggers?

Plus it is not like one needs to single step all the way, there are plenty of ways to control execution flow.

Stepping can be slow if you setup a lot of watches that get evaluated every time

That is what trace points like IntelliTrace are for, no need to single step.

> How long you don't use debuggers?

Like 7h ago?

Then what about learning their advanced features for tracing and scripting instead of always single stepping?

That is a snarky way to answer.

But here, I was talking how other debugger have not the same problems.