As someone who hasn’t felt that magic with a repl and LLM’s, how do you integrate the two? Does it have to be in emacs and every buffer is accessible by a LLM?
It depends. If you're building an Emacs package or extending your own customizations, having "every buffer accessible" helps, because that way LLM is not dealing with Emacs (so to say), but with Emacs REPL, that has access to everything running within it.
That however doesn't really work well with other languages like Clojure - LLM can poke into clj REPL from the Emacs REPL by tapping to it through emacsclient, in practice - these layers start leaking pretty quickly. For Clojure (or Lisps in general), you need something that changes the fundamental model of how agents work, which is roughly the Unix/pipe model. Agent spawns process -> reads stdout/stderr -> spawns next process. State lives in files. Each tool invocation is stateless. This works for languages with batch-style toolchains (compile, test, run - pretty much any non-lispy lang). An agent that edits files and re-runs `clj` is doing something fundamentally different from what a Clojure developer does.
For Lisps, you need persistent nrepl connection, eval-in-namespace as the primary tool, ability to inspect live values, hot-reload awareness - not "run clj test and parse the output". For that you need specialized MCP. There are plenty of existing solutions. I built mine in Clojure (in babashka)¹. But that's because I use Emacs. If I was using VSCode, I'd probably use BackSeatDriver²
The main point is - Lisp REPLs are great and powerful, and there's no significant obstacle not to utilize them with LLMs. If you're using a homoiconic language and not utilizing the full power of the REPL, really, why?
Thank you for sharing. I never played with Clojure before but I’m very intrigued by this repl driven workflow from an agentic perspective given it changed the nature and relationship to the program/code.
I’ll look into the links and mentioned programs. Thank you.
I've been programming for over four decades as a hobby and more than twenty years professionally. I have gone through dozens of languages and still trying to learn more. Getting into Clojure still remains one of the best decisions I made in my life. I don't know why mainstream programming media - publishers, meetups, major conferences don't talk about Lisp (as if it doesn't matter at all). Common Lisp perhaps has created this aura of elitist culture (similar to Haskell) - "you have to be this tall to ride this rollercoaster", etc. Turns out, Lisp really is not that difficult. You don't need years of accumulated knowledge to start programming in it. If you know just a single mainstream PL - you already have almost everything you need to start, because pretty much every single programming language has been influenced by Lisp.
And Clojure, unlike Haskell, is way more down-to-earth and enormously practical. I'm not saying Haskell is not, but let's be honest, for anyone to start writing production-grade Haskell would take weeks, not hours. While Clojure needs minutes. These days you can just download the Calva VSCode extension and start playing with it.
Even if one thinks "there's just no way to use it at work", there are so many smaller things they could use it to improve their personal workflows. "Of course, when you only know a hammer, everything looks like a nail", someone might say. Yet, for me, who has seen, learned and used dozens of different "hammers", this one does look quite interesting. For a bunch of pragmatic reasons. And my message to any "hammer-wielding craftsman" - you really don't need to try dozens of hammers to see the value in a good one, and Clojure is a pretty darn good one, I promise.
That's interesting but that's not what this video is. The star shape in the DoD video is a camera artifact. Just a really bright source of infrared light.
At this point, I would dismiss every image of anything that shared symmetry with any part of the camera taking the photo.
In the 90s there was a wave of diamond-shaped craft in Europe. All were taken by cheap disposable cameras with four-bladed aperture. The current trend now is fuzzy moving images. They are fixed points like stars and the "motion" and color changes comes from the digital camera's algorithm trying to make sense of a one-pixel signal from the ccd. (See flat earth videos claiming that stars/planets are actually spotlights.)
Lol "deep lore" - what are you really some sort of priest on this topic? Ok, priest, what is your read of the bigger picture - not the narrow DoW released videos, but the larger context.
Re the counterpost - i admit it's a good effort to match the graphics - but it still looks markedly different. Thermal overexposure seems less likely given paucity of other examples - what about active jamming? IR laser pointing? Hunch just now: sth about polarized light? Idk.
It was just a joke. You linked a thread about one particular camera artifact but missed the fact that there was another thread about this specific case. I've read all of those threads.
There's not really much ambiguity here regarding these factors now:
- it's a small bright infrared light source attached to a parachute
lol, it was funny. Tho dishonest to pretend a consensus has been reached after your "high confidence" comments. More like "you hope" 'there's not much ambiguity'.
My hope was you'd be actually interested to discuss in depth - but seems like you want to end the conversation here. That's okay, no worries. Just a little disappointing and surprising (or maybe not - 100% certainty is not exactly compatible with "willing to update beliefs" ;)).
The full quote is "don't cite the deep lore to me, I was there when it was written". The intention is to imply that he was there when the thread was created.
You don’t have to trust the recommendations, you can analyze the reasoning behind their decisions and argue that. In this case the risk being at the engineering and hardware side and also denial of service. In addition to the trusted relays. Those are valid disputes.
You can argue these exhaustively. They have not done that here. Some of their arguments are complete bunk.
e.g. "Quantum key distribution requires special purpose equipment"
Yes, it requires special equipment. That hasn't deterred some from using it where the added expense is warranted. Commercial QKD systems have been in use for decades. The technology is not currently useful for credit card transactions from your living room, but that doesn't mean it has no applications.
"Since QKD is hardware-based it also lacks flexibility for upgrades or security patches."
This is like arguing that, because your internet connection runs on hardware, nothing can be done to upgrade it or fix security vulnerabilities. If your last-mile connection is copper, as it is for many, there have likely been massive upgrades to its bandwidth and security over the years in the form of changes to what's on either end of the copper. Fiber is the same way. A huge part of QKD protocols is software as well.
When I see points like these, I question the source. They appear to have an agenda, and they certainly have motive. Remember, this is an organization whose business has been spying on its own citizens for decades.
The big hardware issue is that QKD requires point-to-point links between the endpoints that authenticate to one another. That doesn't scale well to more than a handful of endpoints. Even if the endpoint hardware is free.
The big logical issue is that QKD requires a classically-authenticated channel, so you either need a post-quantum signature scheme (at which point why bother with QKD since you can usually use the same computational hardness assumptions to construct a post-quantum key exchange scheme & use AES-GCM or ChaCha20-Poly1305), or you need pre-shared symmetric key material & a Wegman-Carter MAC a la Poly1305 (at which point why bother since you can just use AES-GCM or ChaCha20-Poly1305).
Sorry can you expand on that? I have a Gemini subscription from a Google pro account but never used it much. I can use it with Claude Code?? Hmm. I’ll look it up. Thanks!
reply