Retire the Abstractions

cconvexstrictly 6 days ago 34 commentsRead Article on hazyresearch.stanford.edu

DE version is available. Content is displayed in original English for accuracy.

⚡ Community Insights

Discussion Sentiment

40% Positive

Analyzed from 959 words in the discussion.

Discussion (34 Comments)Read Original on HackerNews

bloaf•about 1 hour ago

I feel like this is the exact opposite of the conclusion I've been coming to. In an age where anyone can vibe code stuff at the drop of a hat, I want the ability to assert guarantees/contracts at a high level, and then let AI work out the details. I want to force AI to work within the confines of an abstraction, not independently of it.

jarbus•12 minutes ago

Personally I think we will just become more ambitious with our abstractions since the LLMs can generate more complex stuff at the lower level. To take the article's examples, LLMs will write kernels that fuse 3+ layers of a model, so the abstractions can enable more complex forms of kernel fusion.

gradus_ad•about 1 hour ago

Precise specs must always be given, they cannot be reasoned into existence, because they are shaped by external considerations.

No matter how intelligent the executor is, without knowledge of the relevant external context, specs will always have to be clearly defined and given.

actinium226•16 minutes ago

> The job of abstraction as a cognitive offloader is starting to retire. Agents are taking that job.

Call me when the agents can take my high level directives and write assembly.

JSR_FDED•about 1 hour ago

“First, an abstraction isn't just a way to manage cognitive load; it's a shared surface where application, reuse, and review attach.”

That is some seriously convoluted writing.

_dark_matter_•about 1 hour ago

Agreed. Turned into some ai slop quickly.

brunoborges•about 1 hour ago

If I want to not care about implementation details on an era of AI written code, abstraction is exactly what I need.

socketcluster•about 1 hour ago

We need abstractions more than ever. The real point is we should retire unnecessary abstractions.

A good abstraction is a single edged sword which simplifies the task. A mediocre abstraction is a double-edged sword. A bad abstraction is like a single edged sword with a restrictive handle and the sharp edge is facing towards you.

vatsachak•about 2 hours ago

This is such a poor idea. LLM Agents don't have taste (abstraction capabilities). They are kind of like water, they take the shape of the container they're in. They are so much powerful when you build your own framework they can work in.

FjordWarden•about 1 hour ago

That is not what the text is arguing for and it has many good ideas, dropping the abstractions but keeping the test harness is one of them. I've worked on many aspect of programming language implementation through the years and I would struggle with the abstractions of parser-generators and bytecode designed by committee like an enterprise Java developer struggles with the Hibernate ORM. Dunno what people are putting in their prompts but ask LLM to roofline and it will pursue that target like a bloodhound.

rryan•about 2 hours ago

agents are unlike humans in many ways but they have their own limitations. it's magical thinking to believe that they are able to cope with zero software abstractions, especially as a codebase increases in size and complexity

and today's agents increase codebase size and complexity much faster than humans do via traditional software engineering methods, so this is likely to hit a wall faster than if human software teams were to do this experiment.

raddan•about 1 hour ago

Just yesterday, for fun, I asked Codex to generate an “online e-commerce site” in ARM assembly. To its credit, it did actually generate a program that served up a webpage over a socket, but it really did not do what I asked. The program still pulled in a large number of shared libraries (something I’ve never really thought to try in assembly). And… it was not actually a functioning e-commerce site. Iterating on that initial prompt proved painful—the program was extremely brittle and now I had to review and talk about ASSEMBLY. Maybe we can dispense with abstractions someday, but holy cow, not yet. I would much rather write an e-commerce platform in C than try to vibe-assembly my way to one.

chowells•about 1 hour ago

Following this argument to its natural conclusion, we should tell LLMs to generate the binary directly. It's still an abstraction, but it's the lowest level we can go to on current consumer hardware.

I don't think raw machine code (not even assembly) is the best form to reason about program logic. It just takes too many steps to execute sophisticated processes to keep them all in your head at once - or keep them all in an LLM context at once.

noncoml•about 1 hour ago

I kind of angree with the anrgument that for an ideal AGI abstractions are not needed. It would write everything perfectly without even needing a programming language. It would know everything to the byte and would create perfect machine code meeting all the requirements as perfect as it’s possible.

But the reality is different. First of all LLM were trained on current data, with the abstractions we currently use.

Secondly they suffer they same problems we do, their context size is way too small to just simply ignore abstractions.

nostrebored•about 2 hours ago

it sounds like a bad abstraction. ime llms are really bad at reasoning through efficiency and utilization problems. they fail at scheduling and bin-packing for the same reason. it's actually difficult, multivariate, and not great.

i would be shocked if a well designed framework were less efficient than "bespoke" clankercode for low-level work

taftster•about 2 hours ago

This is probably true. Today. But I think we're finding the problems LLMs are solving to be both paradoxically predictable but surprising at the same time. Not saying you're wrong, but scheduling and bin-packing seem like cards that will eventually fall to a bespoke prompt.

jrflo•about 2 hours ago

I mean, the post was written by a Stanford CS lab, so I'm inclined to believe that they know what they're talking about and are not just bad at creating abstractions.

rryan•about 2 hours ago

I know nothing about the PhD candidate and professor who co-authored this, but I don't think this statement makes sense in general.

Typically CS labs at universities contain people who have not spent a significant amount of time exposed to large industry codebases and the corresponding complexity. I think the post would have more credibility coming from e.g. the platforms team at a tech company with a monorepo.

jrflo•about 1 hour ago

There is something to be argued about industry vs academic experience but this post has nothing to do with large industry codebases

JMiao•about 1 hour ago

sounds like it might help to know something about the phd candidate and professor

vatsachak•about 2 hours ago

The machine learning community decided to choose Python as the main language, which costs probably tens of millions of dollars in bugs every year due to it not being type checked (astral sh is fixing this though)

raddan•about 1 hour ago

Hasn’t mypy been a thing for years already?

The main problem with Python is that, if you’re not doing your work in highly optimized numeric libraries (which are usually written in C), then you’re paying terrible overheads to use the Python interpreter. Type checking doesn’t help with this because Python is dynamically typed but static types could in principle. Is that what you mean?

nostrebored•about 2 hours ago

why?

jrflo•about 1 hour ago

I think it's generally fair to assume that you don't become a Stanford CS professor by being bad at writing code and creating abstractions, and that the average professor (let alone one at a prestigious university) is more knowledgable than your average HN commentor

odyssey7•about 2 hours ago

When will we learn?

JMiao•about 1 hour ago

but what have we learned? roughly quoting the last scene in "burn after reading"

cia boss: what did we learn, palmer? cia officer: i don't know, sir. cia boss: i don't fkin know either. i guess we learned not to do it again.

what-the-grump•37 minutes ago

In two words, accept slop.

No.