Comment by taeric
2 months ago
Cool, I'm assuming this is largely driven by mouse usage, as well?
I'm always baffled by how long it has been since I was used to step debugging. It was definitely something that was huge when I was learning, but seemed to get left behind by so many practices.
My general memory is that it was growing and the likes of JRebel were aiming for very powerful uses of debugger connected development experiences. Eclipse, as I recall, have their own compiler specifically to let you debug code that isn't completed. Then, cloud technologies largely came and many just lost track of what could be done.
A fun example, I remember senior engineers at Amazon that didn't know you could hot patch Java while step debugging. Something that they had largely never had a chance to do, because of the standard deployment processes they had been used to.
To the direct point, I am somewhat surprised these aren't doable in Common Lisp. I saw examples showing these years ago, just without the GUI affordances that were in some of the other IDEs. https://malisper.me/debugging-lisp-part-5-miscellaneous/ has examples of the trace command offering conditional breaks and such. Sounds like there is the functionality, but lacking the visual cues/affordances?
> Sounds like there is the functionality, but lacking the visual cues/affordances?
Yeah, some things are missing (arbitrarily moving control to a given line (even if it precedes the current one) in a function, stepping into some functions[1]), but mostly they're there, just clunky to access and view. It's getting better, though - I checked the cookbook page[2] and found a project[3] that I didn't notice previously, which should help quite a bit with convenience. Even with that, though, LispWorks[4] still looks better... ;)
[1] The ones compiled with a low `debug` setting; they're either impossible to step into, or you land in the decompiled source. Trying to step into a function call should recompile that function automatically with debug instrumentation enabled.
[2] https://lispcookbook.github.io/cl-cookbook/debugging.html
[3] https://github.com/mmontone/slime-breakpoints
[4] https://www.lispworks.com/images/lw-ide-cocoa.png
One of the reasons I kept around Java and .NET ecosystems on my toolbox, regardless of their lack of coolness by modern coffee shop coding standards, is exactly the traces of Smalltalk/Lisp development experience that somehow are part of the tooling and runtime capabilities.
By the way, it is relatively easy to plug a debugger into a running container in a Kubernetes pod.
Yeah too many folks pretending their systems are UNIX in 1980's, and not aware of what is available.
I frequently try to mention how Java with JRebel is the closest to the Lisp experience I've found with non-Lisp, it's more dynamic feeling than so-called dynamic languages. Having something like the condition system being ubiquitous would be golden. (I'm aware there is a Java port though I never got around to playing with it and it doesn't solve the problem of other people's code not using it..) My last big job involved a giant app server that would take minutes just to restart if you had to do it, JRebel saved so much time by making things much more reloadable including support for a lot of other libraries' quirks and in general a lot of Java-isms like things configured with XML. Looking under the hood at the JVM you can see traces of Lisp everywhere, like class loaders are just (load)s, it's easy to believe the quote about dragging C++ programmers halfway to Lisp.
Then there's things like rr (https://rr-project.org/) that also seem largely ignored by old unix systems people, despite being exactly appropriate for that environment.
Still, having the whole language available via REPL as Lisp does when you hit a break or error makes up for a lot of weaknesses in the rest of the debugging experience.
I haven't met the individuals like taeric but I do find it plausible that something has been lost for developers whose main experience is in highly separated cloud-oriented systems, whether they go as far as micro-services or not. When you don't have full end-to-end debugging and have to correlate everything with trace ids in logs, and also if policies prevent even getting a debugger hook in production, I can see how one would be less motivated to learn about debugging tools to begin with. (On the other hand you're encouraged to have better logging, and often that's enough to figure out a problem, no need to have a running application.)
Most of the stuff like class loaders came from the Objective-C influence, which naturally has its influences in how Smalltalk and Interlisp-D influenced each other work at Xerox PARC.
JAR files and related structure, are basically redressed NSBundle packages.
Agreed on your last paragraph. Really all of your post. I would oddly find myself arguing against people trying to make a complicated step debug mock setup to simulate the deployed environment when looking for bugs. A general socratic approach to the behavior you were witnessing was a valuable way to find bugs.
To me, the connected debugger was far more interesting as a development tool than a debugging one. Despite the name.
I think the 1980s probably had higher debugger use than today. :)
I was specifically thinking of things like Cloudflare Functions and AWS Lambda, for the deployments that you can't really step debug. They both have ways, nowadays; but nothing that would let you do a hot patch to fix anything.
Granted, my example of senior engineers would be odd there. They definitely were deploying code as standard jar files to machines. Not sure why they didn't know of this. Even the more complicated war files were straight forward to connect to.
Further granted that this isn't something you could realistically do to a fleet of machines. Guessing that is why they didn't ever try to use it.
Depends, Azure definitely has the integrations needed for modern debugging.
With application insights and event tracing, that can be event plugged and debugged postmortem on Visual Studio.
Java world has similar ways with JMX, Visual VM and JFR.
Another great one on part with these two for distributed computing are Erlang based systems.
Finally we have language agnostic ways to do similar workflows based on open telemetry, even if code reload is not part of it.
Step debugging is the hello world version of how to use a debugger.
1 reply →