Hacker News Reader

Comment by reader_mode | Hacker News Reader

>2/ The boilerplate is what bothers me the most (as someone who believes in the declarative approach to software engineering). The future for programming and programming languages should be an attempt to step up to a higher level of abstraction, that has been historically the way we step up to higher levels of productivity. As applications get larger and code-bases grow significantly we need abstraction, not more boilerplate.

Just the other day someone on copilot threads was arguing that this kind of boilerplate optimizes for readability... It's like Java Stockholm syndrome and the old myth of easy to approach = easy to read (how long it took them to introduce var).

I've always viewed code generators as a symptom of language limitations (which is why they were so popular in Java land) that lead to unmaintainable code, this seems like a fancier version of that - with all the same drawbacks.

View on HN

I'm all for abstracting. I like Rails, for example. That said, it gets truly difficult to add or change stuff at the more abstract layers. For example, adding recursive querying to an existing ORM is tough. And on the rare occasion that there is a bug in the abstract layer, debugging that from the normal application code is also tough.

I understand why some corporations prefer dumb boilerplate everywhere for some applications. If there is an outage it's usually easy to fix quickly. Sometimes it's not, if it's a issue in the boilerplate (say, Feb 29 rolls around and all of the boilerplate assumed a 28 day month) that means a huge update all across the system, but that rarely happens in practice.

I would say ORM is tough with code gen or with metaprogramming because it maps two mismatched paradigms (OOP and relational) and tries to paper over the differences.

I do agree on the debugging aspect - especially in dynamic languages - metaprogramming stack traces can be really hard to follow.

Tools like xsd or T4 (in the .NET ecosystem) are great time-savers, but you would never consider directly modifying the code they generate. You would leave the generated code untouched (in case it ever needed to be generated again) and subclass it to make whatever changes you intend.

I think Copilot is so unfortunate because it's not building abstractions and expecting you to override parts of them. It's acting as an army of monkeys banging out Shakespeare on a typewriter. And the code it generates is going to require an army to maintain.

Linq2Db is a great example of T4 code generation that works. It creates partial classes from database schema. Together with C# I have strongly typed database access.

https://github.com/linq2db/linq2db

Even there I feel like code generators are just a band aid around the fact that metaprogramming facilities suck. If you would never modify the generated code why generate in the first place. You could argue that stack traces are easier to follow but TBH generated code is rarely pretty in that regard as well.

For example I think F# idea of type providers > code generators.

Code generators = out of practice, out of mind

Reply on news.ycombinator.com