Live data from Hacker News

Common Lisp Screenshots: today's CL applications in action

lisp-screenshots.org

41–50 of 53 posts

Re: Common Lisp Screenshots: today's CL applications in action

#41
post #29

Earlier quoted context omitted.

We have enough headlines about LLMs already. Let's just enjoy a cool Lisp site without some AI advocate telling us that non-AI things are irrelevant.

I'm not an AI "advocate". I'm telling y'all about how the world is . How it's going to be . I'm not happy about it, but we've crossed the threshold beyond which it's incomprehensibly silly not to factor the massive changes LLMs bring into how you work designing or implementing software. Lisp apps are cool, but as of 2026 they're fading into irrelevance. The paradigm of programming they represent is bound for the Comp…

> I'm not an AI "advocate". I'm telling y'all about how the world is. How it's going to be.

This, together with grand claims that obviously don't hold up in reality, does make you an AI advocate no matter how much you dislike the label.

If you comment was more measured and had nuanced view, then I'd understand wanting to push back on it. But then you also say stuff like "Even a legacy code base can be poured into an LLM, which will grok it instantly" so no wonder others see you as a AI advocate.

Re: Common Lisp Screenshots: today's CL applications in action

#42
post #36

Earlier quoted context omitted.

> But a programmer+LLM is going to be far more effective in any language than an unaided programmer is in Lisp—and a programmer+LLM is going to be more effective in a popular language with a large training set, such as Java, TypeScript, Kotlin, or Rust, than in Lisp. So in a world with LLMs, the main practical reason to choose Lisp disappears. You are working on the assumption that humans don't need to even look at t…

> The trajectory over the last 3 years do not lead me to believe that it will be true in the future. Everything changed in November of 2025 with Opus 4.5 and GPT 5.2 a short time later. StrongDM is now building out complex systems with zero human intervention. Again, stop and actually use these models first, then engage in discussion about what they can and can't do. > But, lets assume that in some future, it is true…

> That's your human brain thinking it knows better. The "bitter lesson" of AI is that more data=better performance and even if you try to build a system that encapsulates human-brain common sense, it will be trounced by a system simply trained on more data.

I feel you glossed over what I was saying.

Let me try to rephrase: if we ever get to a future where humans are not needed to look at or maintain code again, all the training data would be LLM generated.

In that case, the ideal language for representing logic in programming is still going to be a Lisp-like one.

Re: Common Lisp Screenshots: today's CL applications in action

#43
post #11
post #3

Until Vindarel gets the TLS working there's also a direct URL: ( https://simple.photo/vindarel/c352e2c0177b24786fb40041657485... >). It's a bit of a shame that there's no indication to what application each screenshot is from.

Many of them do say which program they are from; at least the first of multiple are from the same program.

Yeah, turns out that feature is gated behind javascript, which is unfortunate. The website works pretty well otherwise.

Re: Common Lisp Screenshots: today's CL applications in action

#44
post #29

Earlier quoted context omitted.

We have enough headlines about LLMs already. Let's just enjoy a cool Lisp site without some AI advocate telling us that non-AI things are irrelevant.

I'm not an AI "advocate". I'm telling y'all about how the world is . How it's going to be . I'm not happy about it, but we've crossed the threshold beyond which it's incomprehensibly silly not to factor the massive changes LLMs bring into how you work designing or implementing software. Lisp apps are cool, but as of 2026 they're fading into irrelevance. The paradigm of programming they represent is bound for the Comp…

> Even a legacy code base can be poured into an LLM

Which LLM can read a whole code base? Embeddings do not count.

Re: Common Lisp Screenshots: today's CL applications in action

#45
post #3

Until Vindarel gets the TLS working there's also a direct URL: ( https://simple.photo/vindarel/c352e2c0177b24786fb40041657485... >). It's a bit of a shame that there's no indication to what application each screenshot is from.

Thank you, TLS should be fine now. (fixed ±12 hours ago)

Re: Common Lisp Screenshots: today's CL applications in action

#48
post #30

Earlier quoted context omitted.

My hammer is also solving problems. Still, hammering is not programming. LLMs are text generators.

The difference between the programming tools available before and LLM-based programming tools is the difference between your hammer and that of Fix-it Felix, which magically "fixes" anything it strikes. We are living in that future, now . Actually try it with frontier models and agentic development loops before you opine.

Assuming that everybody disagreeing with such takes simply can't have tried the latest generator is quite telling. Consider, that maybe, I'm not as easily impressed?

Re: Common Lisp Screenshots: today's CL applications in action

#49

Earlier quoted context omitted.

Until there is a bug and say due to DNS issues your LLM is. It reachable because everything is down

Good thing I've got Qwen downloaded to my MacBook in case of that eventuality!

Highly recommend https://github.com/fosskers/vend

Re: Common Lisp Screenshots: today's CL applications in action

#50
post #24

Earlier quoted context omitted.

Can your LLM do that to a running system? Or will it have to restart the whole program to run the next iteration? Imagine you build something with long load-times. Also, your Lisp will always behave exactly as you intended and hallucinate its way to weird destinations.

An LLM can modify the code, rebuild and restart the next iteration, bring it up to a known state and run tests against that state before you've even finished typing in the code. It can do this over and over while you sleep . With the proper agentic loop it can even indeed inject code into a running application, test it, and unload it before injecting the next iteration. But there will be much less of a need for that…

Ah, so I need to pay 100s of $ and use the "frontier" model, which is always a moving BS excuse. Last month Opus 4.5 was the frontier, gotta use it, now it's 4.6, and none of them so far have produced anything consistently good.

It is NOT reasoning about code. It's a glorified autocomplete that wastes energy. Associating "reasoning" to it is an antropomorphizateion.

And calling hallucinations "lateral thinking" is a fucking stretch.

"Let's use tool `foo` with flag `-b`" even if the man page doesn't even mention said flag.

Sure, they might be able to create numerous iterations of containers, testing them, burning resources....but that is literally a thousand monkeys smashing their heads on typewriters to crank out 4chan posts.

Post reply on HN