3 ms·

That's not a good analogy. With a high level language implementation of any sort, the actual instructions executed by the CPU may vary according to how it was

That's not a good analogy. With a high level language implementation of any sort, the actual instructions executed by the CPU may vary according to how it was compiled or run, or what machine you run it on, but the behavior will not. The high level language defines it's own level of abstraction, defining exact behavior, allowing the developer to have full control over program behavior, algorithms, UI, etc. An LLM + natural language instructions is not a program-like abstraction of what you want the computer to do, because it does not have that level of precision. Natural languages are fuzzy and imprecise, because they have been developed for communication, not precise machine-level specification. Obviously you can "vibe code" at different levels of detail, ranging from "build me an app to do X" to "here are 20 1000 word essays specifying the dos and don'ts of what I want you to build", but in either case you are nowhere near the level of precision of using a programming language to specify exactly what you want. So sure, "vibe coding" let's you accomplish A result with less attention to detail than using a programming language, but it's not a "higher level abstraction" in the sense that HLLs are, since it doesn't define what that abstraction is. It lets you get A result, but not define a SPECIFIC result, since natural languages just aren't that precise... natural language means whatever the person/thing interpreting it interprets it to mean. Of course you can use an LLM as a way to "rough out" a function or app, and as a crude tool to manipulate that roughed out form (or an existing project), but natural language does not have precise semantics and therefore cannot provide a precise definition of what you want to do.

dpark 6mo ago
It wasn’t my analogy. It was the article’s so I responded to that. There are many more (and better) examples of how abstractions give up control, precision, and/or determinism. > The high level language defines it's own level of abstraction, defining exact behavior This is not entirely true. A high level language defines some behaviors, leaving many behaviors to be undefined and implementation specific. Many of those unspecified behaviors can matter in some cases. > It lets you get A result, but not define a SPECIFIC result, since natural languages just aren't that precise... You are repeating the same error as the article and missing the fact that while an abstraction lets you specify or control some things, it leaves many things out of your control. The higher the abstraction, the more stuff that is left out of your control. And maybe you don’t care about the things outside your control (great, the abstraction worked!) but regardless there are many things left unspecified in the typical abstraction and very often eventually you will care, which is why people say things like “all abstractions are leaky”. For a simple example, think of writing something like this: MessageBox(“hello world”, OkCancel) MessageBox is an abstraction over a massive amount of logic. You specified a string and a set of buttons and not much else. You give up control over the styling, the placement of the buttons, the actual button text (very likely will be localized), where the box will appear, and so much more. You are not getting a specific result. You are getting a result that meets the contract. “Write a program that shows a hello world message box” is a much higher level of abstraction than even that, and you are giving up significant specificity and determinism. Is it a good abstraction? That’s a great question. But it certainly is an abstraction.
- HarHarVeryFunny 6mo ago
  > This is not entirely true. A high level language defines some behaviors, leaving many behaviors to be undefined and implementation specific. Sure, but you don't need to use those, and shouldn't. A programming language let's you avoid undefined behavior and stick to the defined abstraction provided by the language. Natural language does NOT let you do this, because words have no strict meaning, and the meaning of any sentence is undefined and up for interpretation and contextual clarification, etc, etc. Maybe more to the point LLMs are not concerned with meaning - they are concerned with continuation prediction. The LLM/agent that "ignored instructions" and deleted all the customer's data and backups wasn't "being bad" or "ignoring instructions", it was just statistically predicting, and someone was daft enough to feed those predictions into an execution environment where real world consequences could ensue.
  - dpark 6mo ago
    > A programming language let's you avoid undefined behavior and stick to the defined abstraction provided by the language. Yes and no. It lets you avoid undefined behavior traps. It lets you rely on endless implementation defined choices. > Natural language does NOT let you do this, because words have no strict meaning, and the meaning of any sentence is undefined and up for interpretation and contextual clarification, etc, etc. This is a fair criticism of natural language. It is less well defined. That doesn’t stop it from being an abstraction, though perhaps it fairly makes it a problematic abstraction. > The LLM/agent that "ignored instructions" and deleted all the customer's data and backups wasn't "being bad" or "ignoring instructions" That one was entirely human error. And not just “oops I trusted the AI too much”. That guy was sharing the DB volume across prod and staging so deleting the staging DB also took down prod. If you run your business like that, eventually a human will do the same thing, because it’s catastrophically dumb.
    - HarHarVeryFunny 6mo ago
      > It lets you avoid undefined behavior traps. It lets you rely on endless implementation defined choices. That's a strange way to think of a programming language specification. A programming language is an abstraction that mostly fully specifies behaviors that any compliant implementation must adhere to, and that you as a user of the language can therefore rely on. There may be a few details in a language specification that are specified as implementation defined, but that doesn't mean that are not specified, it just means they are specified by the implementation rather than the standard.

dpark 6mo ago

It wasn’t my analogy. It was the article’s so I responded to that. There are many more (and better) examples of how abstractions give up control, precision, and/or determinism. > The high level language defines it's own level of abstraction, defining exact behavior This is not entirely true. A high level language defines some behaviors, leaving many behaviors to be undefined and implementation specific. Many of those unspecified behaviors can matter in some cases. > It lets you get A result, but not define a SPECIFIC result, since natural languages just aren't that precise... You are repeating the same error as the article and missing the fact that while an abstraction lets you specify or control some things, it leaves many things out of your control. The higher the abstraction, the more stuff that is left out of your control. And maybe you don’t care about the things outside your control (great, the abstraction worked!) but regardless there are many things left unspecified in the typical abstraction and very often eventually you will care, which is why people say things like “all abstractions are leaky”. For a simple example, think of writing something like this: MessageBox(“hello world”, OkCancel) MessageBox is an abstraction over a massive amount of logic. You specified a string and a set of buttons and not much else. You give up control over the styling, the placement of the buttons, the actual button text (very likely will be localized), where the box will appear, and so much more. You are not getting a specific result. You are getting a result that meets the contract. “Write a program that shows a hello world message box” is a much higher level of abstraction than even that, and you are giving up significant specificity and determinism. Is it a good abstraction? That’s a great question. But it certainly is an abstraction.

HarHarVeryFunny 6mo ago
> This is not entirely true. A high level language defines some behaviors, leaving many behaviors to be undefined and implementation specific. Sure, but you don't need to use those, and shouldn't. A programming language let's you avoid undefined behavior and stick to the defined abstraction provided by the language. Natural language does NOT let you do this, because words have no strict meaning, and the meaning of any sentence is undefined and up for interpretation and contextual clarification, etc, etc. Maybe more to the point LLMs are not concerned with meaning - they are concerned with continuation prediction. The LLM/agent that "ignored instructions" and deleted all the customer's data and backups wasn't "being bad" or "ignoring instructions", it was just statistically predicting, and someone was daft enough to feed those predictions into an execution environment where real world consequences could ensue.
- dpark 6mo ago
  > A programming language let's you avoid undefined behavior and stick to the defined abstraction provided by the language. Yes and no. It lets you avoid undefined behavior traps. It lets you rely on endless implementation defined choices. > Natural language does NOT let you do this, because words have no strict meaning, and the meaning of any sentence is undefined and up for interpretation and contextual clarification, etc, etc. This is a fair criticism of natural language. It is less well defined. That doesn’t stop it from being an abstraction, though perhaps it fairly makes it a problematic abstraction. > The LLM/agent that "ignored instructions" and deleted all the customer's data and backups wasn't "being bad" or "ignoring instructions" That one was entirely human error. And not just “oops I trusted the AI too much”. That guy was sharing the DB volume across prod and staging so deleting the staging DB also took down prod. If you run your business like that, eventually a human will do the same thing, because it’s catastrophically dumb.
  - HarHarVeryFunny 6mo ago
    > It lets you avoid undefined behavior traps. It lets you rely on endless implementation defined choices. That's a strange way to think of a programming language specification. A programming language is an abstraction that mostly fully specifies behaviors that any compliant implementation must adhere to, and that you as a user of the language can therefore rely on. There may be a few details in a language specification that are specified as implementation defined, but that doesn't mean that are not specified, it just means they are specified by the implementation rather than the standard.