3 ms·

Have you looked at the machine instructions your compiler produces? No? Why? Because software languages are a pretty good abstraction. To the extent that goo

Have you looked at the machine instructions your compiler produces? No? Why? Because software languages are a pretty good abstraction. To the extent that good abstractions are in place, you can avoid looking at code specifically. Those don't perfectly well exist, so it takes a lot of self discipline and the right tools/methods, but invariably, AI will produce better systems. That said, its very easy to produce slop, so well see much more of it. But mostly, it will be AI from here on in, as a matter of productivity. There are some arguments on the margins but those will fade over the next few years. 'At minimum' - the 'power tools' are here to stay.

marginalia_nu 2mo ago
Anyone who is involved in any sort of performance critical work looks at compiler output on a regular, if not daily basis.
- znnajdla 2mo ago
  Sure but you only look at it when optimizing some performance critical code, usually the hot path. That is usually a tiny fraction of the codebase. I also use AI to generate large amounts of code but I only inspect the actual code when critical, delicate or architecturally important stuff is involved.
- bluegatty 2mo ago
  Yes, but even HFT traders use Java and don't look at the compiler output. Looking at the compiler output is a totally valid concept, but it's definitely a niche case.
  - marginalia_nu 2mo ago
    If you're doing high performance Java you're definitely looking at the compiler output. At least you should be. It's arguably more important with Java than with the compiler output for something like C++, as C2 is much more unpredictable and dependent on runtime circumstances. You also want to be real certain that bounds and null checks are omitted as those come at a pretty big performance premium.
cautiouscat 2mo ago
> Have you looked at the machine instructions your compiler produces? > No? Why? > Because software languages are a pretty good abstraction. No, it’s because compilers produce deterministic output. I am so tired of this argument. If I’m not concerned with the performance of my code, I can be 100% confident that that exact code will produce the correct assembly every time. That’s why I don’t read it. Not because I don’t care.
- bluegatty 2mo ago
  No - perfect determinism is absolutely not required. It's entirely the nature of the abstraction. You want it to work as expected, it does not have to produce the same thing each time.
  - bigstrat2003 2mo ago
    No, determinism is actually required. If compilers changed between producing decent assembly and crap assembly from run to run, we would be reading the generated assembly every single time.
    - meowkit 2mo ago
      Yall modern compilers do not produce the same thing every time. Compilers have had decades to get really good at what they do. LLMs have been functional for maybe 3 years? Source: I work on an operating system.
kriro 2mo ago
Higher level languages are still formal languages. I think there's a conceptual difference between moving from one formal language to another (machine instructions to asm or asm to C) and moving from a formal language to natural language. So yes, developing, looking at and understanding a formal description of your system has benefits for an engineer compared to handing off this step completely.
shhsshs 2mo ago
A compiler translating high-level code to machine code is a predictable and repeatable process. An LLM translating a prompt to to high-level code has a much lower degree of predictability. To say an LLM prompt is a comparable abstraction is unfair, though I admit it's getting very close.
- bluegatty 2mo ago
  The LLM will never produce the same output each time, it doesn't have to do that to have very strong level of abstraction. But yes, it has to fulfill some kind of contract defined by the absraction. It's less a problem of the LLM, and more so how we use them, and the inherent tooling around it.
  - beej71 2mo 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 2mo 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.
pydry 2mo ago
LLMs are pretty much the exact opposite of a reliable compiler-like abstraction. This is true to such an extent that I have to question the overall competence of anybody who makes the comparison. It's an enormous red flag. I'd recommend reading Joel spolsky's leaky abstractions essay coz while it applies less and less 20 years later to things like kernel abstractions it explains very well why treating the LLM as a compiler sets you up for abject failures.

marginalia_nu 2mo ago

Anyone who is involved in any sort of performance critical work looks at compiler output on a regular, if not daily basis.

znnajdla 2mo ago
Sure but you only look at it when optimizing some performance critical code, usually the hot path. That is usually a tiny fraction of the codebase. I also use AI to generate large amounts of code but I only inspect the actual code when critical, delicate or architecturally important stuff is involved.
bluegatty 2mo ago
Yes, but even HFT traders use Java and don't look at the compiler output. Looking at the compiler output is a totally valid concept, but it's definitely a niche case.
- marginalia_nu 2mo ago
  If you're doing high performance Java you're definitely looking at the compiler output. At least you should be. It's arguably more important with Java than with the compiler output for something like C++, as C2 is much more unpredictable and dependent on runtime circumstances. You also want to be real certain that bounds and null checks are omitted as those come at a pretty big performance premium.

cautiouscat 2mo ago

> Have you looked at the machine instructions your compiler produces? > No? Why? > Because software languages are a pretty good abstraction. No, it’s because compilers produce deterministic output. I am so tired of this argument. If I’m not concerned with the performance of my code, I can be 100% confident that that exact code will produce the correct assembly every time. That’s why I don’t read it. Not because I don’t care.

bluegatty 2mo ago
No - perfect determinism is absolutely not required. It's entirely the nature of the abstraction. You want it to work as expected, it does not have to produce the same thing each time.
- bigstrat2003 2mo ago
  No, determinism is actually required. If compilers changed between producing decent assembly and crap assembly from run to run, we would be reading the generated assembly every single time.
  - meowkit 2mo ago
    Yall modern compilers do not produce the same thing every time. Compilers have had decades to get really good at what they do. LLMs have been functional for maybe 3 years? Source: I work on an operating system.

kriro 2mo ago

Higher level languages are still formal languages. I think there's a conceptual difference between moving from one formal language to another (machine instructions to asm or asm to C) and moving from a formal language to natural language. So yes, developing, looking at and understanding a formal description of your system has benefits for an engineer compared to handing off this step completely.

shhsshs 2mo ago

A compiler translating high-level code to machine code is a predictable and repeatable process. An LLM translating a prompt to to high-level code has a much lower degree of predictability. To say an LLM prompt is a comparable abstraction is unfair, though I admit it's getting very close.

bluegatty 2mo ago
The LLM will never produce the same output each time, it doesn't have to do that to have very strong level of abstraction. But yes, it has to fulfill some kind of contract defined by the absraction. It's less a problem of the LLM, and more so how we use them, and the inherent tooling around it.
- beej71 2mo 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 2mo 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.

pydry 2mo ago

LLMs are pretty much the exact opposite of a reliable compiler-like abstraction. This is true to such an extent that I have to question the overall competence of anybody who makes the comparison. It's an enormous red flag. I'd recommend reading Joel spolsky's leaky abstractions essay coz while it applies less and less 20 years later to things like kernel abstractions it explains very well why treating the LLM as a compiler sets you up for abject failures.