Well yes, but I must quibble...

> Print debugging.... It works on any system

No it does not. It requires a console, and not all systems have a console.

It requires a way to get bytes out of the system. You can connect an external console to that.

Well, you're right, of course. Another obvious one is that print debugging doesn't work for your GPU kernels.

Well, not every system has a framebuffer, but here's a Carmack tweet that comes to mind:

"gl_FragColor.x = 1.0; is the printf of graphics debugging. Stone knives and bearskins."

— https://mobile.twitter.com/id_aa_carmack/status/568861553245...

He also seems to like a timing/GPU/CPU debugger called PIX from MS, I'm impressed. I wish they had started with the hands on, but the presenters in this video[0] all show why print debug will never be enough. Getting back to the OP, for me even IDE integrated debugging is worse than print debugs. You need to so much data to make it useful for me, which makes things like PIX, APM and other application tracers the thing I go for during debug.

[0] https://www.youtube.com/watch?v=UH-o5cG_QWo

As a side note: While using wgpu-rs to do Rust game development, I grew very fond of RenderDoc (https://renderdoc.org/).

It has great Vulkan compatibility and it helped me greatly when building an object picking buffer by visualising everything from call trees to resource contents and metadata. I believe it should come in handy for any GPU-based project, not just 3D/2D graphics.

Which is why a GPU debugger with frame tracing is so much better option.

By the way, there are actually ways to expose a print function on shader code, provided there is driver support.

https://github.com/KhronosGroup/Vulkan-ValidationLayers/blob...

Any system that is capable of emitting any data, can emit bytes from print debugging. Could be log file, socket, or even pulses along a GPIO pin.

If the system can't emit any data, well, you're kind of stuck anyway.

> If the system can't emit any data, well, you're kind of stuck anyway.

It's also by all recognition, functioning perfectly :)

Having worked in embedded, debugging through an Oscilloscope is a cherished memory that I sometimes talk to junior colleagues about. Knowing these things are possible can sometimes help people find more novel ways to think about debugging their applications.

Pulses on a GPIO pin are not print statements.

A huge proportion of computing devices have no method of producing any out put, other than to some form of actuator, at all.

"print statements" are useless in this class of device.

Stretching the definition of "print statement" to recording pulses from a pin is, well, a stretch!

Poor young programmers. If the only tool you have is a hemmer, every problem is a thumb.

> Pulses on a GPIO pin are not print statements.

Yes, they are. How do you think text terminals work?

Really? You are being disingenuous.

It is a long way from "pulses on GPIO pins" to a print statement.

It's precisely one text terminal or LED scroller away.

> It's precisely one text terminal or LED scroller away.

This is quite strange. Let us remember the context

> Print debugging is a technique that will never go out of style. It works on any system,

So you are suggesting that watching the blinking of a GPIO pin (I hope you have an oscilloscope, or some other probe, rather than applying to to your tongue) is the same as "Print debugging"?

I contend that in any sensible use of technical English "print debugging" is text output to a console.

In that context there are a lot of systems, possibly most computer systems, do not have access to that. It is not unusual for developers to go to elaborate lengths to attach consoles to these systems - not the same as " It works on any system, "

If you added code to tickle the GPIO specifically to gain insight into the process, whether you leave it in or not, then it’s “print debugging”. Many a microcontroller developer has tickled an indicator LED in their day.

If your simply monitoring activity through an external source (whether it’s an oscilloscope or watching traffic through a network analyzer) then that’s basically black box testing.

> A huge proportion of computing devices have no method of producing any out put, other than to some form of actuator, at all.

Actuators work too. It's not unheard of in robotics to debug by adding statements that make some actuator do specific movements that communicate the information you want to surface.

Anything you can use to output nonzero amount of bits to the environment can work for print debugging.

Unless you're debugging something so simple that it can only flash a led, you can have a serial console onto it

You can print debug on an Arduino for example

So, yes, it works on pretty much any system.

Even then, you could write a print function that writes morse code pattern to the led :p

> Even then, you could write a print function that writes morse code pattern to the led :p

And you then have a different system.

My point is consoles are not ubiquitous in computing. Computer systems that lack them are very common

Do you have an example of one that doesn't have one?

This is in the realm of ignorant questions. It could well be that the majority of computer devices have none. E.g. the micro controller in my washing machine

Why is it an ignorant question? The nicer ones let you use JTAG etc connections, and debug to console using ITM or RTT. (STM, nRF etc) Others allow debugging via serial.

> Why is it an ignorant question? The nicer ones let you use JTAG etc connections, and debug to console using ITM or RTT. (STM, nRF etc) Others allow debugging via serial.

Because all those systems, even the very nicest, all over the palnet, very really have "JTAG etc connections,"

Those are things you attached to the system. You attach them in a complex error prone process, at the end of it you have a different system.

A lot of (most?) computers do not have consoles.

It is a common error amongst developers (who do not work in embedded systems) to assume there is a screen supporting text of some sort. It is an error

You connect the debug probe to your MCU (pogo pins or w/e is convenient for the form factor), connect it to a PC over USB, and print to a terminal window in Windows, Linux etc. Or a serial-USB bridge if it doesn't support debug probes. If the MCU is so basic it doesn't support UART, bit-bang it with GPIO. Too easy!

> Print debugging is a technique that will never go out of style. It works on any system,

So if you connect up a bunch of wires and everything goes well "too easy" you can get output from some, not all, systems.

What you describe is no what the comment about "print debugging" means, to me.

You'd be hard pressed to find any. You can even get console over JTAG/SWD and near every microcontroller has it.

Only when you get into realm of few cents per microcontroller then you don't have it

> No it does not. It requires a console, and not all systems have a console.

It does not. You just send the log output somewhere (often a different system). If you have a deployment with no logging infrastructure (either local for smaller setups or distributed for large scale), you have a major problem beyond just debugging visibility.

> You just send the log output somewhere

How?

Via network socket, serial port, parallel port, however the system in question communicates with the world.

If it's an actual standalone deaf, dumb, and blind black box with zero world interaction then you should, at least, have a hardware probe and step debugging capabilities and you can always flash a sign of some kind on some bus or another.

I view it as "tracer bullets." I know it will make noise, but I'm planning to look at the pattern of the noise to see what I can reason out of it.

Is it a complete answer? Of course not. Neither is trying to spin a wheel that you are truing. Produces a ton of output that is roughly in an expected pattern, and can be acted on.

Logging - for debugging or for other purposes - is a very useful tool.

As a general rule I prefer print debugging. I’ll step in with a breakpoint when I have to but odds are I’ve gone through a round of prints first.

I do not enjoy stepping through all of the context setting up the system to fail. I’ve not tried a debugger that can “back up”, that may well be a different experience. But I loathe stepping through code, walking on eggs, overstepping, “oops, thar she blows, start over”. Like Bugs Bunny on the piana.

Rather just toss in some prints, let fly, sift through the wreckage. My builds are fast enough to make the turn around acceptable.