https://www.hytradboi.com

  ╭⬟╮

The joke was the assistant is a cat who is constantly sabotaging you, and you have to take care of it like a gacha pet.

The seriousness though is that actually, disembodied intelligences are weird, so giving them a face and a body and emotions is a natural thing, and we already see that with various AI mascots and characters coming into existence.

[1]: serious: https://github.com/mech-lang/mech/releases/tag/v0.3.1-beta

[2]: joke: https://github.com/cmontella/purrtran

Here's the current version of my literate programming ideas, Mechdown: https://mech-lang.org/post/2025-11-12-mechdown/

It's a literate coding tool that is co-designed with the host language Mech, so the prose can co-exist in the program AST. The plan is to make the whole document queryable and available at runtime.

As a live coding environment, you would co-write the program with AI, and it would have access to your whole document tree, as well as live type information and values (even intermediate ones) for your whole program. This rich context should help it make better decisions about the code it writes, hopefully leading to better synthesized program.

You could send the AI a prompt, then it could generate the code using live type information; execute it live within the context of your program in a safe environment to make sure it type checks, runs, and produces the expected values; and then you can integrate it into your codebase with a reference to the AI conversation that generated it, which itself is a valid Mechdown document.

That's the current work anyway -- the basis of this is the literate programming environment, which is already done.

The docs show off some more examples of the code, which I anticipate will be mostly written by AIs in the future: https://docs.mech-lang.org/getting-started/introduction.html

Although, we've since moved to having several distinct data structures which conceptually map to tables, but implementation and syntax-wise have differences (mostly for performance).

BTW Basis was a good idea, I remember reading about Nondeterministic replay is a big problem on platforms like ROS.

It makes sense that the first thing I'd get to the front page of HN is what amounts to a bad joke :P

https://github.com/mech-lang/mech https://www.hytradboi.com/2022/i-tried-rubbing-a-database-on...

Not all features are implemented yet but we are getting there!

I also see two graphics, and several formal mathematical expressions. You can't modulo away all the not-natural language and then claim natural language alone was sufficient. I presume these things were added by the authors to increase clarity of the problem statement, and I agree with them. They used formal languages to specify all the important parameters in an unambiguous way, which was the right call! Otherwise we would all be left wondering at the semantics.

Anyway, I don't think this really responds to my point, because competition prompts are designed to be self-contained problem statements that are as clear and unambiguous as possible for competition purposes. And in this case, they switched to speaking in a formal language when being precise and unambiguous was most important.

On the other hand, my statement was about the task of programming, which typically involves solving ill-defined problems with specifications and requirements that shift over time. I've been in programming competitions, I've also been a programmer, and I don't find one to be really related to the other.

Well LLMs finally offer that, and what they are proving is what programmers have known for decades -- natural language is a terrible way to specify a program to a computer. So what is happening in the LLM world is they are reinventing programming languages and software engineering. They're just calling it "prompt engineering" and "context engineering".

What this tell us is that natural languages are not only not sufficient for the task of programming, to make them sufficient you need to bring back all the properties you lost by ditching the programming language. Things like reliability, reproducibility, determinism, unambiguity are thrown away when you use an LLM, and context engineering / prompt engineering are ways of trying to get that back. They won't work well. What you really want is a programming language.

Indeed, it is, and that's the point! Being interfaces to computers for humans, programming languages sit at the intersection of computer science and humanities. Lots of people like to treat programming languages like they're math class, but that's only half the picture. The other half is usability, ergonomics, learnability, and especially community. Not to mention the form of the language is all about aesthetics. How many times has someone on Hacker News called a language "beautiful" or "ugly" referring to the way it looks? When people praise Python they talk about how easy it is to read and how pleasant it is to look at compared to C++. Or look at what people say about Elm error messages versus C++ template errors. Actually a lot of what's wrong with C++ could have been averted if the designers had paid more attention in art class.

> But these days we would need greater insights into higher-level language semantics and inherent tradeoffs to guide language-design and language evolution.

Here's a talk that argues there's much more fertile languages ground for ideas outside of the "programming languages are math" area, which has been thoroughly strip-mined for decades:

https://medium.com/bits-and-behavior/my-splash-2016-keynote-...

This author takes the perspective that programming languages are much greater than the sum of the syntax + semantics + toolchain + libraries, and treating them as such is limiting their potential.

As for me, I brought some eve-y ideas to my language project: https://github.com/mech-lang/mech

It didn't get far enough to be "used" in a production sense. There was enough interest and people were playing around with it, but no real traction to speak of. Frankly, language projects are difficult because these days they have to be bootstrapped to a certain size before there's any appreciable use, and VCs are not patient enough for that kind of timetable.

Here's a postmortem Chris gave about all that: https://www.youtube.com/watch?v=WT2CMS0MxJ0 / https://www.youtube.com/watch?v=ThjFFDwOXok

> I'm assuming this isn't your first go at writing a compiler?

Not quite, the first real language I worked on was called Eve: https://witheve.com

The code is here: https://github.com/mech-lang/mech/tree/main/src/core/src/pro...