4 ms·

I don't believe that AI is the 'higher level of abstraction[1]' that it is often claimed to be. However I wonder if it's possible to work with a codebase when

by Verdex 1mo ago

I don't believe that AI is the 'higher level of abstraction[1]' that it is often claimed to be. However I wonder if it's possible to work with a codebase when other developers are treating AI as a higher level of abstraction. Analogously, people can write in assembly, but can you write in assembly when the codebase is frequently altered by someone with an optimizing compiler? [1] - Do higher levels of abstractions even exist? By my way of thinking that's called not an abstraction. C isn't a higher level of abstraction; it's a different abstraction implemented by assembly. There are more powerful abstractions and more ergonomic abstractions, but that doesn't make them 'higher level'.

Retr0id 1mo ago
> can you write in assembly when the codebase is frequently altered by someone with an optimizing compiler This itself is quite normal (e.g. we have .S files and .c files and link them together), but I suppose a more accurate analogy would be that someone is dumping their optimising compiler output directly into your .S files. Maybe what we need is better ways to partition the slop-code and the not-slop code.
- Verdex 1mo ago
  Clearly I misspoke. But it looks like you've got the gist of what I was trying to say.
exe34 1mo ago
Sounds like you just don't like the phrase 'higher level'. To most people this is synonymous to 'powerful abstractions' and 'more ergonomic abstractions' in the sense that they allow us to think "at a higher level" - map instead of loop, objects instead of memory addresses and size, modules instead of gotos.
- Verdex 1mo ago
  To be sure I don't like the phrase. But more importantly I also don't like the outcomes when improper abstractions are setup and vital details ignored.
  - exe34 1mo ago
    There are no true scotsmen.
jacquesm 1mo ago
You wouldn't be the first person to eventually conclude that C is just a very fancy macro assembler. But AI generated code is much like every other generated code: it is more voluminous and rather less elegant than what you'd write as a person. And here too there is a link with assembly: early compilers routinely put out absolutely terrible assembly by assembly programmers' standards of the day. And then they got better. To the point that today it takes some pretty rare niches that it pays off to break out the assembler and roll your own. I expect AI generated code to develop in the same way, and the way to get them to improve is to hold generated code to high standards. The problem is the perverse incentive: generated code of low quality will eventually result in many more tokens burned than a one-shot piece of perfect and elegant code. Here you can draw a link with medicine...
cesarb 1mo ago
> Analogously, people can write in assembly, but can you write in assembly when the codebase is frequently altered by someone with an optimizing compiler? Yes. There's an interface boundary in the form of function prototypes and ABI rules. To the optimizing compiler, your assembly code is undistinguishable from separately compiled high-level code, and to your assembly code, the compiler output is undistinguishable from separately assembled low-level code. One problem with LLMs, is that they don't respect these boundaries like an optimizing compiler would.

by Verdex 1mo ago

Retr0id 1mo ago

> can you write in assembly when the codebase is frequently altered by someone with an optimizing compiler This itself is quite normal (e.g. we have .S files and .c files and link them together), but I suppose a more accurate analogy would be that someone is dumping their optimising compiler output directly into your .S files. Maybe what we need is better ways to partition the slop-code and the not-slop code.

Verdex 1mo ago
Clearly I misspoke. But it looks like you've got the gist of what I was trying to say.

exe34 1mo ago

Sounds like you just don't like the phrase 'higher level'. To most people this is synonymous to 'powerful abstractions' and 'more ergonomic abstractions' in the sense that they allow us to think "at a higher level" - map instead of loop, objects instead of memory addresses and size, modules instead of gotos.

Verdex 1mo ago
To be sure I don't like the phrase. But more importantly I also don't like the outcomes when improper abstractions are setup and vital details ignored.
- exe34 1mo ago
  There are no true scotsmen.

jacquesm 1mo ago

You wouldn't be the first person to eventually conclude that C is just a very fancy macro assembler. But AI generated code is much like every other generated code: it is more voluminous and rather less elegant than what you'd write as a person. And here too there is a link with assembly: early compilers routinely put out absolutely terrible assembly by assembly programmers' standards of the day. And then they got better. To the point that today it takes some pretty rare niches that it pays off to break out the assembler and roll your own. I expect AI generated code to develop in the same way, and the way to get them to improve is to hold generated code to high standards. The problem is the perverse incentive: generated code of low quality will eventually result in many more tokens burned than a one-shot piece of perfect and elegant code. Here you can draw a link with medicine...

cesarb 1mo ago

> Analogously, people can write in assembly, but can you write in assembly when the codebase is frequently altered by someone with an optimizing compiler? Yes. There's an interface boundary in the form of function prototypes and ABI rules. To the optimizing compiler, your assembly code is undistinguishable from separately compiled high-level code, and to your assembly code, the compiler output is undistinguishable from separately assembled low-level code. One problem with LLMs, is that they don't respect these boundaries like an optimizing compiler would.