> Yeah, exactly. And LLM help developers save time from writing the same thing that has be done by other developers for a thousand times.

Before LLMs we did already have a way to "save developers time from writing the same thing that has been done by other developers for a thousand times", you know? A LLM doing the same thing the 1001st time is not code reuse. Code reuse is code reuse.

▲

raincole 5 hours ago | parent | next [-]

Because code reuse is hard. Like, really hard. If it weren't we wouldn't be laughing at left-pad. If it weren't hard we wouldn't have so many front-end JavaScript frameworks. If it weren't Unreal wouldn't still have their own GC and std-like implementation today. Java wouldn't have been reinventing build system every five years.

The whole history of programming tool is exploring how to properly reuse code: are functions or objects the fundamental unit of reuse? is diamond inheritance okay? should a language have an official package management? build system? should C++ std have network support? how about gui support? should editors implement their own parsers or rely on language server? And none of these questions has a clear answer after thousands if not millions of smart people attempted. (well perhaps except the function vs object one)

Electron is the ultimate effort of code reuse: we reuse the tens of thousands of human-years invested to make a markup-based render engine that covers 99% of use case. And everyone complains about it, the author of OP article included.

LLM-coding is not code reuse. It's more like throwing hands up and admitting humans are yet not smart enough to properly reuse code except for some well-defined low level cases like compiling C into different ISA. And I'm all for that.

▲

Garlef 3 hours ago | parent | next [-]

I think you could also argue that LLMs in coding are actually just a novel approach at code reuse: At the microscopic level, they excel at replicating known patterns in a new context.

(Many small dependencies can be avoided by letting the LLM just re-implememt the desired behavior; ~ with tradeoffs, of course)

The issue is orchestrating this local reuse into a coherent global codebase.

▲

layer8 2 hours ago | parent | prev | next [-]

The problems with leftpad are a problem with the NPM ecosystem, not with code reuse as such. There are other dependency ecosystems that don't have these problems.

▲

FpUser 3 hours ago | parent | prev | next [-]

>"well perhaps except the function vs object one"

If this is what I think it is, I consider it very lopsided view, failure to recognize what model fits for what case and looking at everything from a hammer point of view

	▲	raincole an hour ago \| parent [-]
		I think function is the fundamental unit and object is an extra level over it (it doesn't mean there is no use for object). Thinking objects/classes are the fundamental/minimal level is straight up wrong. Of course it's just my opinion.

▲

bandrami 2 hours ago | parent | prev [-]

I have terrible news: LLMs don't actually make it easier, though it feels like they do at first

▲

foobarbecue 5 hours ago | parent | prev | next [-]

Hard agree. Before LLMs, if there was some bit of code needed across the industry, somebody would put the effort into writing a library and we'd all benefit. Now, instead of standardizing and working together we get a million slightly different incompatible piles of stochastic slop.

▲

edgyquant 2 hours ago | parent | next [-]

This was happening before llms in webdev

	▲	deltaburnt an hour ago \| parent [-]
		I don't think we should use webdev as an example of why lossy copy and paste works for the industry.

▲

mexicocitinluez 3 hours ago | parent | prev [-]

Before LLMs companies and people were forced to use one-size-fits-all solutions and now they can build custom, bespoke software that fits their needs.

See how it's a matter of what you're looking at?

▲

porridgeraisin 5 hours ago | parent | prev [-]

Oh come on, you don't have to be condescending about function calls.

https://news.ycombinator.com/item?id=47260385

▲

Sharlin 5 hours ago | parent [-]

I was talking about libraries, higher-level units of reuse than individual functions. And your "syntactic" vs "semantic" reuse makes zero sense. Functions are literally written and invoked for their semantics – what they make happen. "Syntactic reuse" would be macros if anything, and indeed macros are very good at reducing boilerplate.

You might have a more compelling argument if instead of syntax and semantics you contrasted semantics and pragmatics.

▲

porridgeraisin 5 hours ago | parent [-]

A library is a collection of data structures functions. My argument still holds.

> Syntactic reuse would be macros

Well sure. My point is that what can be reused is decided ahead of time and encoded in the syntax. Whereas with LLMs it is not, and is encoded in the semantics.

> Pragmatics

Didn't know what that is. Consider my post updated with the better terms.

▲

runarberg 3 hours ago | parent [-]

I’m not sure your logic is sound. It sounds like you are insisting on some nuance which simply isn’t there. LLM generates unmaintainable slop, which is extremely difficult to reason about, uses wrong abstractions, violates DRY, violates cohesion, etc.

The industry has known how to reuse codes for two decades now (npm was released 16 years ago; pip 18 years ago). Using LLMs for code reuse is a step in the wrong direction, at least if you care about maintaining your code.

	▲	porridgeraisin an hour ago \| parent \| next [-]
		Oh sure the quality is extremely unreliable and I am not a fan of its style of coding either. Requires quite a bit of hand holding and sometimes it truly enrages me. I am just saying that LLM technology opens up another dimension of code reuse which is broader. Still a ways to go, not in the foundation model, those have plateaued, but in refining them for coding.
	▲	naasking 2 hours ago \| parent \| prev [-]
		> LLM generates unmaintainable slop LLMs generate what you tell them to, which means it will be slop if you're careless and good if you're careful, just like programming in general.