Something I have often thought about for years but never implemented was "sound logging" where you get specific points of your code to play audio clips or tones instead of/as well as logging to console etc.
The idea being that you can test the app.and hear the sound logs going off as you go. In a tight loop that executes quickly I would hope that you could hear something "being off" in the same way that a mechanic can hear if an engine is "running rough" etc.
Of course... It might just be a totally inscrutable and useless wall of noise too! Won't know until I try it out
Xcode has this functionality. You can attach a system sound to a breakpoint. I used it exactly once when I was trying to determine if two events always happened in the same order and were always equally spaced in time. It worked well but drives you sort of mad after a while.
One interesting way of using this I've heard of; is attaching it to a `-[UIViewController dealloc]`, and being able to "hear" (or rather notice the lack of sound) retain cycles this way.
Xcode has all sorts of cool stuff you can do with breakpoints, one I used more often than sound is logging a value on a breakpoint and continuing execution.
This was my undergraduate "thesis" project. We built a GDB plugin that would generate a puredata audio structure to help with debugging. Eg. it would play snoring during a sleep() call, each breakpoint could be set to a different frequency, etc. It was actually pretty interesting for multi-threaded code, though pausing to play the audio could change the runtime profile.
I recall seeing the following very neat idea on HackerNews some time ago, but can no longer find it:
The idea, if I remember correctly, was to intercept system calls and play a sound every time one occurred. So you'd get a series of beeps every time the disk was accessed, somewhat similar to the spinning noise from HDDs. It would play a different type of noise every time the network was accessed, memory was allocated or freed, and so on.
They reported that developers got pretty good at diagnosing and debugging their programs, purely from listening to it run.
I had the exact same thought for years but never came around experimenting with it. I also hoped that one could eventually hear that something is off.
I think this can happen by either recognising the "rhythm" in which sounds appear and/or recognising different tones.
As a first step, my idea was to write a logger that plays different beep sounds for different log levels. That way you could mostly identify the “rhythm” because I guess most log messages would have the same severity. However, to a tiny degree also by the pitch of the sound.
Then as a second step I thought of mapping the log message to a scale of sounds by e.g., hashing the message. This obviously would only work if there’s no dynamic content in the message.
A bit late to the party, but I had a similar idea a while back and built a prototype of this here: http://pilliq.com/companion
It's a "runtime" that executes arbitrary JS code while continuously playing a single tone. Every loop iteration increases the tone's frequency, and every recursive function call increases the tone's pitch (when the function returns, the tone's pitch is decreased).
* There are visual markers to show what is currently being executed
* You can increase or decrease the speed of playback
* You write your own code and execute it in the browser.
I included two examples of fibonacci: one that's iterative and one recursive. I think the audio/visual feedback helps you "feel" the difference of why the iterative implementation is faster than the recursive one.
It's a bit of a hack, and you may need to refresh the page after it finishes running through the code once.
It could be useful but it would probably be very annoying and disharmonious unless it's very well designed. Would be cool and potentially very useful if somebody incorporated it in a good way.
The idea being that you can test the app.and hear the sound logs going off as you go. In a tight loop that executes quickly I would hope that you could hear something "being off" in the same way that a mechanic can hear if an engine is "running rough" etc.
Of course... It might just be a totally inscrutable and useless wall of noise too! Won't know until I try it out