Common take:
“We shouldn’t need LLMs to produce boilerplate for us; we should just build and use languages with less boilerplate instead”
This has the same energy as claiming that design patterns are bad, because languages should just be more expressive… and then making a new language which ends up with its own set of design patterns.
Boilerplate is not necessarily bad! Maximizing the information density of code is not a good goal! APL has existed for decades. Perl has existed for decades. “Line noise” has incredible information density and is widely hated.
Trying to remove all boilerplate results in over-adherence to DRY, and tons of developers have experienced what it’s like for code to be maximally compacted to avoid any repetition. The result is inflexible systems with arbitrary abstractions, because the degrees of freedom have all been welded shut and because the abstraction boundaries were drawn around syntax rather than around semantics. At very high quantities boilerplate can cause a maintainability burden, but too much is usually better than too little. Quality of abstractions matters significantly more.
Static codegen tools and frameworks are nothing new, and they’ll always have their place regardless of the level of abstraction that languages are capable of.
＠技術・雑談
