Yes, that debugger example really confused me and made me wonder why he added it. Anyone who has actually done live-debugging sessions will know that hex is perfectly pronouncible, and furthermore is a direct mapping to binary.
True, even in post-mortem debugging (assuming I have the objects from the heap), it's not like I'm going to exclude the addresses of objects in my write-ups (or as they're exposed via commands, such as !sosex.mdso[0]).
In native, if you're on the stack (e.g.: not using pointers), then addresses don't mean much of anything and if you're using pointers, memory optimisation means the address could mean feck-all after a cycle or two (assuming you've looking at an iDNA/TTT[1]).
So, to agree with you, who are agreeing with me: It is quite odd that this would be a principal argument for proquints.
[0] - https://github.com/lowleveldesign/debug-recipes/blob/master/...
[1] - https://docs.microsoft.com/en-us/windows-hardware/drivers/de...
>Debuggers could input and output memory addresses as proquints as an alternative to hex.
...but why? In debuggers, you're not concerned with memorising the address of an object as much as you are concerned with what the hell is mangling said object. There's no "value-add" for proquints, here. If you were live-debugging in a session with someone else, sure, but how often are you generally doing that?
>Network tools such as browsers, ping, netstat, traceroute, etc. could input and output proquints as an alternative to dotted quads.
Again, what is the value-add? Since I've known 4-octet IP addresses and numbers my whole life, it would take more effort to translate from proquint, to understand the output on the screen. Adding a translation layer in a cut-over fashion instead of a phased-in fashion just seems like wholly unnecessary overhead, only intended to further justify the proquint, yeah?