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

Retire the Abstractions

hazyresearch.stanford.edu

Post reply on HN
Print view View original

31–40 of 60 posts

Re: Retire the Abstractions

#31

Post by StilesCrisis »

raddan wrote: post #15
rryan wrote: post #5

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 te…

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…

Enjoy setting thousands of dollars on fire for fun!

Re: Retire the Abstractions

#32

Post by vatsachak »

FjordWarden wrote: post #24
vatsachak wrote: post #11

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.

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…

Abstractions aren't a burden though, they are more like a support. A good abstraction let's you write 10 programs in the time it would have taken to write one. Also, we now have "production" languages with generics and monomorphization so abstraction is easier than ever.

Djikstra has a great article as to why English language programming will always be second to a programming language. A "formal system" (edited from regular language) is the most precise way to specify things. An "abstraction" is basically a domain specific language.

The way I like to use LLMs is to build abstractions. I like to build mathematical code and ask the LLM to use it. I think that LLMs are very mathematical thinkers and they like it when they see Semigroup. And it's not hifalutin either, I'm processing calculations along DAGs with a million+ nodes in milliseconds, thanks to abstractions

Re: Retire the Abstractions

#33

Post by socketcluster »

FjordWarden wrote: post #24
vatsachak wrote: post #11

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.

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…

Many abstractions we encounter in software industry are poor abstractions which are counter-productive. I agree that we should drop those...

But we can't drop all abstractions. It's not physically possible. The AI agent is going to break logic up into files... The AI will create/impose an abstraction for each piece of logic whether we like it or not.

So saying "drop abstractions" is actually saying "let the AI decide what the abstractions should be" and unfortunately because LLMs are trained on average code, those abstractions are often pretty poor.

Coming up with the right abstractions is actually one of the main skills which AI hasn't automated and where the human brings the most value. It affects maintainability directly; including when using AI.

I've worked on projects with poor abstractions and ones with good abstractions using AI. The ones with poor abstractions require 10x to 100x more tokens and time to solve problems and implement new features. You're constantly fighting it to prevent it from coming up with nasty hacks and workarounds. Poor abstractions create the need for hacks and workarounds.

Re: Retire the Abstractions

#36

Post by jarbus »

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.

Re: Retire the Abstractions

#37

Post by epidemian »

JSR_FDED wrote: post #16

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

Claude seems to love the word "surface". I'm almost surprised to not find the verb "buy" to mean "get" in this generation.

Re: Retire the Abstractions

#38

Post by AdieuToLogic »

FjordWarden wrote: post #24
vatsachak wrote: post #11

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.

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…

Software abstractions are a reification of problem domain understanding. They embody a solution within the mathematical constraints of a programming language such that the collaborations, when done properly, appropriately reflect said understanding.

Discarding abstractions is nothing more than rediscovery of a Big Ball of Mud[0].

0 - https://www.laputan.org/mud/mud.html

Re: Retire the Abstractions

#39

Post by sublinear »

rryan wrote: post #5

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 te…

Yes exactly.

"Why not bomb every square inch?", "Why would you ever let go of the machine gun trigger?", etc.

I assume there must have been moments in the history of war when such bad and desperate ideas were seriously proposed.

The fact that we're still in this profoundly ignorant era of LLMs is embarrassing.

Re: Retire the Abstractions

#40

Post by eru »

bloaf wrote: post #29

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.

Yes. Compare also https://www.khoury.northeastern.edu/home/cmartens/Courses/74... where the abstraction itself mechanically enforces certain guarantees and contracts.
Post reply on HN