3 ms·

I don't get the use of "abstraction" in this context, I must admit. Programming abstractions offer interfaces to functionality that are both simplified in use

by beej71 1mo ago

I don't get the use of "abstraction" in this context, I must admit. Programming abstractions offer interfaces to functionality that are both simplified in use and restricted in capability. (e.g. any API or compiler.) I don't see how LLMs meet that definition. It seems more like we're talking about offloading or delegation, here. And that's a valid business tactic, certainly, but it's not a software abstraction any more than a CTO is an abstraction of a tech lead, no? > But yes, it has to fulfill some kind of contract defined by the absraction. I don't follow. Is the contact here the design specification for the system? If so, again, I'd argue that's not an abstraction.

bluegatty 1mo ago
An abstraction could be a design requirement, expressed in some way. That's definitely an abstraction. IDLs are a form of abstraction, they're a requirement somewhat more formally described. Remember UML? That was an attempt to go 1/2 layer above the code, that was an abstraction. There were tons of tools like that. APIs are an abstraction - maybe the best example. We write code to match exactly the behaviour defined by an APU - as long as it meets the requirement of that contract, then 'it's good'. And there could be many ways of doing that.
- beej71 1mo ago
  [dead]