Comment by pjmlp
2 months ago
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.
Agreed that step debugging is the hello world, but I still think it is a better development tool than it is a bug finder.
I'd love to start celebrating more use of these, if you have recommended articles to spread exposure to.