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

On The Need For Understanding

blog.information-superhighway.net

Post reply on HN
Print view View original

21–30 of 49 posts

Re: On The Need For Understanding

#21

Post by p1necone »

matt_daemon wrote: post #20

There are a few emotional trigger points that LLMs seem to cause in programmers and this is a common one -- the need for deep, first-principles understanding that LLMs make obsolete. One thing that gets me in a lot of pieces like this is they kind of assume people have no agency, that now that these tools exist we won't be able to help ourselves but use them despite our better judgement. The broader topic which I don…

Idk, as someone who has done LLM driven development of fairly complex things (type systems, memory allocation gymnastics etc) I don't think the need to understand what's going on from first principles has really gone away. If I just want some isolated thing to work I can vibe code with no understanding, but there's no way to get coherence between behaviour, performance characteristics, purity etc without fully understanding the problem space. The LLM just saves (a shitload) of time on grunt work.

Of course if you're building some crud app it's all already tread ground, and you probably can just throw a prompt at an LLM and get something acceptable out.

Re: On The Need For Understanding

#22

Post by bitwize »

zby wrote: post #12
abstractspoon wrote: post #2

I can't imagine programming without understanding aka vibe coding. Hence I will never vibe code.

What do you do to learn new programming construct? What did you do to learn programming - didn't you write #include int main() { printf("Hello World"); return 0; } while having no idea what 'stdio.h' is?

Funny you should mention hello world. Kernighan and Ritchie presented it in TCPL as a little anatomical diagram of close to the smallest possible functional C program with the different parts labelled. The first line is labelled "include information about the standard library". What this means in detail is explained in that chapter. Furthermore, if you were compiling on a Unix system, stdio.h was readily available as /usr/include/stdio.h. Curious people could open it up using more or vi and see what was inside. There was no shortage of curious people back then.

The process of "going through the motions" of writing and compiling a program without even a small understanding of what it all meant was a later innovation, perhaps done as a classroom exercise in an introductory CS course for impatient freshmen or similar.

Re: On The Need For Understanding

#23

Post by hnthrow0287345 »

p1necone wrote: post #21
matt_daemon wrote: post #20

There are a few emotional trigger points that LLMs seem to cause in programmers and this is a common one -- the need for deep, first-principles understanding that LLMs make obsolete. One thing that gets me in a lot of pieces like this is they kind of assume people have no agency, that now that these tools exist we won't be able to help ourselves but use them despite our better judgement. The broader topic which I don…

Idk, as someone who has done LLM driven development of fairly complex things (type systems, memory allocation gymnastics etc) I don't think the need to understand what's going on from first principles has really gone away. If I just want some isolated thing to work I can vibe code with no understanding, but there's no way to get coherence between behaviour, performance characteristics, purity etc without fully unders…

>Of course if you're building some crud app it's all already tread ground, and you probably can just throw a prompt at an LLM and get something acceptable out.

This is what I think most people who haven't had boring CRUD jobs just don't get - the impact of having some deep technical knowledge goes to waste if all you're struggling with is dumb stuff like bad database design and basic security vulnerabilities everywhere. This was all done by people who are no longer there and were just in it for the paycheck. But also no one who is good is doing these jobs because the pay is too low compared to what they can get.

I'm sure all of this is true if you are teaching at MIT or are working anywhere near people who have gone there though.

Re: On The Need For Understanding

#24

Post by andai »

This article helped me understand something I've been grappling with for a while.

I've been looking for the optimal game development environment for a while.

That basically boils down to having batteries included. (I have the opposite of Jonathan Blow's situation, I need to be able to get up and running in a few hours for game jams.)

But there seems to be this tension between convenience and control. Either APIs are low level or they are high level.

(A notable exception is the canvas API, which leaves both groups dissatisfied :)

The article basically made me realize, those are basically two separate groups of people. There's people who want total understanding and total control. And there's people who want to Do Thing With Computer.

I am not sure if it's possible to design one system they would both be happy with.

But that made me realize, I had the same idea about GUIs 20 years ago.

On Mac you usually don't get many options. On Windows you usually get too many options.

A rare few applications let you switch between two modes. "Just Do Thing" and "airplane cockpit". There's usually a gear icon or something like that which shows you all the extra options.

I wonder what that might look like for an API.

Re: On The Need For Understanding

#25

Post by keybored »

I was relieved to read (skim) through all of that without it reaching some LLM conclusion like, “of course we have a better vantage point to understand now than thirty years ago... the LLMs can understand for us”.

Re: On The Need For Understanding

#26

Post by keybored »

matt_daemon wrote: post #20

There are a few emotional trigger points that LLMs seem to cause in programmers and this is a common one -- the need for deep, first-principles understanding that LLMs make obsolete. One thing that gets me in a lot of pieces like this is they kind of assume people have no agency, that now that these tools exist we won't be able to help ourselves but use them despite our better judgement. The broader topic which I don…

Feelings aside[1], a large part of it is about having management above you. Take that plus the ever-present online nagging about productivity. If the latter is true then, well, it’s not like there is a choice.

[1] https://news.ycombinator.com/item?id=47362178

Re: On The Need For Understanding

#27

Post by em-bee »

avilay wrote: post #8
abstractspoon wrote: post #2

I can't imagine programming without understanding aka vibe coding. Hence I will never vibe code.

The two don’t have to be mutually exclusive. You can let the agent code and you review it, or vice versa. No different from being a team lead where you don’t write all the code, or even review each and every line of code, but you have a very firm grasp of the code base.

on the contrary, reviewing LLM code and human code is very different. LLMs don't learn. if a human makes a mistake i can teach them to avoid that mistake in the future. if an LLM makes a mistake, all i can do is fix it over and over again. the dynamics are fundamentally different. some people may prefer to work with a machine, but i don't, i prefer to work with humans.

for me this is similar to the difference of using FOSS vs closed source software. if there is a problem on my linux machine, i can potentially fix it, on windows or mac i just can't.

both closed source software and working with LLMs make me feel helpless. whereas using FOSS or working with humans is empowering.

i get that not everyone feels that way, and that's fine. for my part i'll just stay away from LLM generated code.

Re: On The Need For Understanding

#28

Post by dkarl »

My degree is in math, I love Dijkstra, and I think a lot of my colleagues have often created more work than necessary for themselves by treating pieces of code empirically when they could have got a more precise understanding by spending an hour reading it carefully.

However, I think the most fascinating thing about Dijkstra is how wrong he turned out to be in his prediction that an empirical approach would not scale.

I suspect that approaching programming like Dijkstra might have paid off long-term, but it was rarely a good deal in the short term, both for bad reasons (the empirical approach is a quicker and cheaper way to create buggy software that we can sell and claim as achievements on our performance reviews) and valid reasons (the unreliability of humans and hardware ultimately forces us to approach real computer systems, which are always a composite of hardware, software, and humans, empirically anyway.)

Re: On The Need For Understanding

#29

Post by [deleted] »

andai wrote: post #24

This article helped me understand something I've been grappling with for a while. I've been looking for the optimal game development environment for a while. That basically boils down to having batteries included. (I have the opposite of Jonathan Blow's situation, I need to be able to get up and running in a few hours for game jams.) But there seems to be this tension between convenience and control. Either APIs are…

[deleted]

Re: On The Need For Understanding

#30

Post by tadfisher »

01HNNWZ0MV43FF wrote: post #19

The Android example is a bummer. After this many years and generations of GUI frameworks, you should not have to experiment nor dig into source code to learn how to do something as simple as laying out your widgets. The docs should have examples for that kind of thing.

Note that the author is describing a custom View subclass, which is a couple of steps beyond "layout out your widgets". There used to be pretty comprehensive examples on the developer site for how to do View invalidation properly (calling requestLayout willy-nilly isn't always it).

Nowadays, they learned from many years and generations of GUI frameworks and... made a new GUI framework, Jetpack Compose UI.

Post reply on HN