8 ms·

>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 pr

>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.

ethbr0 5y ago
Code generators = out of practice, out of mind
slumdev 5y ago
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.
- hu3 5y ago
  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 https://github.com/linq2db/linq2db
- reader_mode 5y ago
  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.
3pt14159 5y ago
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.
- reader_mode 5y ago
  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.

ethbr0 5y ago

Code generators = out of practice, out of mind

slumdev 5y ago

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.

hu3 5y ago
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 https://github.com/linq2db/linq2db
reader_mode 5y ago
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.

3pt14159 5y ago

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.

reader_mode 5y ago
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.