So, (and I'm in 14.1), why have the Evaluate->Debugger menu item at all if it's not going to be documented and taught? What am I missing?

I find John's illustrative example and Szabolcs' tip to be instructive and perhaps enough to get me over the hurdle of trying to use the debugger instead of the expedient use of Print[].

I believe that learning the debugger is a case in which "watching an example" may be better than "reading the doc".

A 5-10 minute screencast of the debugger in action would likely benefit many users. I hope that someone who uses the debugger frequently might contribute one...

The debugger in the front end does work. Yes, there are caveats...mostly that the interface is clunky to use. And it should absolutely never, ever used in an attempt to debug generated interfaces (which can compete with the debugger for the kernel's attention, thereby hanging the kernel). But it does work.

Rule #1: The debugger only "knows" about stuff that you evaluated while the debugger was turned on. If you want to walk into a function, you can only do so if that function definition was evaluated while the Evaluation->Debugger option was checked.

Rule #2: The debugger can only walk into code which was evaluated from an open notebook window. So, if you have code in a package, you can open it in the FE and click "Run Package", and so long as that window remains open, you should be able to walk into code in that package. But if you run Get[] on the file instead, the debugger will not be able to help you.

A simple example:

• Turn the debugger on.
• Paste the following code: Module[{x = {"Hello", "World"}}, StringJoin[Riffle[x, " "]]]
• Highlight the Riffle expression, and set a breakpoint using Evaluation->Debugger Controls->Toggle Breakpoint
• Run. Use the debugger window to open the Stack and Breakpoints windows if they're not already open, and experiment.

Using message breakpoints (controlled from the breakpoints window) can be very useful to track down a message from an unknown source.

I'm not personally a Workbench user, but I do believe that some use it for this purpose.

But most of the time, the code in the interface splits cleanly into code that's managing the interface, and code that's taking inputs from the interface and doing work. The code that's managing the interface doesn't, in my experience, really require much in the way of debugging...the entire experience is already very usefully visual, with hints such as the pink boxes to help you when something is throwing error states internally. As for the remainder of the code, I'm always testing/debugging it outside of the interface first.

I.e., if I'm writing a significant body of code that's going to live inside of a Dynamic, then I'm debugging/testing it outside of the Dynamic first, and I'm writing it in such a way to make that very easy to do. For example, I often see bug reports or complaints that such-and-such doesn't work in a Manipulate. The very first thing I do is to strip the Manipulate off, and see if it works without the Manipulate. And you know what? About 90% of the time, that's where I find the problem.

This leaves one legitimate area of development not very well covered, though, and that's highly responsive UIs. I.e., UIs that shift and change in significant ways in response to how you use them. Perhaps you might find Workbench useful in such areas. I find other means (a combination of LinkSnooper, Assert, various forms of printing/logging, etc.).

Thanks for pointing this out. I completely missed it.

I'll check it out. While it looks to be a bit spare compared to other modern debuggers, it should meet a need.

It might be nice if Wolfram Research provided a seminar about this, and other more advanced functions for programmers.

You get quite far with Print and Dialog[] statements put into your code.

You could also try this code. Workbench is free if you have Premier Service.

You could also try to use the excellent IntelliJ plugin

But yes, a true debugger and profiler, usable from with the Front End, would be most welcomed. Too bad Wolfram Research seems to be not so much developer oriented anymore as it once was.