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

Learning Programming in an Age of LLMs

blog.ploeh.dk

Post reply on HN
Print view View original

131–140 of 190 posts

Re: Learning Programming in an Age of LLMs

#131

Post by js8 »

ds_opseeker wrote: post #90
js8 wrote: post #58

I answered this to myself - stop worrying about LLMs. It's pretty simple: due to Curry-Howard isomorphism, programming languages are just notations for some type of formal logic. Now ask yourself a question, what language do you want to maintain the programs in? Do you think natural language is going to be easier and more maintainable than formal logic? The answer is no. So you need programmers, people who can read t…

re: natural language sucks. prof.dr.Edsger W.Dijkstra's views: https://www.cs.utexas.edu/~EWD/transcriptions/EWD06xx/EWD667... I humbly add my own. Natural language is valuable for the things it doesn't say. The ambiguity is core to the functionality. Which can be very helpful when navigating social complexities. And then written language is also valuable for the things IT doesn't say. Under the theory that 90% of co…

I would agree with EDW, and I have argued here in a similar way.

I am not against use of NL in negotiation or poetry. If you find ambiguity useful there, be my guest. But engineering specifications, mathematics, as well as other sciences or even philosophy would IMHO benefit from more rigor.

I also strongly disagree with the notion that logical or programming languages cannot express ambiguity. (It actually took me many years to understand.) I used to think you need something like fuzzy logic or probability, but that's unsatisfactory in some ways. Eventually, I settled for a really simple understanding of the problem.

Take lambda calculus for instance. I define the term to be ambiguous iff it has a normal form. So it is ambiguous if it expects additional argument, which resolves (part of or all) the ambiguity. Terms with no normal form are completely unambiguous, their "output" is completely given.

In classical logic, this corresponds to formulas that are conditioned on additional assumption. Again, the extra assumption can resolve the ambiguity.

So it is kind of my conviction (although we could show that by translating an LLM as a program into LC) that all the words in natural language can be formalized as sufficiently complicated lambda terms, that all have normal forms and react to each other in a way that resolves some ambiguity without ever resolving all of it.

Re: Learning Programming in an Age of LLMs

#132

Post by [deleted] »

derpyzza wrote: post #60
Razengan wrote: post #8

I said this in different ways before and got shoveled because of the way I said it: None of us know how to farm, not even the chefs who cook for us at a restaurant or fast food joint, but we eat every day and nobody's going around making people feel guilty about not knowing how to till soil and sow seeds.. In programming and other creativity, most people's skills will [have to] change/evolve into managing, directing,…

...string's aren't a pointer to a pointer to a character. they're pointers to characters directly. maybe you need to wrestle with that concept some more...

[deleted]

Re: Learning Programming in an Age of LLMs

#133

Post by [deleted] »

jappgar wrote: post #129
lioeters wrote: post #127

Earlier quoted context omitted.

No offense but you're just making statements without backing it up with anything. "Clearly superior", "finding out that is true".. How are you going to prove what you said? Natural language is not enough for that purpose. You need formal logic, quantifications, specifications, the foundation of programming. Superior to what, and according to what metrics? What truth in computation are you talking about, and how can w…

Superior just means "above" or "on top of". Natural animals don't communicate in logical terms, even if their dna is a logical sequence.

[deleted]

Re: Learning Programming in an Age of LLMs

#134

Post by agentultra »

meowface wrote: post #102
agentultra wrote: post #76

“I built a thing with AI and I don’t understand it. I want to make changes and fix things and have no ability to theorize why it fails or how to fix it.” Oh my. See, you have to be able to program it yourself before you can build it with an LLM. Otherwise you have no way of judging the output. AI isn’t going to make you a programmer. Learning to program is. Interesting article. My advice is to do it the old fashioned…

A lot of successful startups start out with good ideas and atrocious, unmaintainable code. Current LLMs kind of let you speedrun that. Dutifully slapping more and more mud onto their week-old ball of mud. The sacred, canonical ball of mud they must faithfully preserve at all costs. But the product will probably work decently enough. And as long as the humans are sufficiently devoted to testing and nitpicking and impr…

I think the harnesses might get better. And the alignment and pre training. But I don’t think the LLMs will get much better… I don’t have any sources for that though. Just napkin math.

At the end of the day, even if it gets to 99.9999% reliably generate what an experienced programmer would expect… you still need to be an experienced programmer to know what to want and how to specify it.

I think the experience, institutional knowledge, and process knowledge are never going to be replaceable.

You’ll still need to learn what a cache miss is and how the heap works and when to use skip lists and all that. Otherwise you will just generate slop. An AI system is not able to replace a human.

Re: Learning Programming in an Age of LLMs

#135

Post by Izkata »

skydhash wrote: post #106
trey-jones wrote: post #94

Earlier quoted context omitted.

This is exactly true in my experience. I find myself trusting the LLM better than I ever trusted a development team to deliver accurate work. Just like you would managing a team of junior developers, you have to keep an eye on the output, but I think the agent is more transparent about that than your team would be. And it works faster, and you don't have to deal with emotional meltdown or active sabotage if you criti…

> find myself trusting the LLM better than I ever trusted a development team to deliver accurate work That’s the main issue. You’re talking about the development side guarante, while the most important is the user side guarantee. There’s a lot of talk about liking LLM interaction, but no comments about the software quality, which for a lot of SaaS has gone downhill. It’s why they emphasized LoC and number of PRs but…

> but no comments about the software quality, which for a lot of SaaS has gone downhill. It’s why they emphasized LoC and number of PRs but hide the number of bug tickets.

And here's some numbers (gathered from telemetry over time) showing that: https://www.faros.ai/blog/ai-acceleration-whiplash-takeaways

Here's someone's breakdown (with some things from the full report that aren't in the Faros blog post), showing how it's even worse than first impressions: https://unessays.substack.com/p/talk-is-cheap

Re: Learning Programming in an Age of LLMs

#136

Post by Tanjreeve »

falcor84 wrote: post #62
skydhash wrote: post #48

Earlier quoted context omitted.

That’s the power of abstraction when there’s a good API around something to hide the internal that doesn’t matter much at an higher level. You only need ‘open’ and ‘read’ instead of dealing with disk access and file system trasversal. But those abstraction are deterministic in nature, so there’s a very good guarantee of their behavior. Someone using LLM and not caring about the generated code is just asking for troub…

> The code may work, but there’s no guarantee about its behavior (including error handling and edge cases). But the painful reality is that we never had any such guarantees in industry code to begin with; despite decades of writing on software engineering best practices, software from the biggest companies is often bug ridden. My experience might not be representative, but when I do my "old man yells at clouds" routi…

>My experience might not be representative, but when I do my "old man yells at clouds" routine (which I do multiple times a day), it's a lot more often targeted at Microsoft and Google software than at "vibe coded slop".

As in you get more mad at software you actually use being broken than software that you aren't using and just exists in blogposts?

Re: Learning Programming in an Age of LLMs

#137

Post by mrits »

jappgar wrote: post #116
mrits wrote: post #65

Earlier quoted context omitted.

Extraneous and ambiguous is superior? Or are you talking about hypothetical new spoken languages?

Yes. Ambiguity is a feature, not a bug.

I don't think it's a feature or a bug. It is an indicator of an extremely poor spec though.

Re: Learning Programming in an Age of LLMs

#138

Post by falcor84 »

Tanjreeve wrote: post #136
falcor84 wrote: post #62

Earlier quoted context omitted.

> The code may work, but there’s no guarantee about its behavior (including error handling and edge cases). But the painful reality is that we never had any such guarantees in industry code to begin with; despite decades of writing on software engineering best practices, software from the biggest companies is often bug ridden. My experience might not be representative, but when I do my "old man yells at clouds" routi…

>My experience might not be representative, but when I do my "old man yells at clouds" routine (which I do multiple times a day), it's a lot more often targeted at Microsoft and Google software than at "vibe coded slop". As in you get more mad at software you actually use being broken than software that you aren't using and just exists in blogposts?

I personally work a lot with vibe coded software, both my own and of others. And I do encounter a lot of issues, but in general they annoy me less than the enterprise engineered ones.

Re: Learning Programming in an Age of LLMs

#139

Post by rgbrgb »

I've been thinking about this in the context of learning new languages and tech. In pre-LLM days it was fun to sometimes try to implement a new idea in a new language or stack and build up an understanding by trial and error. You'd have to accept that it will be slower to get going than a familiar set of tools and maybe only trade out one old tool at a time in this way.

Now the pace of dev with something new is so rapid and fun that it's hard to not skip even basic things with a new stack. I swapped postgres (old reliable) for clickhouse (first use) in a project and saw a massive speedup of my workloads, but I really have to go down the socratic rabbit hole to understand why and even then it's a different level of understanding vs having to read the readme, quickstart, install it myself, rewrite queries by hand. TBH though, pre-LLM I probably would have just plodded along with postgres and built a hacky auto-indexer thing, so in a way the agentic coding helps me explore more territory but encourages less depth.

No strong conclusions. Like OP, I'm just spitballing / trying to understand this new world too.

Re: Learning Programming in an Age of LLMs

#140

Post by twinwest »

I am curious that would there be any new programming language being invented in the age of LLMs, as LLM is about probability and need to trained on a large dataset to perform. It looks like the incentive is less while it costs more to create a new programming language.
Post reply on HN