Personal notes on health, AI, and the direction of SWI-Prolog

General
1

Dear SWI-Prolog user,

This is set of rather personal notes. Some users may have noticed
changes in how I manage SWI-Prolog. Most recent contributions have
been implemented by Claude Code and I’ve not been very active on the
forum. The reason for this is that I was diagnosed with rectal cancer
in August last year. End of April I had the main surgical intervention.
Together with some complications this caused a lot of discomfort,
notably not being able to sit for more than 10..15 minutes. There
will be some more uncomfortable treatment. The good news is that,
unless I’m very unlucky, I should fully recover.

Not being able to predict how I would function during the various
treatment steps as well as problems concentrating caused a serious
change of activities. Except for small tasks for long-term commercial
customers I have not done any commercial work in that period. Instead,
I concentrated on improving SWI-Prolog, the tooling in particular because
it distracts, is fun and I do not have to deal with deadlines.

After the main surgery, traditional programming was not an option.
This is a perfect moment for contemplation and trying new paths.
Inspired by @EricGT I have been exploring the use of AI, Claude Code
in particular. I explored ChatGPT about a year ago to conclude it
might be nice for student exercises, but not for programming. Half a
year later I used ChatGPT for porting the XPCE GUI library to SDL3.
That was a better experience, although overall still a mixed blessing.
It was mostly good at finding the right API calls from SDL3, Pango and
Cairo, but plumbing them the wrong way. Pointing it at a bug
typically resulted in a completely different new implementation that
was buggy some other way, so eventually I had to do most debugging.
Agentic AI, first OpenAI Codex, is a game changer though. I quickly
switched to Anthropic’s Claude Code, mostly because they seem to be
most aware of the ethical implications of AI and are considered
state-of-the-art.

I used Claude Code mainly to enhance the tooling, mostly because it is
fun and doesn’t require too much deep thought. Working with the AI
fits my current physical state perfectly: sit down shortly to review and
adjust the AI generated plan, review code and test it then type a few
sentences of new instructions. Next, one can do exercises or other
small tasks while Claude Code does the work for a few minutes or
sometimes as long as several hours for writing a random test suite for
the commandline editor, simplify a failed run and fix it; repeat until
1,000 random edits show no issues.

Main tasks tackled (contemplation on that below):

  • Get libedit (the commandline editor) to work properly on normal
    terminals, the Windows console and the Epilog console.
  • Make Epilog deal with 256-colour and direct-colour modes, strike-through and
    proper link (hover) feedback. Required significant changes to the basics
    of the terminal. Implemented by Claude Code with minimal
    intervention.
  • Get libedit, XPCE and Prolog to deal with the full Unicode range,
    including double-width glyphs (Emoji, several Asian scripts) and
    Unicode combining characters. This included changing the text
    representation used in XPCE. All this was implemented by Claude
    with minimal intervention from my side. It tends to use a bit too
    much copy/paste programming, but if you point at that it is happy
    to generalise and reuse.
  • Implement a Unicode symbol picker in XPCE. It needed some help
    and a few iterations, but programming in XPCE+Prolog is not really
    mainstream!
  • Deal with refining the Prolog Unicode syntax extension. Both
    implementation and design. Handle feedback from the PIP working
    group on this topic.
  • Update XPCE’s look, notably by designing SVG icons and adding support
    for SVG icons to XPCE. I’m not really impressed by Claude’s ability
    to design icons. It took a lot of guidance and is still far from
    the quality that a human graphic designer would have produced. It
    does look less 1990 style though :slight_smile:
  • Implement 2D transformation matrix in XPCE, allowing for scaling,
    rotation and shearing. This is a giant task that was completed
    in two days with only a short planning stage and few prompts.
  • Same for implementing opacity for graphical objects (much simpler
    though).
  • Refactor the XPCE reference documentation that was stored in saved
    binary blobs representing XPCE objects. Its task was to extract
    the documentation, store it in Markdown files and add a plugin to
    PlDoc to make it understand the XPCE documentation conventions.
    This required quite a bit of guidance. But then, it concerns a
    lot of legacy material in a rather alien environment.
  • Modernise the documentation of many classes, notably updating it
    for the changes due to moving from X11 to SDL3 (still need more
    work).
  • Refactor the MacOS binary from a bundle to a .pkg installer
    and include all the automation to sign the package. I had started
    to do this by hand, but gave up as it was too complicated and
    frustrating. Claude did the job quite quickly and with not much
    intervention.
  • Fix quite a few bugs. I’m most impressed by Claude’s ability to
    fix bugs. With very little input it often finds the culprit
    remarkably quickly. It is not always right about the details
    nor the fix. Even if it is wrong, its analysis helps a lot in
    nailing the problem. These days I start giving it the URL of
    a bug report and see what it comes up with.
  • Write a lot of (PlUnit) tests as well as writing, improving
    or updating documentation.

Contemplation

What did I learn? First of all that agentic coding systems have
matured immensely. In my experience to the level where these tools can
no longer be ignored. Is this good or bad? First of all, it just is
there and we cannot uninvent it. I was first considering this a
threat as it makes what I liked doing for over 40 years redundant.
Right now, I’m quite positive. Claude does a lot of the boring work
that also belongs to system development: bug hunting, writing tests,
updating documentation, reading through API documentation,
investigating portability issues (which platforms support X, if I
drop support for an outdated API, would it affect any still supported
platform, etc.). Instead, I can concentrate on what I want. If I
want to do some programming I still can. I can leave the finishing
touch to the AI though: write tests, fix issues and document; the
tasks that typically take most of the time and I like doing least.
I tried this and it was a pleasure!

What about our profession? I learned programming by doing small tasks
in the then young XPCE GUI library developed by Anjo Anjewierden. I
learned a lot by looking at his clean programming style and design.
Richard O’Keefe taught me a lot from work I did on his Thief editor
(a very lightweight Emacs clone used in Edinburgh in the 1980s, when
Emacs was an abbreviation for Eight Megabytes And Continuously
Swapping) as well as the many comments he had on SWI-Prolog. In
short, I learned by imitating and comments from giants. Now I
have the experience to prompt the AI, keeping an overall overview
of where the system should move, its architecture as well as general
principles on maintaining good programming style. How will young
professionals gain these skills?

These developments do raise some existential questions. I’ve spent
quite a bit of time on SWI-Prolog’s development tooling and made a lot
of progress with help from the AI. However, the AI doesn’t need most
of this tooling for writing Prolog programs … Crash reports with
good diagnostics are useful to the AI, but it doesn’t need a GUI
debugger, tooling that provide insight in the program structure,
editors, syntax highlighting, etc.

I tend to believe there is still a role for Prolog itself as it is
a good language for knowledge intensive tasks that require reliable
reasoning. For any such task, a Prolog program will outperform AI
by a large margin while providing trustworthy results rather than
results that are 95% correct, but wrong in some weird way in the
other 5%. Formalised as Prolog typically makes the logic easier
to assess and verify than imperative languages. I do believe most
of the Prolog code will soon be AI generated though.

Final words

I hope (and suspect) that I will soon recover enough to resume work
without constraints due to concentration problems and not being able
to sit comfortably. I’ll continue work on SWI-Prolog and hope to
restart commercial work in a couple of months. Donations (thanks!) as
well as commercial work are important to keep the project financially
healthy. Commercial work is also important to find new challenges.

I wonder about the overall direction in which (SWI-)Prolog should
evolve. Improving tooling, aiming at human program development seems
not a good investment. Possibly the tooling still has a role
maintaining an overview of the code? Tools like the profiler,
coverage analysis and static analysis can still play a role in
assessing bottlenecks, test completeness and potential bugs. With
modern graphics, XPCE can again play a role in providing interactive
GUI applications as the AI is quite capable of doing so.

I’m considering some refactoring of the Prolog core. Notably the way
engines/threads are threaded through the system is awkward. Too much
work to do by hand, but if the AI can do it, it is worth considering.
Actually exploiting the 64-bit Prolog cells we have now (also on 32
bit platforms) rather than using indirections to make all data types
fit into 32 bits can simplify the system and provide some performance
improvement. Implementing proper clause indexing for typical Prolog
predicates using a handful of clauses and for which first argument
indexing does not work well is another many times delayed plan. More
static analysis tools? Ideas on what has most impact are welcome.

Enjoy --- Jan

P.s. I wrote this myself :slight_smile: I did ask Claude to fix spelling and grammar …

2

Best wishes for your recovery. I’m certain that whatever direction SWI-Prolog eventually progress towards, it will be much appreciated by this community.

Ian

3

Thank you so much for all your work on swi-prolog and especially the tooling side.
The gui debugger is one of the most used piece of gui software that I use regularly with prolog and is a very precious tool to actually understand intuitively how prolog execute.

4

I can only join to these best wishes.

5

Considering what you’ve been faced with, your responsiveness to questions and workrate has been astonishing. I hope you continue to make a rapid and full recovery, and thank you for all the help you’ve given me and the entire community - I think it’s safe to say we are all rooting for you!

I found your experience of and musings on AI interesting, and they closely parallel mine. Like any new tool, how you use it needs care and consideration.

That’s exactly my experience. I’ve written a fairly old-school Expert System in Prolog that looks for configuration issues and unused resources in a large Cloud estate. The incoming data is JSON, the output is a set of JSON “symptoms”. The rules are mostly simple and are all self contained, a very good use case for Prolog - and yes, it’s fast. The next step was analysis, grouping and remediation planning - perfect for a LLM, right? Hmm, up to a point. Whilst the LLM is excellent at planning and prioritisation, its attempts at remediation were either OK-ish or catastrophically bad - and you never knew which you’d get. For example it would happily delete storage resources (which can’t be recovered) whilst point-blank refusing to delete Compute resources (which can be recreated). When I got it to agree to delete Compute resources, it then decided that the best way to fix simple attribute-edit problems was to completely delete and recreate the resources… :exploding_head: I ended up getting it to write an “Architectural guidance for fidelity-critical LLM workflows” for me, the crux of which is that LLMs need to be the “Jam in the sandwich” between deterministic input layers and deterministic output layers - both of which Prolog is an excellent match for.

On the flip side, I now have a SWI-Prolog plugin for IntelliJ, entirely LLM generated, I haven’t even looked at the code. It does most of the things I want - code formatting, symbol search, setting breakpoints & handoff to the SWI debugger etc. However it took prompting spread over many days and 135 commits to get there, and burned a frightening number of tokens. But on the other hand I had no interest in becoming an IntelliJ plugin developer.

Much of the current LLM buzz is around LLMs as coding agents, and I think that use case flatters to deceive. Codegen is usually a linear sequence of smaller iterations - there are a bazillion ways to implement something, and if the LLM doesn’t get it right it can just be told to try again. Business processes however have to be predictable, repeatable and auditable - all areas that LLMs are weak on. A blended approach as in the “Jam sandwich” model is pretty much mandatory if you want to avoid chaos. and I think the low impedance mismatch between Prolog & LLMs makes Prolog an attractive option.

I’ve just done exactly that, several times:

  • I needed to add support for some more Cloud resource types, I pointed the LLM at the Cloud REST API docs and some examples of existing handcrafted Prolog code and the result was probably 85% of the way there.
  • I was asked to add CLI invocations to the output of my Cloud Resource analysis system, I pointed ChatGPT at the CLI docs and the Prolog source of the system and told it to generate a DCG, again it got pretty close on the first pass.

There are weaknesses however, it often misses that there are standard library calls to do what it wants and it ends up spewing out a lot of unnecessary code. If you point that out it will self-correct, but you certainly need to review its output carefully. I suspect that’s because, relatively speaking, there’s far less of a Prolog code corpus for it to be trained on.

It’s not “core” functionality but how about a MCP Server library as a first-class citizen of the SWI ecosystem? There are some things out there but they seem mostly about providing access to a Prolog interpreter via MCP, rather than being a framework for writing MCP servers in Prolog. Most of the bits you’d need (HTTP, JSON) are already there and there’s already a sophisticated HTTP server framework in SWI.

6

Dear Jan,

People who know you will not be surprised by the strength, good spirits, and generosity with which you have carried all this. But that does not make it any less admirable!

I just want to add some thoughts on Claude, trying not to oversimplify it. Photography automated faithful visual reproduction but it did not destroyed painting, but changed its center of gravity. AI coding assistants automate much of routine code production, but does not eliminates the need of human judgement. I like the analogy because painting was never only “making realistic images”, just as programming was never only “typing code”. Painting involves vision, meaning, composition, and taste; computer science and software engineering involve modeling, abstraction, correctness, architecture, constraints, and responsibility. AI reduces the value of merely producing code, but it increases the value of knowing what code should exist, why it should exist, and whether it is good.

7

Dear Jan,

It is great news that the diagnosis is for a full recovery.
Hope all goes well.

Many of us owe you huge debt of gratitude.
SWI allowed us to continue using Prolog in an, open, modern and productive environment.
Thank you.

Best wishes for your full recovery,

Nicos

Nicos Angelopoulos

8

My thoughts are with you — I hope you take all the time you need to recover.

–

Regarding sitting: one of the most requested features for AI coding tools like Claude Code, OpenAI Codex, etc. has been the ability to use a phone to remotely run a session, and to address limited screen space, to use voice mode.

(Note: I haven’t used either yet, but do plan to eventually.)

9

I’ve used that. It works, but connecting the the commandline Claude code is a bit of a nuisance and you have to reconnect for each session. I also tend to want some screen space to test and/or review what it has been doing. So yes, for some sessions it is nice. In general I prefer my desktop.

10

All the best wishes for your continued recovery Jan! We all appreciate your dedication a great deal.

I, for one, still write code “by hand” and would be pretty sad if things moved in a direction where an (expensive, proprietary) “agent” was the only supported way of developing.

11

This is a general problem for LLMs when faced with domains in which they do not have enough training. Often one can “steer” the LLM to the use of standard library calls when the dev knows about them. It might be an interesting project for the community to pull together 1) an analysis of standard library calls that the LLMs seem to be ignorant about and 2) put together a list of examples of usage of those library calls (maybe with the help of Claude Code) and then 3) fine-tune an open source model on those more detailed use cases and then post that fine-tuned model to Hugging Face. Thoughts?

12

@jan All the best in your recovery. Every time I hear about the latest AI model dropping from the frontier labs I keep wanting to ask them, “So, how’s that cure for cancer coming? Or raising everyone up from poverty?”. We so need to get our priorities as a species straight. So frustrating.

13

This sounds like a good candidate for a Skill, then it could be plugged into any existing LLM. Or perhaps even better as a MCP server sat on top of https://www.swi-prolog.org/pldoc/doc_for, then it would be searchable and always up to date? It could be used as a testbed for the MCP server library that we don’t currently have… :wink:

14

I wouldn’t worry too much about that :slight_smile: Too many people, including myself like to do some programming the old way :slight_smile: Also, while I’m very happy with AI for bug hunting and quite happy for incremental development in an existing system with a well established design, I’m not so sure it is good in inventing novel ways of doing things and that is what I like most!

Opening the documentation and possibly also some of the tooling as MCP is surely worth exploring. I’m also thinking about letting the AI generate examples on how predicates can be used. We have an infrastructure for that, but not many contributions :frowning:

P.s. Thanks for the kind words in all responses. Much appreciated!

15

So sorry to hear about your struggles; and your amazing response. Good luck with a full recovery.

I still remember hearing about SWI-Prolog in the 1980’s (can’t recall exactly when though).

As for using Claude, etc., I agree that the world has changed. I have been using Gemini for some pretty amazing things too (most recently a ‘semantic navigator’ for a large C++ code base).

When we were young, people who got into computing had to have some motivation: it was not considered a majority thing to do. Even more so for Logic Programming! I suspect that that situation will return: there will likely be demand for software engineers for the foreseeable future; but it will be a less attractive career path also.

16

Dear Jan,

Thank you for sharing this deeply personal update with the community, and we are incredibly relieved to hear that you are on the path to a full recovery despite the immense physical challenges and discomfort you have faced since your surgery. Your health and well-being are the top priorities right now. I am with you that diving into the code or forum can help distract from the pain and discomfort, but please don’t overdo it. The entire community stands behind you, deeply grateful for everything you have built, and we send you our warmest wishes for strength and comfort throughout your remaining treatment.

Best wishes for a prompt recovery!

17

I guess if you raise the level of abstraction in the skill so that any off-the-shelf model will reliably call that skill, then yes. Like the old OOP approach of “always code to an interface, never to an implementation”. But I was talking about using, basically, a custom model that has been fine-tuned to be better at Prolog. That way you bake extra capability into the model proper and let the model reasoning magic do its work rather than hoping it will call the correct skill.

18

Thankyou .

19

I hope you have a full recovery.

20

Sounds like it’s been a tough year. I wish things go much better for you soon!

I was wondering if you could use some help with these projects.

As for direction, I agree that user interface support is not where you want to focus. User interface kind of seems a backburner thing across the board lately. Who needs a UI when you can use English? Does Prolog offer advantages even in writing UI?

To me, Prolog is an Engine for logical computing. What would make it better is more powerful integration with other systems. The ability to trivially ask a logical query and get a logically deduced answer. Make prolog as accessible as pytorch in python, or Lapack in C. Add facilities that help the programmer who has that mixed environment.

As for LLMs they count on tool support for validating the code. Even Python and Javascript are now regularly strongly typed these days, and Prolog should be that way too. Mode and type declarations as a matter of course.

As for learning, I’m persuaded that you learn by observing and trying and doing and getting feedback, and then testing your knowledge. Excluding AI from the process just limits the opportunities to observe and get rapid feedback. But including it in the academic testing part, including homework, just encourages people to abdicate learning in pursuit of grades.