3 ms·

Being able to build multiple different forms of debug inspector that you can use as preferred is a huge feature to me, and trying to provide building blocks so

by mst 2y ago

Being able to build multiple different forms of debug inspector that you can use as preferred is a huge feature to me, and trying to provide building blocks so you can build them faster strikes me as an excellent idea. (I recall once talking to a java dev who considered perl a complete disaster for debugging because ... whatever tool he'd picked to help him produced debug output that suited neither the codebase nor his brain, and the java code he was working with at least managed representations that suited the codebase ... meanwhile, I often get frustrated at how tricky I found it to convince java to let me have multiple different debug stringifications ... such is life ;)

whartung 2y ago
This just talks to the heritage of Lisp. There are certainly other interactive languages, there are other interactive object oriented languages, but few rose to the level of Lisp when it became not just the systems programming language of specialized operating systems, but also the command shell and development tool for such systems. It was also during a time where keyboard interaction was still the primary means of interface. Even with the creation of the Lisp machines and their large graphic displays, those displays were dominated by "terminal" windows. Java has "toString". But Java has no heritage of interacting with it via a terminal interface. In the modern world of graphic displays, windowed environments, and IDEs, those larger tools expose the objects of the JVM (which are made quite transparent by the debugger infrastructure). Outside of "toString", there's not much call for language level specialized handling. IDEs did all of the heavy lifting. I, too, have done things like "toDebugString" or something equivalent, that I could put in a watch expression in the debugger. And, that was "enough". In Lisp, Lisp was "the tool", it was "the debugger", there wasn't really a separate artifact peering into the image. So, it required the ability to do all of that in and of itself. A few years later, and Lisp likely would not have done this. Even Smalltalk doesn't do this. Its inspector is a generic tool. But ST was mostly a GUI based system. And, sure, you can just override STs inspect method. I'm guessing most don't.
- lispm 2y ago
  > It was also during a time where keyboard interaction was still the primary means of interface. Even with the creation of the Lisp machines and their large graphic displays, those displays were dominated by "terminal" windows. In Symbolics Genera a Lisp Listener (the window which runs a combination of a REPL and a command line interpreter) is a full graphics window with the same drawing capabilities as PostScript. It's also a command interpreter taking Lisp objects as arguments to commands. The UI isn't using much direct manipulation with the mouse (like dragging a file between folder windows), though for example in the graphics editor one can do that for graphics objects. One also interacts with graphical scrollbars. Much of the UI is based on displaying textual and/or graphical objects AND running commands on them. Application windows all have a (often visible) command interpreter, where interacting with objects is done via commands on objects (and not only on text), using textual commands, mouse gestures or command menus. The Listener (as do other applications) also records all output and keeps the relationship with the objects which a drawn/printed. Thus the Genera UI does not use "toString", but calls PRESENT (or similar), a function which outputs Lisp objects in various ways, records the output (text and graphics) and keeps the relationship between object and output. Thus the Listener is not only a graphical stream, but also a graphical object store (-> it stores all output using a complex object-oriented framework). (similar -> McCLIM -> https://mcclim.common-lisp.dev https://mcclim.common-lisp.dev -> example for tools/apps https://mcclim.common-lisp.dev/excite.html https://mcclim.common-lisp.dev/excite.html ). One can return/print a data structure in the Listener and then one can point with the mouse at sub-objects and run commands on them (like 'describe'). This makes a separate inspector mostly unnecessary, though there is a inspector window. As there is a debugger window with backtrace, code display, etc. There is also a PEEK window, which is used to inspect things in the OS: Windows, File Systems, Memory, Processes, Network, ...
- mst 2y ago
  The Glamorous Toolkit crew have been doing some amazing stuff in terms of having multiple heavily custom type-specialised inspectors, and while being ST based they're much more GUI focused than REPL focused I think it's not unreasonable to say it's the same spirit, but ST style rather than Lisp style. (for those following along at home, Interlisp was a work of art and I cached a couple of the relevant manuals under https://trout.me.uk/lisp/ https://trout.me.uk/lisp/ so I didn't keep having to go find them yet again to re-read for inspiration)

by mst 2y ago

whartung 2y ago

This just talks to the heritage of Lisp. There are certainly other interactive languages, there are other interactive object oriented languages, but few rose to the level of Lisp when it became not just the systems programming language of specialized operating systems, but also the command shell and development tool for such systems. It was also during a time where keyboard interaction was still the primary means of interface. Even with the creation of the Lisp machines and their large graphic displays, those displays were dominated by "terminal" windows. Java has "toString". But Java has no heritage of interacting with it via a terminal interface. In the modern world of graphic displays, windowed environments, and IDEs, those larger tools expose the objects of the JVM (which are made quite transparent by the debugger infrastructure). Outside of "toString", there's not much call for language level specialized handling. IDEs did all of the heavy lifting. I, too, have done things like "toDebugString" or something equivalent, that I could put in a watch expression in the debugger. And, that was "enough". In Lisp, Lisp was "the tool", it was "the debugger", there wasn't really a separate artifact peering into the image. So, it required the ability to do all of that in and of itself. A few years later, and Lisp likely would not have done this. Even Smalltalk doesn't do this. Its inspector is a generic tool. But ST was mostly a GUI based system. And, sure, you can just override STs inspect method. I'm guessing most don't.

lispm 2y ago
> It was also during a time where keyboard interaction was still the primary means of interface. Even with the creation of the Lisp machines and their large graphic displays, those displays were dominated by "terminal" windows. In Symbolics Genera a Lisp Listener (the window which runs a combination of a REPL and a command line interpreter) is a full graphics window with the same drawing capabilities as PostScript. It's also a command interpreter taking Lisp objects as arguments to commands. The UI isn't using much direct manipulation with the mouse (like dragging a file between folder windows), though for example in the graphics editor one can do that for graphics objects. One also interacts with graphical scrollbars. Much of the UI is based on displaying textual and/or graphical objects AND running commands on them. Application windows all have a (often visible) command interpreter, where interacting with objects is done via commands on objects (and not only on text), using textual commands, mouse gestures or command menus. The Listener (as do other applications) also records all output and keeps the relationship with the objects which a drawn/printed. Thus the Genera UI does not use "toString", but calls PRESENT (or similar), a function which outputs Lisp objects in various ways, records the output (text and graphics) and keeps the relationship between object and output. Thus the Listener is not only a graphical stream, but also a graphical object store (-> it stores all output using a complex object-oriented framework). (similar -> McCLIM -> https://mcclim.common-lisp.dev https://mcclim.common-lisp.dev -> example for tools/apps https://mcclim.common-lisp.dev/excite.html https://mcclim.common-lisp.dev/excite.html ). One can return/print a data structure in the Listener and then one can point with the mouse at sub-objects and run commands on them (like 'describe'). This makes a separate inspector mostly unnecessary, though there is a inspector window. As there is a debugger window with backtrace, code display, etc. There is also a PEEK window, which is used to inspect things in the OS: Windows, File Systems, Memory, Processes, Network, ...
mst 2y ago
The Glamorous Toolkit crew have been doing some amazing stuff in terms of having multiple heavily custom type-specialised inspectors, and while being ST based they're much more GUI focused than REPL focused I think it's not unreasonable to say it's the same spirit, but ST style rather than Lisp style. (for those following along at home, Interlisp was a work of art and I cached a couple of the relevant manuals under https://trout.me.uk/lisp/ https://trout.me.uk/lisp/ so I didn't keep having to go find them yet again to re-read for inspiration)