Hacker News Reader

Comment by skydhash | Hacker News Reader

I wouldn't say so. Once you learn a bit more about programming languages, you realize the problem is mostly about communication, not the tools itself. No matter how good the language is, if the writer and the reader is not fluent in it, you'd have a hard time communicating ideas. My very subjective benchmark is that you ought to be capable to express the overview of your implementation in plain English before even going to code (except if you're prototyping). I've met people that are only gluing snippets together and have never given a thought about the overall design.

View on HN

Spoken language is often insufficiently precise for describing complex systems.

I get tired of folks drawing boxes and arrows and waving their hands about their designs. I ask for proof that it works they way they say it does and I get nothing.

People seem to like GenAI tools because they can avoid doing the work and get the results. It's like having a genie or a monkey's paw... with similar consequences.

If you don't understand the concurrency problems before you're not going to understand them by staring hard at the code that a chatbot generated.

We're just arguing about abstractions. Do people need to always understand "under the hood" of abstractions? Obviously not, most of us don't know how ADC works or how CPU instructions are pipelined or how light pulses end up as 1's and 0's in a buffer somewhere, but requests.get(...) is a genie that we can still use.

Abstractions are not a dichotomy between "forget everything bellow the level in which you wish to operate" and "I need to be able to follow the path of each electron". Which abstractions are used and how you traverse them are relevant discussions that a lot of professionals seek to avoid by using framework, jargon and box diagrams.

We are agreeing, I'm arguing against that dichotomy from the other direction—you don’t always need to know everything under-the-hood. You also can’t always ignore everything under-the-hood.

Sometimes you can get the job done by using a tool like a genie, and that’s awesome (it’s the goal of abstractions IMO). Sometimes you can’t.

You don't always need exhaustive "proof that it works" other than running the thing and looking at the output.

If you can get the job done with an LLM without understanding the code it wrote, then that's awesome. I've seen it multiple times with non-technical people who just want to do some small thing with a Python script. They solve their problem, send their report/email, and move on.

> If you can get the job done with an LLM without understanding the code it wrote, then that's awesome.

I don’t think anyone would find fault with this argument. People who are wary of LLMs, including myself, are in fact wary of lazyness. Getting the (current?) job done is only a small part of building a system. The fact is you have to maintain it or extract the embodied knowledge later, and that’s where no thought have not been given.

In the Tidy First? book by Kent Beck, he explains that the value of software is both in its current behavior and the future possibilities that the structure provides. If there’s no future to worry about, LLMs may be a valuable tool.

Let's not conflate running one off scripts with software development. If LLMs can help people do something with Python that would be just a lot of boring clicking around or whatnot, great.

The conversation in this thread was about how LLMs will change software engineering as a profession tho...

Reply on news.ycombinator.com