Boilerplate is only easier to read and analyze if you can be sure it is consistent, so you can tune it out. Usually though, there is this one getter method that is not quite like the others and you literally will not see the difference until it bites you.

We'll need more IDE enhancements, to highlight interesting pieces and desaturate standard boilerplate...

When I think of boilerplate I think of context that is made explicit. Things like type annotations, longer variable names, the lifetime or attributes of some class or data etc. These things are extremely helpful for a number of things - they convey context from writer to readers, they aid in proving the code correct, and they can make code faster.

The context almost always exists in the writers head. We all have a specification of our program based on our expectations, and we type out code to turn that model into an implementation. We only spend so much time conveying that model though - most of us don't write formal proofs, but many of us will write out type annotations or doc comments.

The cost is usually as simple as expressing and typing out the model in our head as code. Languages that are famous for boilerplate, like Java, enforce this - and it makes writing Java slower, but can also make Java code quite explicit (I'm sure someone will respond talking about confusing Java code, that's not the point).

Reducing the cost of conveying context from writer to reader means we can convey more of that context in more places. That's a huge win, in my opinion, because I've personally found that so much implicit context gets lost over time, but it can be hard to always take the time to convey it.

Think about how many programs you've read with single character variable names, or no type annotations, or no comments. The more of that we can fix, the better, imo.

Tools like this do that. TabNine autocompletes full method type signatures for me in rust, meaning that the cost of actually writing out the types is gone. That's one less cost to pay for having clearer, faster code.

>Boilerplate optimizes for the right things - code that's easier to read and analyze, but takes longer to write.

This is wrong and the same retarded logic Java used to defend not introducing var and similar features for ages. Boilerplate is usually noise around the actual logic - it's a result of limited abstractions. When you're repeating same code over and over you raise that segment to a separate concept, that's how abstraction and high level programming works - it increases readability and maintainability. Being easier to type has nothing to do with it.

Thanks for being the person who I knew would try to make this about Java. I don't care about Java, it was a trivial example.

The rest of your post doesn't really have to do with mine. Yeah, you can cut down on boilerplate with changes to languages... duh. But in terms of conveying context there's always a tradeoff of explicit vs implicit, and one of those costs is taking the time to actually turn your mental model into a written implementation - this eases that burden.

As I said, it's a fancy autocomplete.

>But in terms of conveying context there's always a tradeoff of explicit vs implicit

Exactly - if a tool let's you write it explicitly too easily you're making that the default, and it ignores the readability/maintainability side of the tradeoff.

Maybe it gets good enough to recognise when things can be factored out for better readability as well. But in my experience code generators rarely result in maintainable code.