The visualisations I’m talking about are mostly debugger tools. The parallel stacks view is life saving when you’re trying to figure out a deadlock. Having to scroll around this huge viewport with a cursor would just piss me off. I just can’t see how you could navigate a huge (10x screen width) node graph in a text terminal using vim style commands.
I had a look at parallel stacks and it looks nice and seems quite helpful. But I have to think, if you have that many threads that might deadlock and it happens often, if your architecture might be the issue.
Most of our parallelism is job based. There is a job queue and worker threads are taking jobs from it. So deadlocks are pretty much a non issue for us.
I‘m not trying to say that everything you‘re doing is obviously wrong, but the older I get the more suspicious I‘m getting if there‘s a need for „fancy“ debugging tools, because it might mask that there are some more serious issues in the application.
For a game or similar code that's sometimes too much RAM, and usually too much latency.
I'm working with vim on a ~5 million line C++ code base. Thanks to rtags[1] I've all I need: auto completion, goto definition, even semantically correct renaming or finding all locations in code calling a certain function.
I'm certainly not saying that it's as polished as 'Visual Studio', but it works pretty well.
If tooling isn't baked into an IDE - which unfortunately is often the case - then pretty much every editor with some kind of extension mechanism can take advantage of it.
> Maybe it's just because this is what I'm used to, however I just don't see how some of the tools would even be displayed in a terminal (parallel stacks window, for example) without some horrible ascii node graph.
Yes, most visualization are text based. E.g. for showing the references for a function rtags uses the Quickfix-window of vim, which pretty much is just a list with one entry for every reference. I can now jump to every occurence in the list or even execute an operation on every reference, like I've removed the last parameter of the function call, and now I'm defining a vim substitution command for removing the last parameter and execute it on very item of the Quickfix-window.
Sometimes visualizations are certainly helpful, but I never found them particular useful for software, because the more complex an application gets, the less useful the visualizations become. At some point you're less interested on the class level and more on the system level, but tools can't that easily detect what are the systems in an application.
[1] https://github.com/Andersbakken/rtags