Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Vera: a programming language designed for machines to write

github.com

Post reply on HN
Print view View original

31–40 of 105 posts

Re: Vera: a programming language designed for machines to write

#31

Post by preommr »

Octoth0rpe wrote: post #19
svachalek wrote: post #16

Earlier quoted context omitted.

Yeah it seems based on 2023 research which is ancient, back when we didn't have coding agents at all, and on some 1980s sci fi concepts of "how machines think" (beedeeboop) rather than the all too human coding agents we have. If I had to design one of these, I'd go for: 1. Token minimization (which may be circular, I'm sure tokens are selected for these models at least in part based on syntax of popular languages) 2.…

> That is, a feature can largely be written in one file, rather than bits and pieces all over the codebase. This seems to be at odds with the goal of token minimization. Lots of small files that are narrowly scoped means less has to be loaded into context when making a change, right? Throwing out another idea: I wonder if we could see some kind of equivalent of c header files for more modern languages so that an llm…

> This seems to be at odds with the goal of token minimization. Lots of small files that are narrowly scoped means less has to be loaded into context when making a change, right?

my solution (as someone that's building something tangential) is to use granular levels of scope - there should be an implicit single file that gets generated from a package at a certain phase of the static tool processing. But the package is still split into files for flexibility and DevEx (developper experience). Files/Folder organization is super useful for humans. For tooling, the pacakge can be taken collected together, and taken as a single unit, but still decomposed based on things like namespace, and top-level definitions that define things like classes, specifications, etc. That way the tooling has control over how much context to pass in.

Re: Vera: a programming language designed for machines to write

#32

Post by davidw »

still_grokking wrote: post #29

Why would anybody use a vibe-coded and vibe-desinged language which effectively does not exist yet instead of an established one with such features, like Scala? https://arxiv.org/html/2510.11151v1

Also isn't it an advantage for LLM coding to use an existing language that has a lot of code that LLM's have already stol... I mean ingested?

Re: Vera: a programming language designed for machines to write

#33

Post by still_grokking »

solomonb wrote: post #10

I think Hindley Milner (for decidability) + Linear Types (for resource management) + Refinement Types (for lightly asserting invariants) + Delimited Continuation based Effects (for tracking effectful code) + Unison style Content Addressability (for corralling code changes, documentation, and tests) would make a really nice language for an LLM.

That's in large parts Scala.

It doesn't have Hindley-Milner type inference, but it has very strong type inference.

We will get linearity soon thanks to and as part of the Capybara[1] effort.

Refinement types are already long a reality.

The whole new effect tracking thing is based on delimited continuations.

The Unison style content addressability comes up now and then, maybe it will become a reality at some point. It's though mostly not a language thing but more a build system thing.

Scala is already great for for LLMs also for other reasons:

https://arxiv.org/html/2510.11151v1

[1] https://2025.workshop.scala-lang.org/details/scala-2025/6/Sy...

Re: Vera: a programming language designed for machines to write

#34

Post by still_grokking »

unignorant wrote: post #4

This isn't my project, but I shared it here because it has a few important ideas I've been thinking about in my own work. Effect type systems in particular are a really good fit for LLMs because they allow you to reason very precisely about a program's capabilities before runtime (basically, using the type system for capability proofs). This helps you trust agent-created code (for example, you know it can't do IO), o…

You're looking for Scala… ;-)

https://news.ycombinator.com/item?id=47957121

Re: Vera: a programming language designed for machines to write

#35

Post by still_grokking »

hgoel wrote: post #27
hyperhello wrote: post #25

Earlier quoted context omitted.

But that’s because null is a static type. Zero isn’t a static type. How can I know if a calculation produces zero if I can’t predict the result of it at compile time?

I think it's about if there's a possibility of it being zero. Of course there's no way to tell at compile time that a value will definitely be zero. So, in pseudocode int div(int a, int b): return a / b; Would probably be a compile time error, but int div(int a, int b): return b == 0 ? ERR : (a /b); Would not, or at least that's what I'd expect.

Or it's just some AI brain fart…

The whole things looks vibe-coded, and vibe-designed.

Re: Vera: a programming language designed for machines to write

#36

Post by fragmede »

davidw wrote: post #32
still_grokking wrote: post #29

Why would anybody use a vibe-coded and vibe-desinged language which effectively does not exist yet instead of an established one with such features, like Scala? https://arxiv.org/html/2510.11151v1

Also isn't it an advantage for LLM coding to use an existing language that has a lot of code that LLM's have already stol... I mean ingested?

Depends. A professor told me AI is really good at writing bad pandas code because it's seen a lot of bad pandas code, so starting from scratch isn't necessarily the worst thing.

Re: Vera: a programming language designed for machines to write

#37

Post by still_grokking »

davidw wrote: post #32
still_grokking wrote: post #29

Why would anybody use a vibe-coded and vibe-desinged language which effectively does not exist yet instead of an established one with such features, like Scala? https://arxiv.org/html/2510.11151v1

Also isn't it an advantage for LLM coding to use an existing language that has a lot of code that LLM's have already stol... I mean ingested?

Exactly! Completely new languages without large amounts of reference material are terrible for LLMs.

Re: Vera: a programming language designed for machines to write

#38

Post by gavmor »

svachalek wrote: post #16
rtpg wrote: post #12

The lack of naming seems to indicate a fundamental misunderstanding of how LLM coding agents are successful, and just makes me doubt anything about this project being useful and workable.

Yeah it seems based on 2023 research which is ancient, back when we didn't have coding agents at all, and on some 1980s sci fi concepts of "how machines think" (beedeeboop) rather than the all too human coding agents we have. If I had to design one of these, I'd go for: 1. Token minimization (which may be circular, I'm sure tokens are selected for these models at least in part based on syntax of popular languages) 2.…

Features written in one file, rather than "cohesive" modules with a single "responsibility" in one file?

So, orthogonal to the accepted, common code organization idiom (no matter how infrequently adhered to)?

Fascinating! Just the other day I decomposed a massive Demeter violation into stepwise proxying "message passing." I was concerned that implementing this entire feature—well, at least a solid chunk of it— as a single, feature-scoped module would cause the next developers eyes to glaze over upon encountering such a ball-of-mud, such a dense vortex of spaghetti.

But, as I drove home that evening, I couldn't help wonder if I hadn't, instead, merely buried the gordian lede behind so many ribbons of silk.

Re: Vera: a programming language designed for machines to write

#39

Post by gavmor »

lesam wrote: post #26
Octoth0rpe wrote: post #19

Earlier quoted context omitted.

> That is, a feature can largely be written in one file, rather than bits and pieces all over the codebase. This seems to be at odds with the goal of token minimization. Lots of small files that are narrowly scoped means less has to be loaded into context when making a change, right? Throwing out another idea: I wonder if we could see some kind of equivalent of c header files for more modern languages so that an llm…

I think AST aware code reading is criminally underused by agents - you don't need a header file if you can see a listing of all the functions in a library. Similarly, I don't read the whole file a function is in while editing it in an IDE, why should a coding agent get the whole file polluting its context by default?

Check out Ataraxy-Labs/weave for AST-aware git merges.

But, I wonder, do AST-aware tools cleave to the LLM training manifold the way coding-tutorial slop does?

Re: Vera: a programming language designed for machines to write

#40

Post by kgeist »

2001zhaozhao wrote: post #8

> There are no variable names. @Int.0 is the most recent Int binding; @Int.1 is the one before. You already lost me here. There's a reason variable names are a thing in programming, and that's to semantically convey meaning. This matters no matter whether a human is writing the code or a LLM.

>The short answer is that variable names are one of the things that confuses LLMs rather than helps them. Unlike with humans, names undermine a model's efforts to keep track of state over larger scales. Models confuse similarly named variables in different parts of the codebase easily

So I wonder, doesn't this apply to function names too, which the author keeps in? I've seen LLMs use wrong functions/classes as well.

I think a proper harness, LSP and tests already solve everything Vera is trying to solve. They mostly cite research from 2021 before coding harnesses and agentic loops were a thing, back when they were basically trying to one-shot with relatively weak models (by modern standards)

Post reply on HN