logoalt Hacker News

pjmlp04/24/20252 repliesview on HN

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.


Replies

Jach04/25/2025

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.)

show 2 replies
taeric04/25/2025

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.

show 1 reply