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

Teach yourself programming in ten years (1998)

norvig.com

Post reply on HN
Print view View original

51–60 of 142 posts

Re: Teach yourself programming in ten years (1998)

#51

Post by soulofmischief »

my-next-account wrote: post #29
crystal_revenge wrote: post #8

Earlier quoted context omitted.

I don't personally know anyone who writes code any more (for work). Is this not the case for you? The distinction I see now is between teams that read PRs and teams that don't. I still think the former is a good approach... for now, but I don't expect this will necessarily be the case in a year (or less). This article was such an inspiration to me when I was younger, and the advice, for that time, was very correct. H…

I do! A lot of the work I do is not simple CRUD, and I have to think about what's going on. Reading code doesn't do that to the same degree.

Cutting-edge models are capable of much more than generating CRUD apps and understanding the details is orthogonal to whether you wrote the lines yourself or not.

Re: Teach yourself programming in ten years (1998)

#52

Post by jdw64 »

metalspot wrote: post #38
jdw64 wrote: post #12

These days, I'm not sure anymore. I learned through self-study, reading documents. I don't have a degree, and I don't have the exceptional talent to be involved in language standardization. Everyone around me codes with AI, and most of them produce better results than I do. That's natural. I'm good at some things, but I'm bad at many others. I still hand-code occasionally, but now the main is AI coding, and hand-codi…

I have used AI almost exclusively for a year, but I was programming by hand for almost 30 years before that. I don't think there is any difference between going from assembly -> C -> Java, TypeScript, C#, Go, etc, and taking the next step to AI. It is just another intermediate abstraction layer that allows you to work at larger scale. Programming with AI enforces some good disciplines, which were always true, but cou…

First, I upvoted your comment. I consider it the cost of hearing insights from someone with 30 years of experience. But I don't agree.

The reason is that the compiler's mechanical contract is 'deterministic.' AI, on the other hand, is 'probabilistic.' No matter how much you specify the same situation and details, it doesn't produce 100% identical results.

Abstraction should fundamentally share the same axis of change, but AI doesn't do that. And human code typically starts small, adjusts bit by bit, and refactors as requirements change or scale grows to realign the axis of change. AI's abstraction is fundamentally different from what humans create.

Of course, it can depend on the 'workflow.' If you work in small function units, it can act similarly to a deterministic system. But fundamentally, the market's expectation for natural language AI coding is based on 'large codebases.' Since it's not a codebase understood by a human, it effectively creates an abstraction that's different from my cognitive abilities.

The problem is that AI's abstraction varies from project to project. This is undeniably black-box coding. Sure, you can review it if you know how to read code, but my view differs from yours.

I don't think this is a new abstraction layer. I see it as a technique for controlling blast radius. Of course, you could review the entire codebase while working, but considering the recent vibe coding trend, where people only check core P0 and P1 parts and let AI generate the rest freely, it's even more clear that the focus is on scaling to sizes that humans couldn't handle before.

Of course, my perspective differs from yours, and I think you're a far better programmer than I am.

That's why I think hand-coding and vibe-coding share only the surface-level axis of producing an output, but the cognitive instincts they demand are completely different.

The core of vibe-coding is essentially predicting which part of the black box, if it breaks, would be most critical to the system, and isolating the blast radius. Hand-coding, on the other hand, is fundamentally about surveying the entire system, and definitively controlling and designing every control flow and state change.

In other words, one is an area of 'auditing,' giving up direct control in favor of managing risk, while the other is an area of 'creation,' shaping logical consistency from 0 to 1.

I imagine you also have experience as a PM.

A project manegaris a different profession from a programmer. It requires programming experience, but it's fundamentally a different role. In my view, vibe-coding is essentially a career transition toward being a PM. But separate from that, I don't think this is simply a new abstraction layer. I've seen enough cases where the same prompt and same environment produce different results

Re: Teach yourself programming in ten years (1998)

#53

Post by jurjenh »

overgard wrote: post #37
drudolph914 wrote: post #33

Earlier quoted context omitted.

I used to have this feeling, and I just got over this hurdle. I now continue coding by hand with zero AI usage. It's amazing how much better you feel when you get to use your brain. What really helped me was many perspective shifts perspective shift 1: the people that never cared about programming/engineering finally left the room. the people chasing the trends, trying to grift, or just after money are finally gone.…

> perspective shift 1: the people that never cared about programming/engineer finally left of the room. God I wish, they've all become annoying loud "thought leaders"

You are obviously with them in the wrong room....

Once you know them for who/what they are, and you learn to be comfortable enough with not following them closely, or not knowing what the hip thing is right now, then you can learn to let go of that (almost) insatiable need to keep up. Let them have the room - and the mental energy it requires.

Re: Teach yourself programming in ten years (1998)

#54

Post by flohofwoe »

incanus77 wrote: post #40

Why is this marked as 1998 when it references Khan Academy and Go, among other things?

On Wayback machine references to this post (a much shorter version though) go back to 1998, this is the oldest reference:

https://web.archive.org/web/19980206223800/https://www.norvi...

Re: Teach yourself programming in ten years (1998)

#56

Post by zerr »

primitivesuave wrote: post #31

FWIW, Peter Norvig also gave an updated take on what programming will look like with LLMs around 2 years ago. It did give me some hope back then, but with the development of Fables and Kimis and Sols I think it's truly anyone's guess where the art of programming will go. https://www.youtube.com/watch?v=ia6aJIplmtc

What most miss today is DX - Developer Experience, many (most?) devs don't want to become Prompt Engineers.

Another thing is that not many can afford Fable or similar and I don't think prices will go down, since it is already heavily subsidized?

Re: Teach yourself programming in ten years (1998)

#57

Post by noduerme »

zerr wrote: post #56
primitivesuave wrote: post #31

FWIW, Peter Norvig also gave an updated take on what programming will look like with LLMs around 2 years ago. It did give me some hope back then, but with the development of Fables and Kimis and Sols I think it's truly anyone's guess where the art of programming will go. https://www.youtube.com/watch?v=ia6aJIplmtc

What most miss today is DX - Developer Experience, many (most?) devs don't want to become Prompt Engineers. Another thing is that not many can afford Fable or similar and I don't think prices will go down, since it is already heavily subsidized?

I've always spent 90% of my work time thinking and sketching what the architecture should be to solve a problem. I find that once I've worked that out, it's actually still faster for me to code it than to try to explain it and refine it in prompts. And the code ends up more succinct and covers the edge cases I've already considered. If I need a fast script to do one thing, or unit tests, sure an LLM is faster at writing those. But for clean code, nothing beats knowing what you're going to write and just writing it yourself.

Re: Teach yourself programming in ten years (1998)

#58

Post by teiferer »

zerr wrote: post #56
primitivesuave wrote: post #31

FWIW, Peter Norvig also gave an updated take on what programming will look like with LLMs around 2 years ago. It did give me some hope back then, but with the development of Fables and Kimis and Sols I think it's truly anyone's guess where the art of programming will go. https://www.youtube.com/watch?v=ia6aJIplmtc

What most miss today is DX - Developer Experience, many (most?) devs don't want to become Prompt Engineers. Another thing is that not many can afford Fable or similar and I don't think prices will go down, since it is already heavily subsidized?

Another thing is that not many can afford a power loom or similar and I don't think prices will go down, since it is already heavily subsidized?

Re: Teach yourself programming in ten years (1998)

#59

Post by teiferer »

axus wrote: post #21

It'd be embarrassing if you have to spend $10 in AI tokens for it to fix one line that you could have fixed quicker yourself for free. Not sure if the savings add up enough to offset the investment in learning to program.

I wonder if people writing these comments actually do this hands on.

That's because I do and a one line fix rarely costs anything but cents. Unless you first need to let it figure out which line it is, but that's not a fair comparison because you'd also first need to find out. And if it takes you an hour then instead paying $10 could be a reasonable price to pay.

Re: Teach yourself programming in ten years (1998)

#60

Post by kakacik »

noduerme wrote: post #57
zerr wrote: post #56

Earlier quoted context omitted.

What most miss today is DX - Developer Experience, many (most?) devs don't want to become Prompt Engineers. Another thing is that not many can afford Fable or similar and I don't think prices will go down, since it is already heavily subsidized?

I've always spent 90% of my work time thinking and sketching what the architecture should be to solve a problem. I find that once I've worked that out, it's actually still faster for me to code it than to try to explain it and refine it in prompts. And the code ends up more succinct and covers the edge cases I've already considered. If I need a fast script to do one thing, or unit tests, sure an LLM is faster at writ…

... and 10x that for long term maintenance and evolution of the code. When you read your code later, understanding of it comes more naturally/faster than somebody else's code (at least for me). I break down bigger problems into small chunks in one way, other folks may view things differently.
Post reply on HN