Live data from Hacker News

Learning Programming in an Age of LLMs

blog.ploeh.dk

141–150 of 190 posts

Re: Learning Programming in an Age of LLMs

#141
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…

I totally agree with the skepticism that we'll ever get to a point where natural language becomes the "formalism" and stop needing people who understand the actual formalism underneath. And I agree that you don't need LLM based tools.

But things that you don't need can still be (and often are) incredibly useful. Nobody needs an IDE, nobody needs vim or emacs or bash or even compilers or assemblers.

But we have all those tools and they are useful. That is, their utility is net positive.

Using LLMs to generate code currently also has (wildly) net positive utility. Maybe that will change because some part of the calculation changes. But this is the situation right now.

Re: Learning Programming in an Age of LLMs

#142
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…

LLMs do not execute natural language. Natural language describes a problem or request, and LLMs generate and test formal logic they predict will satisfy the request.

When you want to change the resulting program (“formal logic”), you generally don’t change the prompt and regenerate everything (like you would do with source code). Instead, you provide new natural-language instructions to have the LLM perform the change. This means that you don’t have a reproducible specification on the level where you are describing the specification. Therefore the thing that you are maintaining is not a natural-language artifact, it’s effectively still the formal description (program code).

And that’s why the parent comment is saying that we need people that understand the thing that is being maintained, i.e. the program code, which is the source of truth about what is being maintained.

Re: Learning Programming in an Age of LLMs

#143
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…

> It's pretty simple: due to Curry-Howard isomorphism, programming languages are just notations for some type of formal logic.

Thank you, this made me chuckle!

Re: Learning Programming in an Age of LLMs

#144
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…

I agree with this but what I've been trying to answer the last few months is if there was an optimal language for the spec. As with you, I don't think it's English Markdown, but I don't think it's Java either. I also don't think it's Gherkin, Lisp perhaps? I'm still searching.

In any case, it should be a formal language, and we haven’t finished exploring that space. I don’t expect that we will have anytime soon.

Re: Learning Programming in an Age of LLMs

#145

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

#146
post #40

Earlier quoted context omitted.

> Just five years ago, the only way to build a working project of moderate complexity was to learn the basic to intermediate concepts required to make an MVP. > Now, if you can steer an LLM reasonably well, you can quickly build an MVP that goes well beyond your own understanding of the implementation. Somewhat agree. Five years ago you could build an MVP without understanding how to open TCP sockets or how to parse…

> Some things you need to understand-others, not so much. This is the core of the matter though, knowing what you need to understand and what you can ignore is the actual programmer's skill. It requires you to have a clear mental picture of both what you are trying to build and what the underlying machine will do when you are finished. You need to understand the abstractions, but also where they leak, when they won't…

That's just it. you didn't "build so much", you didn't build anything. You asked someone (or something) to build it for you.

How can people look at LLM-generated code and think "this is mine, I made this" is beyond me.

Re: Learning Programming in an Age of LLMs

#147

I'm a software engineer, I do software development but also system maintenance, and I do handle networking and telephony systems, and work with some juniors. Working with AI is problematic. It can speed up you but at the same time delay you. For the system maintenance part sometimes you need to do a lot of stuff fast and in various machines and you can't just count on a cloud based AI oracle (that takes time) to do y…

> we would have to live in a world where software engineering didn't matter. As an engineer who works very hard to do the right thing, I'm beginning to worry that software engineering doesn't matter. I write code that i think about a lot, understanding every line. It's not perfect, but I try to make sure my code is maintainable and well structured. I work much slower then my colleagues who produce unmaintainable slop…

Sometimes it matters and sometimes it doesn't. The hard part is figuring out which is which. The most effective engineers are those who maximize the amount of time they spend picking the right point in the trade-off at the right times. Choosing a preferred point on the continuum and sticking to that at all times simplifies decision making (itself a useful thing!) but it's not the optimal strategy.

There are a couple ways out of this conundrum. One is to try to get really good at picking the right point on the continuum as much as possible, which is essentially a forecasting problem (and thus it's really hard!). I think the somewhat easier choice is to pick roles that align well with your style. If you have a deliberate and near-perfection preference, you can seek to work on projects where there is no question of the importance of correctness. If you prefer the opposite, you can work on prototypes and zero-to-one type projects, and that will be more satisfying (and less catastrophic).

Re: Learning Programming in an Age of LLMs

#148
I have a hard time understanding the problem here. I view ai as a tool. Like a steam shovel, electric drill, etc. You can pick up any tool, and try to use it. With the the drill, you’ll have modicum of success, until the drill spins in the chuck. Then you’ll learn to tighten the chuck more, and have more success. Try to solo on a steam shovel with no training, and there will likely be trouble. Vibe coding without understanding underlying syntax is similar.

Re: Learning Programming in an Age of LLMs

#149
> After months of refactoring I had an uncomfortable realization: I may have built a system that is above my own level of understanding. When everything works, that gap is almost invisible. When it doesn't, it becomes very real.

> "Sometimes I genuinely don't know what to do next without asking another model. That made me wonder whether I spent a year building a product, or partly building the appearance of one: something sophisticated enough to work, but which I don't yet understand deeply enough to truly own

This is always the reality for a sufficiently complex system. We only have an illusion of understanding

Now, more specifically about this feeling, it’s the way a lot of managers feel as well. They can only ask others to fix/change things, and they don’t really understand how/why things break in the code. Even if they lead the whole team to build the product

Re: Learning Programming in an Age of LLMs

#150
> Still, I doubt that it's possible to significantly speed up human learning. The bottleneck is hardly the teachers nor the materials, but how fast a human brain can absorb new knowledge.

I completely agree with it. LLM might be able to 10x the number of PRs, and maybe that is actually is fine for the company because it doesn't care too much about verifications and such. It just wants to ship something that works. But individuals still learn at approximately the same speed. My brain still needs to hit some walls, scream at itself and assimilate the failure and success of my past, to actually learn something new. LLM does help by serving as a very good search engine if I can't Google it easily, but no more than that.

I'm also very happy that OP said "I don't know" a few times.

Post reply on HN