@riley @jenniferplusplus It doesn't have to be amazing. If it can just scaffold out the tedious stuff for me (which it can successfully 99% of the time), then it still makes my job easier, and is thus a useful tool.

@LouisIngenthron @riley @jenniferplusplus You don’t need LLMs to make it easy to scaffold code. Any good IDE already had the feature in the form of a snippet library of *known good* scaffold code. To pick one example, mine has a scaffold for a table-driven unit test, which is the most tedious piece of code I can think of that I regularly have to write.

@mathew I think you're talking about boilerplate, not scaffolding.

@LouisIngenthron @jenniferplusplus

@mathew The canonic example of scaffolding in mechanical construction is, you can't build arches beyond some very tiny size by just laying bricks into a curved shape. So, you build a temporary curved surface, you'll then lay the bricks onto this surface, and once the arch is complete and the mortar will have hardened, then you can remove the temporary scaffolding. This sort of pattern is fairly common in engineering, including software engineering.

The problem is, this is not widely recognised, and both managers and newbies in all sorts of engineering disciplines keep, metaphorically speaking, trying to build arches without the important temporary support. And that leads to crashes, and budget overruns, and worse.

@LouisIngenthron @jenniferplusplus

@riley @LouisIngenthron @jenniferplusplus I was just using the term used in the comment I was replying to. If you want to keep that distinction, what LLM coding bots generate is boilerplate rather than scaffolding, right? People aren’t throwing it away later, they’re incorporating the code as a permanent part of the codebase.

@mathew No. 'Boilerplate' is an antipattern of languages or coding standards that insisting on the code including long repeats of substantially similar sections. This used to be common in COBOL and many of IBM's undertakings, but the general software developer culture has become increasingly aware of the problems with boilerplate, and many subcultures now have various measures against boilerplate code being common. Of the mainstream languages, only Java and JavaScript still incentivise boilerplate code (and for two very different reasons, with JavaScript's reason being the more defensible of the two).

'Scaffolding' is temporary structures that you build as a part of the engineering work, but that will not be a part of the final product. In civil engineering, scaffolding used to be invariably dismantled, and if it would be needed for maintanance work, reconstructed. Some argument is feasible as to whether scaffolding used in software projects should be shipped together with the final project. I personally believe that most scaffolding should be documented and shipped, the exception being early prototypes. But if you're writing a compiler in two stages, a simplified version to translate the full version, as a part of a bootstrap process, you should definitely ship the simplified version as well as the full version.

The sort of source code that LLMs can output does not necessarily fall under either of these categories. The strongest feasible argument of using LLMs for generating software, though, overlaps strongly with the argument against programming in ways that require or incentivise boilerplate code. (The loudest argument for using LLMs, the idea that they empower non-programmers to create programs, is not, at the current level of AI research, actually a feasible argument. In fact, this argument has been repeatedly raised throughout the history of programming languages, endemically so since the rise of the fourth generation languages, and it has always failed. At some point, an AI system might be able to do what a software developer currently does, as in, reliably convert a piece of ambiguous natural language description of a problem into a program that does something reasonable towards solving the problem, but LLMs are nowhere near this point, and based on what I know of AI research so far, I would be inclined to argue that anything recognisable as a form of present-day LLM will, more likely than not, even not be a functional component of a genuine artificial programming system, once there will be such a system.

@LouisIngenthron @jenniferplusplus

@riley @LouisIngenthron @jenniferplusplus OK, I guess I was unclear: what was being argued in the comment I was replying to, was that the necessity of boilerplate was a valid reason for using LLMs. I was disputing that.

“The strongest feasible argument of using LLMs for generating software, though, overlaps strongly with the argument against programming in ways that require or incentivise boilerplate code.”

I don’t understand this comment. Why would a lack of need for boilerplate code be an argument for using LLMs?

(Ironically, the way you post huge responses that don’t seem to relate to what I’m actually saying makes me start to wonder if you’re using LLMs to generate output in order to troll people like the person I replied to.)

@mathew That's so offensive an argument that I hope you won't mind if I mutter angrily about hrowing pearls to swine and turn my deficient-as-it-is attention elsewhere.

For more information, re-read.

@LouisIngenthron @jenniferplusplus

@mathew @riley @jenniferplusplus Of course I don't *need* an LLM for that. I don't *need* an IDE other than notepad either. But better tools makes work go faster.

@LouisIngenthron @riley @jenniferplusplus Personally I feel that a library of good code is going to be a better way to make work go faster than a library of code that may or may not be good.

@mathew @riley @jenniferplusplus When the library of good code is one room and the library of may-or-may-not is a skyscraper, the balance shifts.

More importantly, I would never recommend these tools for amateurs for that very reason (it reinforces bad habits as well as good). But for those of us with the skill and experience to identify the bad stuff, it's a huge efficiency booster.