Live data from Hacker News

Retire the Abstractions

hazyresearch.stanford.edu

21–30 of 60 posts

Re: Retire the Abstractions

#21
post #14
post #10

Earlier quoted context omitted.

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.

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

Well, they’re also probably not scaling up in the same way as any of the commercial AI offerings, let alone the frontier labs. Faculty at Stanford probably have some decent hardware to play with, but they do not have data centers. I don’t doubt that they know their way around CUDA/PTX, but it’s not clear how relevant their message is given that their research code is very likely not being deployed in production, or at scale.

Re: Retire the Abstractions

#22
post #8

When will we learn?

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.

Re: Retire the Abstractions

#23
post #4

Earlier quoted context omitted.

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.

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)

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?

Re: Retire the Abstractions

#24

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 in their prompts but ask LLM to roofline and it will pursue that target like a bloodhound.

Re: Retire the Abstractions

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

Re: Retire the Abstractions

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

Re: Retire the Abstractions

#27
post #23

Earlier quoted context omitted.

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)

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?

I mean yes the python interpreter is not great, but I'm talking about bugs created by accidentally passing a negative number where a positive one should go, using a tensor of the wrong size etc.

I don't have any ml experience with python only numerical libraries and I always have to be careful what I'm doing otherwise an experiment can go Kaput. Types stop that.

Re: Retire the Abstractions

#28
post #13

Earlier quoted context omitted.

why?

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

Professors have no reputation for writing good code. Academic code is fairly notorious for being under abstracted, hard to follow, messy, etc.

If a passerby told me this story I’d have the same guess though!

Re: Retire the Abstractions

#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.
Post reply on HN