> 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.
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.