4 ms·

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

by 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
      > 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. This is true but hand waves over a lot of behavior. An implementation of Python could be 10x faster or 10x slower and still be fully compliant with the specification. There’s a reason that NumPy’s core is written in C and not Python. The implementation-specific details sometimes matter. The abstraction is leaky as soon as you care about anything not explicitly specified in the abstraction.
HarHarVeryFunny 6mo ago
> “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. But to who/what is it an abstraction? To a human, sure. If I told an intern to "write a hello world message box", I'd expect at least to get something approximating that request. To an LLM? The LLM has no intent or understanding - it's just a statistical predictor. Maybe it'll "interpret" your request as only wanting a hello world message box, so it'll delete your company's entire git repository to ensure a clean slate to start from. I think that when you say "it is certainly an abstraction" what you implicitly mean is "it is certainly an abstraction TO ME", but an LLM is not you, and does not have a brain, so what is an abstraction to you shouldn't be taken as being an abstraction to an LLM (whatever that would even mean).
- dpark 6mo ago
  No, we can’t retreat to the “LLMs so dumb” position every time we discuss anything around them. This is not a rebuttal. It is an interesting thing to discuss on its own merit, but it’s not relevant here. If a natural language specification is an abstraction over the code implementation, then it is an abstraction whether given to a human or an LLM. The LLM being arguably a bad tool does not change that.
  - HarHarVeryFunny 6mo ago
    So let's take LLMs and AI out of the discussion altogether. The question is then can specifying a computer behavior in (inherently imprecise) natural language be considered as some sort of "program", a higher level abstraction in same sense as a HLL provides a higher level of abstraction to programming in assembler? I would say no, for various reasons: 1) There is a difference between an abstraction and under-specifying your requirements 2) Whatever you want to call it, any descriptive language that is insufficiently precise to unambiguously describe the details that are important to you is not very useful as a way to specify system behavior 3) If you are not only using natural language to describe the desired behavior of a system, but are also assuming that the person (or thing) interpreting the description is bringing their own knowledge and expertise to bear in "fleshing out the details", then you don't have a full specification at all, even an abstract one. What you have in that case is not something analogous to a computer program, but more like business requirements.

by dpark 6mo ago

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
    > 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. This is true but hand waves over a lot of behavior. An implementation of Python could be 10x faster or 10x slower and still be fully compliant with the specification. There’s a reason that NumPy’s core is written in C and not Python. The implementation-specific details sometimes matter. The abstraction is leaky as soon as you care about anything not explicitly specified in the abstraction.

HarHarVeryFunny 6mo ago

> “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. But to who/what is it an abstraction? To a human, sure. If I told an intern to "write a hello world message box", I'd expect at least to get something approximating that request. To an LLM? The LLM has no intent or understanding - it's just a statistical predictor. Maybe it'll "interpret" your request as only wanting a hello world message box, so it'll delete your company's entire git repository to ensure a clean slate to start from. I think that when you say "it is certainly an abstraction" what you implicitly mean is "it is certainly an abstraction TO ME", but an LLM is not you, and does not have a brain, so what is an abstraction to you shouldn't be taken as being an abstraction to an LLM (whatever that would even mean).

dpark 6mo ago
No, we can’t retreat to the “LLMs so dumb” position every time we discuss anything around them. This is not a rebuttal. It is an interesting thing to discuss on its own merit, but it’s not relevant here. If a natural language specification is an abstraction over the code implementation, then it is an abstraction whether given to a human or an LLM. The LLM being arguably a bad tool does not change that.
- HarHarVeryFunny 6mo ago
  So let's take LLMs and AI out of the discussion altogether. The question is then can specifying a computer behavior in (inherently imprecise) natural language be considered as some sort of "program", a higher level abstraction in same sense as a HLL provides a higher level of abstraction to programming in assembler? I would say no, for various reasons: 1) There is a difference between an abstraction and under-specifying your requirements 2) Whatever you want to call it, any descriptive language that is insufficiently precise to unambiguously describe the details that are important to you is not very useful as a way to specify system behavior 3) If you are not only using natural language to describe the desired behavior of a system, but are also assuming that the person (or thing) interpreting the description is bringing their own knowledge and expertise to bear in "fleshing out the details", then you don't have a full specification at all, even an abstract one. What you have in that case is not something analogous to a computer program, but more like business requirements.