Hacker News new | past | comments | ask | show | jobs | submit
devmor | on: The foolishness of "natural language programming" (1978)
I'm not sure if you're being self depreciating or genuinely desire that, but this isn't an outcome that leads to good software engineering.

You should own and be the expert on the architecture and design of what you're building regardless of whether yourself, an LLM or another person is writing the code.

The LLM isn't "smarter" than you, it's more resourceful. It can (to varying degrees of success) translate your design into code. If you aren't still taking ownership and driving the design of that logic, the LLM isn't going to bring you success with anything other than single-use or hobby applications.

skydhash | parent
The thing is, if you’re good at designing and breaking down problems and coming up with a good system, code is not likely an hindrance.

You can take any idea and try to flesh it out with pseudo code. Once that’s done, try to convert it to real code and you’ll see that process is fairly mechanical. This is why people says that coding wasn’t an issue for ages. Coming up with the algorithm is the hard part.

People that have an issue with coding either are not familiar with the language/platform or is trying to think with real code instead of pseudocode or diagrams.

ADDENDUM

There are techniques to think with real code, moslty the Edit-Compile-Run workflow coupled with a good editor, or the REPL workflow (also helped by a good editor). Then add a good integration with a documentation system (manual pages?) and you’re golden.

But I’ve been on projects where a dev cycle relies on a 20 minutes local rebuild or one hour CI run. So it can be very hard to try to apply those workflows to legacy projects.

zelphirkalt | root | parent | next
I somewhat doubt the "fairly mechanical" claim. I think when you actually turn it into real programming language code, that's when lots of the edge cases become apparent and then you will face a lot of new questions, that the natural language or the pseudo code didn't cover.
skydhash | root | parent
I think those are mostly technical issues (accidental complexity) and those are either documented or there should be someone experienced with the technology on your team (even if that experience came from trying it out).

Critical thinking is essential for nailing down your essential complexity (the core solution of the problem). You can try to define invalid and edge cases alongside the happy path in the pseudo code diagrams version, even if it's a TODO comment.

devmor | root | parent
I find this to be intrinsically true in my experience. I was put into senior-level engineering positions very early in my career because I'm a strong problem solver and mentor. I've taken on several positions as a programmer working with a language stack I had little to no experience in without much issue.

Of course there are problems where knowing the code deeply is essential to solve the problem, but those really aren't the majority, if even less than 1% of business problems.

When it comes to what the average developer needs to understand, having a strong grasp on one functional and one procedural language can enable you to solve almost every problem in any language ecosystem, provided the correct resources. If you can do this, you can utilize an LLM for programming assistance well. If you can't, you probably should not heavily rely on one at all yet.