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

Karpathy on Programming: “I've never felt this much behind”

twitter.com

Post reply on HN
Print view View original

111–120 of 630 posts

Re: Karpathy on Programming: “I've never felt this much behind”

#111

Post by AndrewKemendo »

rambojohnson wrote: post #58

What exhausts me isn’t “falling behind.” It’s watching the profession collectively decide that the solution to uncertainty is to pile abstraction on top of abstraction until no one can explain what’s actually happening anymore. This agentic arms race by C-suite know-nothings feels less like leverage and more like denial. We took a stochastic text generator, noticed it lies confidently, wipes entire databases and hard…

Every technical person has been complaining about this for the entire history of computer programming

Unless you’re writing literal memory instructions then you’re operating on between 4 and 10 levels of abstraction already as an engineer

It has never been tractable for humans to program a series of switches without incredible number of abstractions

The vast majority of programmers never understood how computers work to begin with

Re: Karpathy on Programming: “I've never felt this much behind”

#112

Post by shepherdjerred »

alphazard wrote: post #54

The thing that always trips me up is the lack of isolation/sandboxing that all of the AI programming tools provide. I want to orchestrate a workforce of agents, but they can't be trusted not to run amok. Does anyone have a better way to do this other than spinning up a cloud VM to run goose or claude or whatever poorly isolated agent tool?

I'm working on a solution [0] for this. My current approach is:

1. Create a new Git worktree

2. Create a Docker container w/ bind mount

3. Provide an interface for easily switching between your active worktrees/containers.

For credentials, I have an HTTP/HTTPS mitm [1] that runs on the host with creds, so there are zero secrets in the container.

The end goal is to be able to manage, say, 5-10 Claude instances at a time. I want something like Claude Code for Web, but self-hosted.

[0]: https://github.com/shepherdjerred/monorepo/tree/main/package...

[1]: https://github.com/shepherdjerred/monorepo/pull/156

Re: Karpathy on Programming: “I've never felt this much behind”

#113

Post by Der_Einzige »

Q6T46nT668w6i3m wrote: post #63
rambojohnson wrote: post #58

What exhausts me isn’t “falling behind.” It’s watching the profession collectively decide that the solution to uncertainty is to pile abstraction on top of abstraction until no one can explain what’s actually happening anymore. This agentic arms race by C-suite know-nothings feels less like leverage and more like denial. We took a stochastic text generator, noticed it lies confidently, wipes entire databases and hard…

It’s wild that programmers are willing to accept less determinism.

You can have the best of both worlds if you use structured/constrained generation.

Re: Karpathy on Programming: “I've never felt this much behind”

#114

Post by skydhash »

viraptor wrote: post #90
Q6T46nT668w6i3m wrote: post #63

Earlier quoted context omitted.

It’s wild that programmers are willing to accept less determinism.

It's not something that suddenly changed. "I'll generate some code" is as nondeterministic as "I'll look for a library that does it", "I'll assign John to code this feature", or "I'll outsource this code to a consulting company". Even if you write yourself, you're pretty nondeterministic in your results - you're not going to write exactly the same code to solve a problem, even if you explicitly try.

Contrary to code generation, all the other examples have one common point which is the main advantage, which is the alignment between your objective and their actions. With a good enough incentive, they may as well be deterministic.

When you order home delivery, you don’t care about by who and how. Only the end result matters. And we’ve ensured that reliability is good enough that failures are accidents, not common occurrence.

Code generation is not reliable enough to have the same quasi deterministic label.

Re: Karpathy on Programming: “I've never felt this much behind”

#115

Post by wiseowise »

Q6T46nT668w6i3m wrote: post #63
rambojohnson wrote: post #58

What exhausts me isn’t “falling behind.” It’s watching the profession collectively decide that the solution to uncertainty is to pile abstraction on top of abstraction until no one can explain what’s actually happening anymore. This agentic arms race by C-suite know-nothings feels less like leverage and more like denial. We took a stochastic text generator, noticed it lies confidently, wipes entire databases and hard…

It’s wild that programmers are willing to accept less determinism.

> It’s wild that programmers are willing to accept less determinism.

It's wild that you think programmers is some kind of caste that makes any decisions.

Re: Karpathy on Programming: “I've never felt this much behind”

#117

Post by skydhash »

bryanrasmussen wrote: post #81
Q6T46nT668w6i3m wrote: post #63

Earlier quoted context omitted.

It’s wild that programmers are willing to accept less determinism.

It's wild that management would be willing to accept it. I think that for some people it is harder to reason about determinism because it is similar to correctness, and correctness can, in many scenarios be something you trade off - for example in relation to scaling and speed you will often trade off correctness. If you do not think clearly about the difference with determinism and other similar properties like (rea…

Determinism require formality (enactment of rules) and some kind of omniscience about the system. Both are hard to acquire. I’ve seen people trying hard not to read any kind of manual and failing to reason logically even when given hints about the solution to a problem.

Re: Karpathy on Programming: “I've never felt this much behind”

#118

Post by NooneAtAll3 »

Aldipower wrote: post #76

I am a software developer and mainly a programmer for decades now. I love programming. I love to be "once" with the computer. I will never give this joy up. If I need to sell shoes at daytime, I will program real computer programs in the evenings. If it won't be possible with modern machinery anymore, I will take my Commodore 64. I am a free man. Edit: Corrected since/for. :-)

(for decades)

('since' takes time_point - 'for' takes time_duration)

Re: Karpathy on Programming: “I've never felt this much behind”

#119

Post by abeyer »

2sk21 wrote: post #107
xzkll wrote: post #34

Does any of you bother the fact that now you have to pay money in order to do your job? I mean AI model subscriptions. Somehow it feels wrong for me to pay for tools that are trying to replace me.

IDEs used to be extremely expensive back in the 1990s. IDEs such as Microsoft Visual Studio and IBM's Visual age for Java were quite expensive subscription as I recall. subsequently, open source IDEs like Eclipse and VisualStudio seem to have become the norm.

Visual Studio has never been open source, though some of the underlying build tools and compilers are.

Visual Studio Code is a different thing... and claims to be open source, but by intent and approach really is closer to source available.

Re: Karpathy on Programming: “I've never felt this much behind”

#120

Post by simonw »

azangru wrote: post #110
simonw wrote: post #100

Earlier quoted context omitted.

I think AI-assisted programming may be having the opposite effect, at least for me. I'm now incentivized to use less abstractions. Why do we code with React? It's because synchronizing state between a UI and a data model is difficult and it's easy to make mistakes, so it's worth paying the React complexity/page-weight tax in order for a "better developer experience" that allows us to build working, reliable software…

> Why do we code with React? ...is a loaded question, with a complex and nuanced answer. Especially when you continue: > it's worth paying the React complexity/page-weight tax All right; then why do we code in React when a smaller alternative, such as Preact, exists, which solves the same problem, but for a much lower page-weight tax? Why do we code in React when a mechanism to synchronize data with tiny UI fragments…

Yeah, I share all of those questions.

My cynical answer is that most web developers who learned their craftsin the last decade learned frontend React-first, and a lot of them genuinely don't have experience working without it.

Which means hiring for a React team is easier. Which means learning React makes you more employable.

Post reply on HN