[stillpointlab]

I'm usually the one defending AIs in the comments, but this article hits home for me. I find myself zoning out when I read long tracts written by AI. I absolutely hate filler and many LLMs just fill up space with text.

In my own usage, that has meant that even when I use LLMs to help with prose, I write the text and use the LLM to review and provide feedback. In some cases I will copy a sentence if the LLM version is better but generally I just ask for opinions. I explicitly request the AI _not_ to write. When it re-writes entire paragraphs of my prose I actually experience a deep cringe feeling.

[amanaplanacanal]

They seem to be good at generating a lot of boilerplate, which works for some people because our processes require a lot of boilerplate. We'd be better served by fixing our processes to not require all this useless text, but I don't see this happening.

[jaredklewis]

Over time I’ve come to appreciate boilerplate more.

Early in my career I really appreciated very DRY code with minimal repetition. However over time I’ve noticed that such code tends to introduce more abstractions as opposed to more verbose code which can often rely on fewer abstractions. I think this is good because I think we also have a sort of “abstraction budget” we have to stay within or our brains, metaphorically, stop reading from memory and need to start reading from disk (consulting docs, jumping to function definitions, etc…)

I feel the ideal code base would rely on a small number of powerful abstractions.

In practice I think this usually means relying mostly on the abstractions built into the language, standard library, and framework used and then maybe sprinkling in a couple of app/domain specific abstractions or powerful libraries that being their own abstraction.

So in my experience reducing boilerplate can often make the code more difficult to understand.

[wrs]

It’s not really an abstraction budget, it’s an “unfamiliar abstraction” budget. You only pay cognitive load for an abstraction when you haven’t yet internalized the abstraction. Otherwise progress would have become impossible long ago.

There’s a huge pile of abstractions in that codebase that you have internalized to the point of invisibility — machine instructions, virtual memory, ASCII, sequential execution, named variables, garbage collection, network streams…literally thousands of these abstractions had to be invented and become second nature to you so these other abstractions that currently aren’t as familiar could be based on them.

A good abstraction gives a return on investment of effort internalizing it. There’s no limit on how many good abstractions you should have.

[jaredklewis]

I think we agree, just I would stipulate that I have to see a an abstraction a lot to internalize it (internalize is a great word for this btw).

Like way more than the rule of 3. Even a dozen uses (if it’s only going to be local to just that particular project) is not enough for me.

Edit: and maybe this just says more about the kinda of languages I use at work, but I feel the conventional, widely understood, idiomatic way to do lots of things is often heavy on boilerplate. If these languages were rewritten from the ground up I imagine with hindsight the core languages and standard libraries would look pretty different and be more ergonomic.