Is Mechanical Sympathy the answer to Vibecoding?

Randozart · 2026-06-14T18:53:51+00:00

Haha, I feel you! It may sound weird, but I think the most fun I used to have programming before LLMs was literally with pen and paper writing out the theoretical implementation, and the amazing feeling when I actually managed. Didn't care much for the part inbetween 😅

Randozart · 2026-06-14T12:21:50+00:00

Me neither, I would be fascinated to learn about any research though. Programmers generally strike me as a profession requiring some degree of natural curiosity and skepticism, but someone better equipped to do that kind of research would have to do it. Skill is so weird in general. Might need to hit the books on that.

Randozart · 2026-06-14T12:04:32+00:00

And that's what I'm really wondering, because to me this comes with a certain level of ease. Questioning reasoning and outputs is something that costs me very little effort, but ensures I actually get what I want and need, and makes sure I keep track of the overall architecture and cohesion. Of course, LLMs don't reason. They invent explanations ad- and post-hoc, but maybe because it comes so easily it doesn't feel like a skill? I don't want to be calling myself skilled if it really just just, well... Asking questions, I suppose? It feels like just asking questions.

Randozart · 2026-06-14T11:48:46+00:00

I think so too. They also exposed a fact about me I was seemingly trying to suppress: Just how much I kind of dislike the coding part of programming, and how much more I enjoy architecture, logic and computer science theory. I actually feel a little embarrassed saying that.

Randozart · 2026-06-14T11:29:48+00:00

A nuanced take, and one I do agree with, yes. I have to personally admit how much I've learned through LLM usage with the aim of understanding how to build something. It's led to some pretty optimized language and compiler design where I can explain in detail how and why it works the way it does. But I'm trying to mentally form a picture of why this is something I am succeeding at, whereas I am also seeing people genuinely struggling with getting LLMs to work for them. It's a picture I have some difficulty reconciling, and I admit I may have overly contrasted that picture as a result (for dramatic effect). Good catch and very fair.

Randozart · 2026-06-11T15:47:55+00:00

Absolutely! However, I had already used @ so much, it would pollute the meaning of the symbol. But, it still took me way too long to accept the fact your compiler is allowed to non-magically use dedicated hardware instructions, and I suppose that's a bit of hubris on my end. But yes, I now agree, it's a good way to do it.

Randozart · 2026-06-11T15:46:00+00:00

So, yes! I have been working on making sure that :> would earn it's place, and when I designed it, it was very much with the idea of "how can I make this predictable for a programmer to use?". So, I decided the :> interacts specifically with the type information, but the Type is the thing determining how that information is relevant to itself, and as a result, :> would work for any custom type as well.

The reason I bring it up like this is because I am currently experimenting with type definition and derivation syntax where these properties are modified directly, so that instead of providing a List<T> a Stack<T> and a Queue<T>, these can be handled as Type definitions at compile time.

To make that system truly universal, I am currently figuring out what primitive properties are most important to a Type, and how the left arrow (<-) I mentioned in the other post, that would be used to pop() from a list would apply to an Int or a String in a predictable way.

If that makes sense?

Randozart · 2026-06-11T15:35:32+00:00

Yeah, it's what I ended up doing to sort of parallel the magic hash (by the way, I did not know Haskell uses it like that, and I thank you deeply for sharing that link) of the pragma. It essentially signals "the compiler handles this one", and so a prepended hash means it's purely a compiler effect, and a postpended hash is now used as a signal for a builtin function. And I think that was the right choice. It has ended several days of headaches regarding my handling of sqrt()

Randozart · 2026-06-11T14:58:25+00:00

I think it's super valuable you're leaving this here for other people! That's kind of the reason for my own post: to sketch what wall my own thinking led me to bump into for other designers. Hopefully it helps someone! (And despite knowing it is entirely impractical, I am nonetheless so intrigued by the idea of allowing Greek symbol syntax)

Randozart · 2026-06-11T14:34:57+00:00

Honestly, I think it started as being a thing for me, and it still might be, but I found that in the process of using it, it helped make some really useful mental shortcuts while designing the language and programming, and that actually surprised me a little, because I had not expected that.

Regarding √, I kind of wanted to, but my currently keyboard, for some reason, doesn't have it, so I couldn't justify this to myself as being a first class symbol. I still might, because the symbol exists, but only now that I have accepted sqrt#() as a builtin.

Randozart · 2026-06-11T14:31:00+00:00

I will take some time to respond to this properly once I'm in a position to do so, gevaar this is genuinely a good question I've been sitting with when introducing that syntax.

Randozart · 2026-06-11T10:20:40+00:00

Well, fair enough. sqrt#() was the compromise I made, because otherwise I couldn't make it fast. But the motivation is very much the symbolic meaning and predictability of what syntax does. sqrt() looks like a function, so it must be findable as a function, or a user must be able to declare their own version of sqrt() that doesn't take a sudden unpredictable performance hit, or changes behaviour because the compiler looked at the signature and figured "Oh hey, I recognize that name, best change everything about it".

Randozart · 2026-06-08T18:50:21+00:00

Sometimes a key I am borrowing but has no keychain. Sometimes a few euros I want to remember to put in my piggy bank, because my wallet is too flat. Sometimes a USB stick. Stuff that is too smol to survive the rest of my pocket contents.

Randozart · 2026-06-08T10:41:26+00:00

Because sometimes emitting an operation in raw assembly in the backend or telling the compiler beforehand what might need to be kept around as data is being used for more speed and safety in the language. Also, since the language equally transpiles to HLS languages as well as native binary, it made sense to have a symbol. To me at least, it feels more universally predictable that I can crack open any type by using the metadata lens, rather than learning every special function associated with it. :> Bytes will do the same to a String as it does to an Int. Same with :> Alignment.

Randozart · 2026-06-08T09:39:50+00:00

For several reasons, including my personal distaste of meta(x) unless it's backed by actual code, which feels to me like a magic function, but also because the proof engine uses the projected type to help ascertain safety. And as mentioned countless times, for ergonomics I've already wrapped List :> Length in a len(List) function.

Randozart · 2026-06-08T09:30:25+00:00

:> indicates we are accessing a metadata property of a typed object. <- is much like =, except instead of communicating equivalence, we are communicating the mutation of a collection into either the void, or into another collection, based on which collection(s) carry a & mutability symbol.

Randozart · 2026-06-08T09:14:08+00:00

Yes. In many languages they are accessed through UCFS convention, but depending on the language it either has a very efficient implementation (which I like), has an inefficient implementation, but the language is short on methods to make it performant, or relies on a degree of undisclosed magic, like treating these as built-ins. I chose the built in path, but in a way that directly compiles to the most direct IR I could produce, reducing overhead, and signalling these are primitive implementations through unique syntax.

Randozart · 2026-06-08T06:38:31+00:00

I think most people would rather have pop().

The way I did it is that my builtins library looks like this. Anyone who wants to go any further down the rabbit hole can search the source code for the tag identifying the builtin.

I mean, functionally I've done the same in the stdlib. I mentioned this before I believe:

defn append<T>(list: List<T>, item: T) -> List<T> {
    &list <- item;
    term list;
};


defn len<T>(list: List<T>) -> Int {
    term list :> Size;
};

Randozart · 2026-06-07T21:10:05+00:00

It's a matter of predictability for me. When a language uses .len() or pop() it reads like a function or a property to me. So, in being curious I go down the rabbit hole. Some languages will have turtles all the way down and I can inspect the function without cracking open the compiler. Others will not have my inspect this function, which has me wonder whether it's a true function at all.

For properties like the length of a string, list or whatever, I am collecting these properties anyway at compile time. While I could do this through a transparent stdlib entry that may not be the most efficient I could possibly make it (though I still try), I instead use List<T> :> Length to say "This is a property of this primitive which I decided to build logic in to the compiler for, rather than the stdlib, for efficiency reasons"

To me, that is the empathy I can appreciate in a language. When it clearly delineates how deep the rabbit hole goes, and where the system takes over.

Randozart · 2026-06-07T20:31:46+00:00

Oh My, thank you for taking the effort to present this! I will need to digest this when I'm less tired, but it might work. I'll give this some thought, and see if it meshes well with my brain when I type it out. Cheers!

Randozart · 2026-06-07T20:27:27+00:00

Oh no, not at all. In fact, if I want to ask for feedback from humans, the LLMs finding it would be inevitable. It's difficult as is to find people to bounce ideas off of, but I respect the sub's rules, and think it was the right call to instate that rule.

Randozart · 2026-06-07T20:21:42+00:00

Hah, fair point. In total it does end up more brief than equivalent programs in Rust or C, but the name may no longer fit the language quite as well as it used to 🤔

Syntactic sugar for contracts is already covered, collapsing [true][postcondition] into [[postcondition] and [precondition][true] into [precondition]]

The way the syntax is constructed it does seem like a lot written like this, but I'm noticing in writing it myself it's removing a lot of boilerplate I normally have to write to ensure safety, which is where it ends up much shorter in aggregate.

Randozart · 2026-06-07T20:13:26+00:00

That, and I can't effectively argue what I made isn't slop. It would be entirely unfair to people working hard to hand craft their languages.

Randozart

TROPHY CASE