Fair enough, but attaching multiple debuggers across several interacting components with conditional breaks gets me there faster than incrementally inserting progressively more print statements, in a dev environment. Proper logging is a given doping out problems in a production system to then verify and correct in dev.

Sometimes having a debugger on prod is the right answer.

"The Remote Agent software, running on a custom port of Harlequin Common Lisp, flew aboard Deep Space 1 (DS1), the first mission of NASA's New Millennium program. Remote Agent controlled DS1 for two days in May of 1999. During that time we were able to debug and fix a race condition that had not shown up during ground testing. (Debugging a program running on a $100M piece of hardware that is 100 million miles away is an interesting experience. Having a read-eval-print loop running on the spacecraft proved invaluable in finding and fixing the problem. The story of the Remote Agent bug is an interesting one in and of itself.)

"The Remote Agent was subsequently named "NASA Software of the Year"."

http://www.flownet.com/gat/jpl-lisp.html

http://ti.arc.nasa.gov/m/pub-archive/176h/0176 (Havelund).pdf

No one said otherwise, and the comment you replied to specifies "in a dev environment". The language you are using is unnecessarily combative: this is likely to inhibit the adoption of your ideas.

Only with python. With LISP it's the common case to debug prod.

I would rather argue that such incompetent managers who speak such nonsense need to be fired.

Smalltalk folks will debug in production too. Although to be fair, Smalltalk folks will write whole programs in debug in development.

Sure. Arguably Smalltalk is a LISP, just with non-Lisp syntax. It actually was prototyped in lisp first.

Agreed, great logs are great.

My comment explicitly stated dev environment, not prod, for debugger usage.

There is much more to logging than print statements. I have yet to run into production code which uses vanilla stdout print statements for logging.