[m-users.] (cough) "AI"
Mark Brown
mark at mercurylang.org
Mon Dec 1 02:33:41 AEDT 2025
Hi Tomas,
On Sun, Oct 26, 2025 at 7:31 AM Tomas By <tomas at basun.net> wrote:
>
> Hi all,
>
> Just read this on Slashdot:
>
> | I'm a programmer who started out hesitant about AI, and at first I
> | thought all that it could do was auto-complete better.
> | Then I tried Claude Code, and it really is like having your own
> | personal junior dev assisting you're every need. Like a junior, it
> | makes mistakes, but using the *massive* amount of good code that it
> | creates, and fixing what's left, is so much faster than writing it
> | all from scratch yourself.
> https://slashdot.org/story/25/10/25/0324244/meet-the-people-who-dare-to-say-no-to-ai
>
> and wonder if anybody has tried this with Mercury?
Over the weekend I tried getting Claude to write a random maze
generator that can do square or hex mazes with a bunch of algorithms,
outputting a customized SVG file. This took ~150 non-trivial prompts
for several thousand lines of code and a thousand or so lines of
markdown documentation. Testing it thoroughly was beyond the scope of
the experiment, but the output looks pretty good to me with some quick
tests. The finished code looks pretty good, too, for the most part (if
I wanted to work on it any further I'd ask Claude to work on improving
boundary.m and render.m next). Claude put "2024" as the copyright
year, which is kinda funny. Needs more recent training data!
Transcripts are included with the project, if anyone wants to know how
it was produced. Fwiw this is genuinely how I imagined holodecks would
be programmed, except without the voice recognition :-)
https://github.com/markbrown/amaze
>
> I suspect that (1) this person uses C[*]/Java, and (2) the usefulness
> of this "AI" stuff for Mercury will be proportionally less in a
> similar magnitude as code length for same functionality, ie a factor
> ten or so.
The source code for the above project is really the Markdown, not the
Mercury. From what I've seen so far the choice of programming language
doesn't particularly matter.
As a separate experiment, I asked Claude to read the Mercury compiler
source and write a document outlining the design. The result is
attached. Most of it doesn't add more than the existing
compiler/notes/compiler_design.html file, but the "Compilation
Workflows" section looks useful.
Cheers,
Mark
>
> Anybody has any experiences?
>
> /Tomas
> _______________________________________________
> users mailing list
> users at lists.mercurylang.org
> https://lists.mercurylang.org/listinfo/users
-------------- next part --------------
A non-text attachment was scrubbed...
Name: amaze.tar.gz
Type: application/gzip
Size: 258134 bytes
Desc: not available
URL: <http://lists.mercurylang.org/archives/users/attachments/20251201/907dbf3e/attachment-0001.gz>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: COMPILER_DESIGN.md
Type: text/markdown
Size: 23738 bytes
Desc: not available
URL: <http://lists.mercurylang.org/archives/users/attachments/20251201/907dbf3e/attachment-0001.bin>
More information about the users
mailing list