Show HN: An Occam to Go transpiler (LLM-generated)

[dboreham]

Occam and golang share a common ancestry for their approach to concurrency, in CSP. So I've long wondered whether Occam could be successfully translated into golang.

I began this project: https://github.com/codeassociates/occam2go as an experiment to see if LLM coding could help test that idea. Also, the project seemed like a worthy challenge in light of comments I'd read around the recent Anthropic "Claude-written C compiler" announcement. Those comments said that an LLM can write a C compiler easily because there are many C compilers in its training data. Since there's little to no Occam in today's LLM training data sets (GitHub doesn't even recognize it as a distinct language) this project should be impossible for an LLM, right? (Spoiler: wrong).

Every line of code in the repo was LLM-generated. The transpiler currently builds and runs its test suite Occam programs, a number of old Occam demo/example programs and the Conway game of life Occam program from the 1988 book "Programming in Occam2". I'd be interested to hear if it can run other Occam code that may be out there somewhere. Almost all of the Occam2 language should be supported, albeit with some limitations such as PRI PAR not actually delivering priority semantics at runtime.

There's also a short article that links to the more interesting Claude sessions recorded during the project: https://codeassociates.github.io/conversations-with-claude/c...

[Rochus]

Interesting. How long did it take until the result effectively worked? What agent did you use? I recently tried to generate an Oberon to C99 transpiler in devin.ai from an existing parser and validated AST I have already implemented myself in C++, but after two days of round-tripping and the LLM increasingly entangling in special cases and producing strange code with more and more redundancy, I stopped and wrote it myself. That was a costly exercise which didn't succeed. The language was not the problem. Devin showed it understood Oberon. But it got completely confused with the different variants of arrays (fixed size by value, fixed or variable size dynamic, fixed or variable size var or value parameter) and spread redundant code all over losing track. I also tried to make it generate a Risc-V code generator, which was neither successful (bug fixing didn't seem to converge and even seemed to turn in circles).

[dboreham]

Ah, Oberon! I "learned" programming from Niklaus Wirth's Pascal book on a family vacation where I had no computer. Actually I didn't have a computer with a Pascal compiler even if I wasn't on vacation.

Anyway, I began this project while on vacation (again) then completed it while attending a conference, so the work wasn't 100% duty cycle. That said it took about a month from beginning to the current state. You can see in the linked article almost all the LLM sessions that built the project.

LLMs do seem to be a bit narcissistic as you've alluded to -- confidently declaring that it has implemented "PRI PAR" for example, but conveniently not mentioning that it only parsed the keywords and didn't in fact implement priority semantics. This reminds me of less experienced developers I've managed in the past. Loth to deliver bad news.

This project was all done with Claude. When I began I was given the Opus 4.5 model but fairly early in the timeline Anthropic enabled the new Opus 4.6 model. This was before its official release so I'm not sure if they have a rollout policy that targeted me or my project. Anyway, most of the work was Opus 4.6.

Overall I learned a tremendous amount about what today's frontier models can do: I could probably give 4-5 talks on various things I noticed, or talk for a few hours over beers. General take away was that the experience was uncannily similar to developing software as a human, or running a team of somewhat less experienced humans. A fun time to be alive for sure.