Hacker News Reader

Comment by perrygeo | Hacker News Reader

Considering LLMs are models of language, investing in the clarity of the written word pays off in spades.

I don't know whether "literate programming" per se is required. Good names, docstrings, type signatures, strategic comments re: "why", a good README, and thoughtfully-designed abstractions are enough to establish a solid pattern.

Going full "literate programming" may not be necessary. I'd maybe reframe it as a focus on communication. Notebooks, examples, scripts and such can go a long way to reinforcing the patterns.

Ultimately that's what it's about: establishing patterns for both your human readers and your LLMs to follow.

View on HN

Yeah, I think what is needed is somewhere between docstrings+strategic comments, and literate programming.

Basically, it's incredibly helpful to document the higher-level structure of the code, almost like extensive docstrings at the file level and subdirectory level and project level.

The problem is that major architectural concepts and decisions are often cross-cutting across files and directories, so those aren't always the right places. And there's also the question of what properly belongs in code files, vs. what belongs in design documents, and how to ensure they are kept in sync.

Also:

"Bad programmers worry about the code. Good programmers worry about data structures and their relationships."

-- Linus Torvalds

> "Bad programmers worry about the code. Good programmers worry about data structures and their relationships."

If you get the architecture wrong, everyone complains. If you get it right, nobody notices it's there.

The SRE's Lament.

"Nothing needs fixing, so what do we pay you for?"

"Everything's broken! What do we even pay you for!?"

Doesnt this apply with the hysteria of LLMs?

The question being - are LLMs 'good' at interpreting and making choices/decisions about data structures and relationships?

I do not write code for a living but I studied comp sci. My impression was always that the good software engineers did not worry about the code, not nearly as much as the data structures and so on.

The only use of code is to process data, aka information. And any knowledge worker that the success of processing information is mostly relying on how it's organized (try operating a library without an index).

Most of the time is spent about researching what data is available and learning what data should be returned after the processing. Then you spend a bit of brain power to connect the two. The code is always trivial. I don't remember ever discussing code in the workplace since I started my career. It was always about plans (hypotheses), information (data inquiry), and specifications (especially when collaborating).

If the code is worrying you, it would be better to buy a book on whatever technology you're using and refresh your knowledge. I keep bookmarks in my web browser and have a few books on my shelf that I occasionally page through.

Notebooks are an example of literate programming.

Reply on news.ycombinator.com