> Visual Studio allows similar capabilities for C++ via data visualizers.
No reason this couldn't be possible for Emacs, I guess nobody bothered. In particular, Common Lisp with SLIME already makes use of "presentations" in REPL, which nicely combine CL's print-object output with inspector/debugger capabilities.
Ultimately, no one limits you to printing out simple text. In various Lisp software I wrote, I ended up displaying profiling info inline in REPL, like this:
(EDIT: there were pretty Unicode characters in that output, but my browser / HN ate them. See https://github.com/tkych/cl-spark for how it should look like.)
(all it took was a simple macro on top of a sparkline lib). I dumped custom execution stats out-of-band into a HTML file that, with little bit of static JS, rendered explorable charts. I've sent data straight into new Emacs buffers for processing, with a help of this simple macro:
(can be trivially modified to make the new buffer automatically assume a given major-mode).
Point is, you don't have to limit yourself to simple, uninterpreted printfs. Write your own debugging tools! And while I'm not up to date with C#, most other languages and IDEs I've seen don't move beyond dumb printfs. Java definitely doesn't (hint: Grep Console is a very useful plugin to IntelliJ and Eclipse). And this Console.table() is just a visual gimmick. I'm actually disappointed that with all the capabilities for interactive HTML rendering, that's the best the Web standardized on so far.
When I think about Common Lisp debugging capabilities usually what comes to my mind is Allegro, Lisp Works, MCL, CCL, not SLIME in text mode single window.
Sure, but a lot of CL development these days is done with SBCL and SLIME - Allegro and LispWorks are expensive, and whatever cool stuff CCL has would require me to buy a Mac.
No reason this couldn't be possible for Emacs, I guess nobody bothered. In particular, Common Lisp with SLIME already makes use of "presentations" in REPL, which nicely combine CL's print-object output with inspector/debugger capabilities.
Ultimately, no one limits you to printing out simple text. In various Lisp software I wrote, I ended up displaying profiling info inline in REPL, like this:
(EDIT: there were pretty Unicode characters in that output, but my browser / HN ate them. See https://github.com/tkych/cl-spark for how it should look like.)(all it took was a simple macro on top of a sparkline lib). I dumped custom execution stats out-of-band into a HTML file that, with little bit of static JS, rendered explorable charts. I've sent data straight into new Emacs buffers for processing, with a help of this simple macro:
https://gist.github.com/TeMPOraL/8715c9dd9837e0b601d1cdce059...
(can be trivially modified to make the new buffer automatically assume a given major-mode).
Point is, you don't have to limit yourself to simple, uninterpreted printfs. Write your own debugging tools! And while I'm not up to date with C#, most other languages and IDEs I've seen don't move beyond dumb printfs. Java definitely doesn't (hint: Grep Console is a very useful plugin to IntelliJ and Eclipse). And this Console.table() is just a visual gimmick. I'm actually disappointed that with all the capabilities for interactive HTML rendering, that's the best the Web standardized on so far.