Hacker News Reader

Comment by Nition | Hacker News Reader

In a way it shows how poorly we have done over the years in general as programmers in making solved problems easily accessible instead of constantly reinventing the wheel. I don't know if AI is coming up with anything really novel (yet) but it's certainly a nice database of solved problems.

I just hope we don't all start relying on current[1] AI so much that we lose the ability to solve novel problems ourselves.

[1] (I say "current" AI because some new paradigm may well surpass us completely, but that's a whole different future to contemplate)

View on HN

> In a way it shows how poorly we have done over the years in general as programmers in making solved problems easily accessible instead of constantly reinventing the wheel.

I just don't think there was a great way to make solved problems accessible before LLMs. I mean, these things were on github already, and still got reimplemented over and over again.

Even high traffic libraries that solve some super common problem often have rough edges, or do something that breaks it for your specific use case. So even when the code is accessible, it doesn't always get used as much as it could.

With LLMs, you can find it, learn it, and tailor it to your needs with one tool.

> I just don't think there was a great way to make solved problems accessible before LLMs. I mean, these things were on github already, and still got reimplemented over and over again.

I'm not sure people wrote emulators, of all things, because they were trying to solve a problem in the commercial sense, or that they weren't aware of existing github projects and couldn't remember to search for them.

It seems much more a labour of love kind of thing to work on. For something that holds that kind of appeal to you, you don't always want to take the shortcut. It's like solving a puzzle game by reading all the hints on the internet; you got through it but also ruined it for yourself.

> I just don't think there was a great way to make solved problems accessible before LLMs. I mean, these things were on github already, and still got reimplemented over and over again.

What kranner said. There was never an accessibility problem for emulators. The reason there are a lot of emulators on github is that a lot of people wanted to write an emulator, not that a lot of people wanted to run an emulator and just couldn't find it.

"I mean, these things were on github already, and still got reimplemented over and over again."

And now people seem to automate reimplementations by paying some corporation for shoving previous reimplementations into a weird database.

As both a professional and hobbyist I've taken a lot from public git repos. If there are no relevant examples in the project I'm in I'll sniff out some public ones and crib what I need from those, usually not by copying but rather 'transpiling' because it is likely I'll be looking at Python or Golang or whatever and that's not what I've been payed to use. Typically there are also adaptations to the current environment that are needed, like particular patterns in naming, use of local libraries or modules and so on.

I don't really feel that it has made it hard for me to do because I've used a variety of tools to achieve it rather than some SaaS chat shell automation.

And can come with hidden gotchas. I remember dealing with one bit, presented as an object but I thought that was simply because it was in an object oriented language, it was simply a calculation with no state. Many headaches later I figured out it had some local state while doing a calculation, causing the occasional glitch when triggered from another thread. They didn't claim thread safety, but there sure was no reason for it not to be thread safe.

Ah yes people were making emulators because emulators weren't a solved problem...

That isn't why people made emulators. It is because it is an easy to solve problem that is tricky to get right and provides as much testable space as you are willing to spend on working on it.

It’s 2026 and code reuse is still hard. Our code still has terrible modularity. Systems have terrible to nonexistent composability. Attempts to fix this like pure OOP and pure FP have never caught on.

To some extent AI is an entirely different approach. Screw elegance. Programmers won’t adhere to an elegant paradigm anyway. So just automate the process of generating spaghetti. The modularity and reuse is emergent from the latent knowledge in the model.

> Programmers won’t adhere to an elegant paradigm anyway

It’s much easier to get an LLM to adhere, especially when you throw tooling into the loop to enforce constraints and style. Even better when you use Rust with its amazing type system, and compilation serves as proof.

Rust as a good language for LLMs. That’s interesting.

I wonder if you could design a language that is even more precise and designed specifically around use by LLMs. We will probably see this.

I view LLMs akin to a dictionary - has a bunch of stuff in there but by itself it doesn't add any value. The value comes from the individual piecing together the stuff. Im observing this in the process of using Grok to put together a marketing video - theres a whole bunch of material that the LLM can call upon to produce an output. But its on you to prompt/provide it the right input content to finesse what comes out (this requires the individual to have a lot of intelligence/taste etc....) . Thats the artistry of it.

Now that Im here Ill say Im actually very impressed with Groks ability to output video content in the context of simulating the real-world. They seemingly have the edge on this dimension vs other model providers. But again - this doesnt mean much unless its in the hands of someone with taste etc. You cant one-shot great content. You actually have to do it frame-by-frame then stitch it together.

> I view LLMs akin to a dictionary

…If every time you looked at the dictionary it gave you a slightly different definition, and sometimes it gave you the wrong definition!

Go look up the same word across various dictionaries - they do not have a 1:1 copy of the descriptions of terms.

Reproducibility is a separate issue.

Dictionaries are not a great analogy, because the standout feature of LLMs is that their output can change based on the context provided by individual users.

Differences between dictionaries are decided by the authors and publishers of the dictionaries without taking individual user queries into account.

Reply on news.ycombinator.com