[svachalek]

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. As many compile time checks as possible (good for humans, even better for machines with limited context)

3. Maximum locality. That is, a feature can largely be written in one file, rather than bits and pieces all over the codebase. Because of how context and attention work. This is the one I don't see much in commercially popular languages. It's more of a declarative thing, "configuration driven development".

[gavmor]

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.

[svachalek]

Ha. It's a thought, at least. I've been programming for about 45 years and have seen the industry go through idioms like fashion. I remember the source to one popular video game, I think it was Quake, was organized into 26 files. Everything was located based on the first character of its name.

One idea for isolating features was "cross cutting" and "aspect oriented programming" that never caught on but I've always thought it was under-explored.

My day job is collecting a type of analytics for a major global company. Every new point of data involves changing about 1 line in about 10 different applications that talk to each other, sometimes adjusting schemas and report formats as well. Takes weeks to coordinate the rollout. It's super tedious. But, perhaps there's a prompt that tells the models how to do this whole process without human intervention. And that would be saved as a skill file, that provides the needed cross-cut across many files/applications/schemas/repos, letting the code live in conventional organization.

Hard to say. We're still in early times, I think.

[imtringued]

Well, Rust does fulfill these to a reasonable degree. There is obvious room for improvement, but the vast majority of languages don't even bother being a Rust successor. Instead, they take a step back and decided that what Rust is doing is too much, e.g. Zig. It's kind of irritating that everyone and their dog is coming up with a new programming language that barely changes anything when there are so many low hanging fruit. The vast majority of programming languages that people are coming up with could have been language subsets, extensions or alternative runtimes for existing languages.

[Octoth0rpe]

> 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 just has to read the equivalent of a .h file to start using a library.

[preommr]

> 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.

[lesam]

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?

[gavmor]

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?

[still_grokking]

Why would you need "header files" when a LSP server can give you just the outline of some file?

[drivingmenuts]

> all too human coding agents

There is no actual thought occurring. Arguably, we can say the same about a lot of humans at any given moment, but with machines there never is. It's all statistics.

[svachalek]

It's statistics based on human coding patterns and human thought patterns (encoded in natural language) though. It's not I AM MODEL 527R1, I AM TOTALLY LOGICAL AND DO NOT UNDERSTAND YOUR HUMAN EMOTIONAL STATES.