"..trace logs, a relatively old technique that glorifies printf as First-Class Citizen Of The Testing Guild.." I don't understand the stigma attached to logs a

"..trace logs, a relatively old technique that glorifies printf as First-Class Citizen Of The Testing Guild.." I don't understand the stigma attached to logs and debug-by-print. When is a tool that uses x to provide y 'glorifying' x? I've built and regularly use two tools that rely on logs: a) I write white-box tests that allow me to check not just what a function returns but specific events in the course of the function running: http://akkartik/name/post/tracing-tests http://akkartik/name/post/tracing-tests. This allows me to check, for example, that searching in a sorted array doesn't require double the lookups when the size of the array doubles. It also allows me to test subcomponents without calling them directly, leaving their interfaces underspecified and flexible to change later without needing to modify a bunch of tests. b) I often debug my programs by dumping a trace and running it through a 'trace browser' which starts out showing just the coarsest level and allows me to drill down in specific places as I want. This 'zoomable' google-maps-like UI gives me all the benefits of time-travel debugging at a fraction of the system engineering it usually takes. (I still can't get the feature to work in gdb..) Try it out: $ git clone https://github.com/akkartik/mu $ cd mu $ ./mu browse-trace .traces/factorial-test It'll take ~30s to compile the first time you run it (C compiler required on Linux/OS X). Once it compiles, you'll see an ncurses program. Use 'q' to quit, hit enter to zoom into lines (you can see how many lines are collapsed in parens), backspace to zoom out on a line. These are both things nobody can do on a conventional toolchain, and super easy to build. Maybe print seems trivial because nobody's building tools around it?