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

I personally haven't tried the code reviewer approach with it yet. But I
can imagine it would suffer from similar issues. It will probably pick
stuff up that most people won't but it would probably also miss some subtle
things that people would find quickly. It is an interesting idea and it's
on my list of experiments to do. I'm just running up hard against the laws
of physics right now, that being the constraints around time and space, I'm
already spending almost every waking hour coding right now. But if someone
here has had any real success with this type of thing I really would love
to learn more. I think the ai coding lisp problem will remain an issue
because the sheer volume of training data for other tools dwarfs it. But
then again, quality vs quantity? Maybe the question should be do we have
enough quality common lisp code for it to train on. I also say common lisp
specifically, because in theory it would be possible to train this thing on
Genera with it's insane code base and documentation, but that's not all
common lisp....

Regards,

Eben Bruyns


On Fri, 8 Aug 2025 at 08:27, David McClain <[email protected]>
wrote:

> Er, no I did not attempt to compile and run the generated code. I was just
> watching and reading along, spot checking the code for correctness. Not a
> true wring-out of the code.
>
> So you might be right that there are lurking bugs, race conditions, etc.
>
> For me, I do think its having encyclopedic levels of knowledge, which
> would be difficult or impossible for mortals, and some notion of
> connections between the various parts is the best that it can offer. But
> somehow, it would be useful to build in a better knowledge of fundamental
> code safety issue, like race conditions, potential mutability violations,
> etc.
>
> Right now I have tickled pink to have a fully parallel concurrent Actors
> system, and I use it all the time to get massive parallel execution from my
> code. But to use it properly you have to be on your guard to ensure that
> your code is functionally pure as viewed from other threads. Lisp cannot
> enforce this kind of coding - use REMOVE instead of DELETE, no PUSH/POP, no
> SETF on globally visible items in the closure environments, etc.
>
> It would be useful to have something like a knowledgeable Claude serve as
> a code reviewer, looking for coding violations of functional purity. (I
> really don’t want to code in Haskell)
>
> - DM
>
> On Aug 7, 2025, at 13:16, Eben Bruyns (as eben at sdk dot co dot nz) <
> [email protected]> wrote:
>
> Did you run the code? When I did a lot of these early experiments the code
> looked good on the surface but it fell apart when I tried to run it, very
> quickly.
>
> Regards,
>
> Eben Bruyns
>
>
> On Fri, 8 Aug 2025 at 08:12, David McClain (as dbm at refined-audiometrics
> dot com) <[email protected]> wrote:
>
>> Interesting, thanks for the pointers…
>>
>> I asked it to show a Lisp implementation of a thread-safe FIFO queue that
>> supports multiple concurrent readers and writers. (Hint: MP:MAILBOX).
>>
>> Claude did a respectable job with a Bordeaux-Threads portable
>> implementation.
>>
>> I then asked it to recode in Lispworks Common Lisp, and it did a decent
>> enough job, using LW MP.
>>
>> But then I pointed out that it could just as well have used an MP:MAILBOX
>> and be done. So it abided by my wish, embedding an MP:MAILBOX into its FIFO
>> Queue structure, alongside a Size counter and an MP:LOCK to make updating
>> the Size safe.
>>
>> That is funny, to me. MP:MAILBOX-SIZE and MP:MAILBOX-COUNT already exist
>> in MP, so there is really no code needed at all, beyond just generating an
>> MP:MAILBOX.
>>
>> Just sayin… But I’d give Claude a serious B+ from what I see so far.
>>
>> I really do think that these kinds of encyclopedic tools, with connective
>> intelligence, would be most useful for understanding and using frameworks,
>> like CAPI, as you have already mentioned.
>>
>> - DM
>>
>> > On Aug 7, 2025, at 11:23, Alexey Veretennikov <
>> [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
>>
>
>