Re: Just take me out back and shoot me...

"Eben Bruyns (as eben at sdk dot co dot nz)" <[email protected]>
Newsgroups gmane.lisp.lispworks.general
Message-ID <CAEPc2Hcs8j20qzA_aKcefwvkMX_TpYtUmNATQo7G7bWuccYnUw@mail.gmail.com>
Yes I have found the incremental steps to work up to a point as well. I
think the real problem is that of context and context loss. Since I'm
probably trying to do tasks that's beyond "basic" don't bother with Opus,
the results are worse. Sonnet does a much better job, but still not great.
While we're on the subject Claude Code can vary wildly from day to day.
Some days it's smart, other days it feels like it's hung over...

I haven't personally had it write production code, but the experiments my
wife has done I'd say was pretty successful, she's doing the work of a few
junior devs with it. So from that perspective I can't complain. I think the
problem is likely due to the fact that I'm actually breaking new ground
with some of the stuff I'm doing, so it has no frame of reference. I don't
think many people are trying to do the stuff I'm doing under the covers
(and for obvious reasons I won't go into detail around some of this). It
really does seem to excel at doing the standard rote stuff that we use
"code grinders" for.

Regards,

Eben Bruyns


On Fri, 8 Aug 2025 at 08:38, Arnold Noronha <[email protected]> wrote:

>
> The key I've found was to work in incremental steps.
>
> Basically, my Emacs+Claude integration looks like this: put the point
> on the start of an s-exp, call M-x claude-rewrite-sexp and give it a
> prompt. So at any point of time, it's only rewriting one small S-exp.
> If I ask it to rewrite an Emacs region, if frequently gets the
> parenthesis wrong, but if I ask it to rewrite an S-exp, never hits the
> parenthesis issue.
>
> If it struggles, I give it a few other carefully chosen sample files to
> show it the patterns I'm using. (For instance, special macros,
> functions and what not.)
>
> Also, ask it to write unit tests, it does a pretty good job and you'll
> be validating its work as you go. (Btw, I don't even use Opus, I just
> use Claude Sonnet, and it's still great.)
>
> Claude Code is a different beast. I haven't had success with production
> code with it yet, but it was useful in order to test out complex
> refactorings to see where I might get stuck if I had to do it myself.
>
> --Arnold
>
> On Fri, 2025-08-08 at 08:15 +1200, Eben Bruyns (as eben at sdk dot co
> dot nz) wrote:
> > Oh I want to pipe up here. I'll share a little bit about what I've
> > been doing in lisp while I'm at it.
> >
> > Some of you might have seen me pop up in here asking some strange
> > looking questions at times, time to show and tell.
> >
> > The main project I've been working on is an extensible launcher
> > platform for a Gaming handheld machine called the Steam Deck. I
> > started off writing this in python as a FOSS project, but since the
> > community turned out to be basically me, I ditched the efforts there
> > in favour of finally learning Common Lisp properly.
> >
> > I started off using these AI tools (co-pilot, chat gpt etc), as a
> > test. With python it was yielding somewhat ok results initially.
> > Here's the open source repo for those
> > interested: https://github.com/ebenbruyns/junkstore
> >
> > I ran into problems with it pretty quickly. I can say with reasonable
> > certainty that every single hard to find bug was casually introduced
> > by these AI systems being "helpful". They've created many subtle race
> > conditions that took hours or days to debug, and once I looked at the
> > code I realised that I would never have written it that way to start
> > with.
> >
> > I'll give you guys some hours spent on this just so you can have
> > context and put it all in perspective. The FOSS code took around 1000
> > hours to develop, test debug etc. I have another component written in
> > python too that adds functionality to the FOSS version that's paid
> > and took another 400 hours or so.
> >
> > When I decided to stop writing open source and in Python I switched
> > to Lispworks (best decision ever). I've spent another 4500-5000 hours
> > working on this new version, but AI can't code lisp. Instead what I
> > found was that all the tasks I used AI for I could just abstract away
> > in macros, clos and other lisp specific goodness that made the AI
> > obsolete really.
> >
> > You can see the application here: https://www.junkstore.xyz/
> >
> > Then a few weeks ago I talked to a friend and they put me onto Claude
> > code. The results have been a mixed bag. I'm doing some pretty heavy
> > reverse engineering stuff (as you can imagine with a project like
> > this), and it's helped me build some tools to aid in this very
> > quickly, but it destroys things as quickly as it can create them.
> > It's been a wild roller coaster of  2 weeks with this thing and I
> > think if I just coded stuff in lisp I could potentially have done a
> > lot more in that time.
> >
> > But it's not all been wasted. My wife, who is not a programmer, has
> > been using Claude code to crunch, twist and bend the website. I think
> > the results are pretty decent. As an experiment I thought I'd throw
> > her the secure portal UI (since all the real code is in services the
> > security aspect is abstracted away from it and it's just user
> > experience that can get affected). I have to say the results and the
> > speed at which she was able to do things is incredible. I did have to
> > review the code, and I actually need to review the code much closer
> > than I would with human devs. The problem is that you can't tell them
> > why something is bad and not to do it again, they don't remember. So
> > you have to check for the same stuff over and over again.
> >
> > I think there's certainly value in these tools, but I don't think the
> > value is as much as the industry wants you to believe. The real trick
> > would be to find a way to put these tools on rails and keep them on
> > rails.
> >
> > I've done some experimentation with setting these tools up with
> > testing feedback loops and you can get better results if you do that,
> > but it's still an exercise in frustration most of the time. If I had
> > the resources I'd get my hands on some serious hardware that can run
> > a "large" small language model or something and specialise that on
> > the stuff I'm doing, to see if that yielded better results. Living on
> > a sailboat with solar power and using a 15w power budget on my
> > machine doesn't really leave much room for this type of thing though.
> >
> > Anyways, I just wanted to share this as I think it might be
> > interesting to some of you.
> >
> > Regards,
> >
> > Eben Bruyns
> >
> >
> > On Fri, 8 Aug 2025 at 06:24, Alexey Veretennikov (as alexey dot
> > veretennikov at protonmail dot com) <[email protected]> wrote:
> > > Yes indeed Claude could write Lisp code now. I've tried and it
> > > works for some primitive functions/algorithms. I successfully used
> > > it with Aider for CL code.
> > > I would love to see some MCP agents with integration to popular
> > > APIs in LW, so we can try to use it at least in chat mode with
> > > ability to modify open files.
> > > Would be also nice to have a feature in Editor for auto-reverting
> > > modified buffers, so integration with command line tools like Aider
> > > could be easier. I've submitted the feature request for that and
> > > hope it is not a huge work to do, it would help a lot.
> > > Would be nice as well to have a terminal with ansi colors support
> > > so we can launch i.e. aider directly from LW.
> > >
> > > BR,
> > > /Alexey
> > >
> > >
> > > On Thursday, August 7th, 2025 at 20:14, Arnold Noronha (as arnold
> > > at tdrhq dot com) <[email protected]> wrote:
> > >
> > > > Claude (not Claude Code, not Claude Chat, but the Anthropic API)
> > > > actually writes Lisp really well, as long as you give it the
> > > > right
> > > > context because everyone's Lisp code looks different.
> > > >
> > > > It even handled CAPI quite nicely, even though it hallucinated a
> > > > bit..
> > > > but close enough to guide me through my first CAPI app.
> > > >
> > > > It's also remarkably good at writing Elisp, which makes it easier
> > > > to
> > > > write dev tools. I used that to bootstrap a little Cursor like
> > > > Emacs
> > > > integration, which I use almost daily now.
> > > >
> > > > Thanks,
> > > > Arnold
> > > >
> > > > On Thu, 2025-08-07 at 09:59 -0700, David McClain (as dbm at
> > > > refined-
> > > > audiometrics dot com) wrote:
> > > >
> > > > > I finally caved in this morning and tried ChatGPT. I am long
> > > > > familiar
> > > > > with “AI” in its present state, having directly used
> > > > > Perception,
> > > > > Kohonen, and Probabilistic networks back in the 1990’s for
> > > > > control of
> > > > > “rubber mirrors”, target tracking for missile guidance, etc,
> > > > > etc.
> > > > >
> > > > > I was holding off because this is not AI, just a recognizer of
> > > > > patterns with an ability to generalize. Komogorov wrote a
> > > > > theorem a
> > > > > while back that a feedback perceptron network with N inputs +
> > > > > feedback can emulate an Nth degree attractor in high
> > > > > dimensional
> > > > > fractal systems. That’s why we could use the rubber mirror to
> > > > > cancel
> > > > > out atmospheric scintillation of star images on the Kitt Peak
> > > > > 4m
> > > > > telescope back in the early 90’s.
> > > > >
> > > > > At any rate, I saw a video expressing the virtues of ChatGPT
> > > > > for web
> > > > > search, rather than Google search, since it doesn’t offer up
> > > > > tons of
> > > > > extraneous finds based on whomever paid the most to get in
> > > > > front of
> > > > > your eyeballs. And so I tried it, and it does work better.
> > > > >
> > > > > But, as long as you already know a great deal about some topic,
> > > > > you
> > > > > are prepared for its hallucinations (which I have yet to see),
> > > > > and
> > > > > its tendency to offer up a consensus opinion as authoritative
> > > > > fact.
> > > > > You have to push back and challenge its answers, and that
> > > > > generally
> > > > > provokes an even better response.
> > > > >
> > > > > So, along the lines of a discussion about Transactional
> > > > > Conventional
> > > > > Hewitt Actors, it offered up the statement at one point about
> > > > > parallel concurrent activation of the same Actor by two
> > > > > different
> > > > > dispatch threads sending two different messages at the same
> > > > > time:
> > > > >
> > > > > "You retry only if the actor behavior was concurrently
> > > > > changed, which is rare in practice if messages are processed
> > > > > quickly.”
> > > > >
> > > > > I challenged that as an opinion, not fact, since I had the
> > > > > experience
> > > > > of a debug monitor Actor becoming overwhelmed by parallel
> > > > > message
> > > > > collisions in my Ionosphere Watch System:
> > > > >
> > > > > "Your statement "You retry only if the actor behavior was
> > > > > concurrently changed, which is rare in practice if messages are
> > > > > processed quickly." is just a (hopeful) opinion. It could very
> > > > > well
> > > > > happen that collisions in some situations could happen very
> > > > > frequently.”
> > > > >
> > > > > To which it acknowledged my criticism as valid, and offered an
> > > > > even
> > > > > better answer, mentioning an exponential back-off, like we use
> > > > > in
> > > > > TCP/IP and Transactional Memory systems.
> > > > >
> > > > > That was an interesting suggestion, but I can probably get by
> > > > > just
> > > > > using a “put the collision message back on the queue for later
> > > > > delivery attempts”, instead of a direct immediate retry with an
> > > > > exponential back-off.
> > > > >
> > > > > At any rate, I am now willing to concede that ChatGPT may be
> > > > > useful,
> > > > > especially if you are alone in a room staring at 4 walls. But
> > > > > I’m
> > > > > still not willing to consider it true AI. And I haven’t allowed
> > > > > it to
> > > > > write any Lisp for me. Maybe someday...
> > > > >
> > > > > - DM
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > Lisp Hug - the mailing list for LispWorks users
> > > > [email protected]
> > > > http://www.lispworks.com/support/lisp-hug.html
> > >
> > > _______________________________________________
> > > Lisp Hug - the mailing list for LispWorks users
> > > [email protected]
> > > http://www.lispworks.com/support/lisp-hug.html
>
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.