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 have Workbench but have never used its debugging facilities. The one thing I learned from Workbench, using the Workbench editor, is that I tend to have many routines built on Modules that contain local variables that are never used! Of course, they were once used, or intended to be used. I found the same thing looking at another person's extensive code.

The way I develop is to write and evaluate a routine incrementally looking at intermediate output to make certain it's what I was expecting. I also use Print statements, which I later comment out or delete. This always seems to solve any problems.

I also don't think of Mathematica so much as a programming language or what I do as programming. I think of it more as writing definitions of mathematical objects or actions and writing specifications for graphics and dynamic displays. It is the displays that usually involve the longest code. But again incremental development with evaluation and an occasional Print statement always does the job. I don't think I ever have a routine that goes over one screen. These are not toy applications. They do quite a lot, principally because the Mathematica routines, especially the procedural constructs, do quite a lot.

I thought the more advanced debuggers were for large projects involving lower level code such as C++. It would be interesting to know what kind of project you are undertaking that can't be broken into smaller individually developed and tested routines. What is missing might not be as incrementally useful as you envision.

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.