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

The End of Programming

pauldix.com

Post reply on HN
Print view View original

91–100 of 124 posts

Re: The End of Programming

#91

Post by smitty1e »

I can support the "End of Programming" thesis from the standpoint that no one is still doing punch cards in binary against the CPU.

Higher level languages are great, but we all owe RSM a debt of gratitude for the FSF and keeping the source code within public view.

These closed AI models are akin to compiler vendors, in my view.

It doesn't take much economic analysis to realize that we disdain living on the vendors' various plantations.

That is, the "AI is just a tool" argument is subordinate to the need to keep freedom free.

End of rant.

Re: The End of Programming

#92

Post by kodoman »

dogcomplex wrote: post #48
znnajdla wrote: post #22

The article gives the example of Bun's successful Zig to Rust of why this is the end of programming. I think that rewrite is a perfect example of why it's NOT the end of software engineering. A non-programmer could not have prompted AI to do that rewrite, and in fact a non-programmer would not have even conceived of the idea of doing that rewrite in the first place. Somebody is still needed to 1. come up with the ide…

Yes but those are all semantic tasks which can be done and understood in time by the next iteration of models training at that meta-level of architectural analysis. AI deeply understands what Bun, Zig and Rust are, how they work, can conceive of the before and after architecture (probably the hard step here), can conceive of the goal of the rewrite, and can verify (using Lean and machine-checked proofs of the before…

I feel like leaving it to decide everything would not produce a good end product. It feels like just having it decide how GC should work, how the function call stack should work or any of these rather simple but actually requiring lots of decision and thinking how things fit together (and pick a good solution out of many seemingly good solutions that can come back to bite you), couple this with the tendency for AI agents to tend towards adding new code and building over features I don't think you end up with a good solution.

On formal verification having done it only in an academic sense and looked over at projects like seL4 and quite interested in that project. It feels like actually proving useful properties of programs for real programs even ones with well defined domains and easier to model such as interpreters or compilers it seems that it will just prove theorems about properties that hardly matter or don't even matter at all. See how bad it still tends to be when trying to get it to write tests.

I would be interested to know if their has been an agent that has actually utilized formal methods such as Lean or Coq or Isabella to prove properties of programs in an automated way as you suggest, I have only seen it proving mathematics and or searching for counter examples, not writing Curry-Howard style proofs.

Re: The End of Programming

#93

Post by Ekaros »

imhoguy wrote: post #86
HexDecOctBin wrote: post #15

Earlier quoted context omitted.

And who will fix the slop? Not Silicon Valley programs being paid $200K or whatever. We stand on the verge of a golden age of outsourcing in software which will make all previous phases of outsourcing look like trial runs.

I come to conclusion that software source code will be kind of ephemeral output, like binaries are today. If you are not happy about slop accumulation, you take still valid functional requirements, docs, API contracts, test cases, some selection of still valid prompt history, and let better agent rewrite everything from scratch. Even if the session costs $200K one time - that is very cheap even for SMEs.

I really worry about "regressions" in that model. If you regenerate everything all the time. Do you keep issues fixed or constantly end up introducing new issues. Well it might work with absolute total test coverage. Which seems to be very high bar to reach.

Re: The End of Programming

#94

Post by xtracto »

dogcomplex wrote: post #83

Programming with AIs requires new architectural structures designed around the all-too-small context windows of the AIs themselves. Highly modular, highly semantic, highly traceable, good at deleting and refactoring/removing things they no longer need, good at identifying the core truths/principles/designs they need to uphold, good at recognizing what is mere interface from architecture from data. This is the great o…

Great take, two things come to mind:

First, the "all too small context window" reminds me of GetRight, mp3pro and a lot of other artifacts we invented in the 80s and 90s to deal with the limited internet bandwidth of then. We created artifacts to "achieve things" with the limited technology at hand. In 2026, ive got a 500 mbps simetric home connection. The same way, RAGs and all related stuff are artifacts to help us deal with today's tech limitations. In 10 years, it will be a non issue.

Second, I agree on the architectural patterns. Building (commercial) software will become a real Engineering career. Engineers will define the blueprints of the functionality of software, as well as the "materials" (technology, practices to use, measurement limits, ranges, etc) of tge software to be built, the same way Architects and Civil Engineers do when designing a Skyscraper or a bridge to be built.

As you very well put it, there will still be the "artisan" programmer, who builds whatever code by hand. But that will be as a hobby or some personal project.

Re: The End of Programming

#95

Post by cafebabbe »

kodoman wrote: post #76
cafebabbe wrote: post #3

I don't know if this is the end of programming, but i can clearly observe the gradual end of expertise in my company - people slowly forgetting architecture, principles, and how stuff works in general, in favor of code delivery speed. And without expertise you end up asking stupid things to a token producer machine, however godlike it can be. It's hard not to extrapolate...

I really do think that people who rely on AI to make architectural dissensions will simply have a bad time later down the road when it turns out that the AI made a stupid decision. I have noticed myself a 3 months or so ago sometimes asking AI questions for things that I knew the answer to (but had to think about) and my solution would have been better. Once I realized it I realized how despite always telling my self…

Same mental state i'm now, back from holidays. AI-free diet for a while. Nothing scarier than realizing that "smart" laziness was simply hiding the beginning of incompetence.

Re: The End of Programming

#96

Post by robertlagrant »

I spend more time writing tests than writing code. Saying "You don't need to write code any more, only think, design, and write 'verification'" is interesting of course, but compacts a smaller percentage of the total time to make a feature than listeners might think.

However my recent years have been in Python, which perhaps is high level enough to require a large amount of code writing. Maybe in C++ it's a bigger gain?

Re: The End of Programming

#97

Post by znnajdla »

kodoman wrote: post #92
dogcomplex wrote: post #48

Earlier quoted context omitted.

Yes but those are all semantic tasks which can be done and understood in time by the next iteration of models training at that meta-level of architectural analysis. AI deeply understands what Bun, Zig and Rust are, how they work, can conceive of the before and after architecture (probably the hard step here), can conceive of the goal of the rewrite, and can verify (using Lean and machine-checked proofs of the before…

I feel like leaving it to decide everything would not produce a good end product. It feels like just having it decide how GC should work, how the function call stack should work or any of these rather simple but actually requiring lots of decision and thinking how things fit together (and pick a good solution out of many seemingly good solutions that can come back to bite you), couple this with the tendency for AI ag…

> I don't think you end up with a good solution

More precisely, a "perfect solution" doesn't exist. It's all tradeoffs given your goals. Someone needs to make the decision: 1. which tradeoffs are worth given your goals 2. which goals are worth defining or redefining. And do that effectively, you need to understand the problem, which goes back to engineering.

Re: The End of Programming

#98

Post by nasretdinov »

tyingq wrote: post #74
nasretdinov wrote: post #18

LLMs are scarily good at translation, whether between natural or between programming languages. Also very good at re-implementing the stuff that has been provably done before. And, arguably, 90-95% of writing code is exactly that.

I'm no expert, but it feels like this exact thing is how it ends up eating itself. For two reasons. - Eventually the universe of "provably done before" is now mostly LLM genned code. So the training data quality starts a slow decline. - That it's "good enough" now for 90+% of the work kills the pipeline for any new human software experts. So they never gain the experience and insight to be able to steer the AI to pro…

IMO that's precisely why software engineering is going to become even harder than it is right now -- all the "easy" stuff is semi-automated, so now you have to spend even more time and energy "drawing the rest of an owl" so to speak, doing the hard 10% yourself. And unless anything drastic happens in LLM development this last 10% isn't going to be automated away any time soon.

Re: The End of Programming

#100

Post by nasretdinov »

mechazawa wrote: post #51
nasretdinov wrote: post #18

LLMs are scarily good at translation, whether between natural or between programming languages. Also very good at re-implementing the stuff that has been provably done before. And, arguably, 90-95% of writing code is exactly that.

In my experience they still struggle a lot though. They're great at 1 to 1 translations but they will fight the target language to get there tho. A lot of the rust rewrites I've seen done by AI contain a lot of patterns that any rust dev worth it's salt will scoff at.

Yes -- the bigger the difference between languages the worse they perform. However I'm not really expecting e.g. Claude to be able to port sync.Map from Go to Rust, because sync.Map relies on GC to do the hard work of cleaning up references to values no longer used by any goroutine :).

But in porting, e.g. from PHP to Go they're crazy good at, doing a much better job than any simplistic machine translation ever could

Post reply on HN