3 ms·

What you're describing is decontextualization. A sufficiently powerful transformer would theoretically be able recontextualize a sufficiently descriptive natura

What you're describing is decontextualization. A sufficiently powerful transformer would theoretically be able recontextualize a sufficiently descriptive natural language specification. Likewise, the same or an equivalently powerful transformer should be able to fully capture the logic of a complicated program. We just don't have sufficient transformers yet. I don't see why a complete description of the program's design philosophy as well as complete descriptions of each system and module and interface wouldn't be enough. We already produce code according to project specification and logically fill in the gaps by using context.

scribu 2y ago
“Fill in the gaps by using context” is the hard part. You can’t pre-bake the context into an LLM because it doesn’t exist yet. It gets created through the endless back-and-forth between programmers, designers, users etc.
- soulofmischief 2y ago
  But the end result should be a fully-specced design document. That might theoretically be recoverable from a complete program given a sufficiently powerful transformer.
  - skydhash 2y ago
    Peter Naur would disagree with you. From "Programming as Theory Building": A very important consequence of the Theory Building View is that program revival, that is reestablishing the theory of a program merely from the documentation, is strictly impossible. Lest this consequence may seem un- reasonable it may be noted that the need for revival of an entirely dead program probably will rarely arise, since it is hardly conceivable that the revival would be assigned to new programmers without at least some knowledge of the theory had by the original team. Even so the The- ory Building View suggests strongly that program revival should only be attempted in exceptional situations and with full awareness that it is at best costly, and may lead to a revived theory that differs from the one originally had by the program authors and so may contain discrep- ancies with the program text. The definition of theory used in the article: a person who has or possesses a theory in this sense knows how to do certain things and in addition can support the actual doing with explanations, justi- fications, and answers to queries, about the activity of concern. And the main point on how this relate to programming: - 1 The programmer having the theory of the program can explain how the solution relates to the affairs of the world that it helps to handle. Such an explanation will have to be concerned with the manner in which the af- fairs of the world, both in their overall characteristics and their details, are, in some sense, mapped into the pro- gram text and into any additional documentation. - 2 The programmer having the theory of the program can explain why each part of the program is what it is, in other words is able to support the actual program text with a justification of some sort. The final basis of the justification is and must always remain the programmer’s direct, intuitive knowledge or estimate. - 3 The programmer having the theory of the program is able to respond constructively to any demand for a modification of the program so as to support the affairs of the world in a new manner. Designing how a modifi- cation is best incorporated into an established program depends on the perception of the similarity of the new demand with the operational facilities already built into the program. The kind of similarity that has to be per- ceived is one between aspects of the world.
izabera 2y ago
>sufficiently descriptive natural language specification https://www.commitstrip.com/en/2016/08/25/a-very-comprehensive-and-precise-spec/ https://www.commitstrip.com/en/2016/08/25/a-very-comprehensi...
- soulofmischief 2y ago
  No, the key difference is that an engineer becomes more product-oriented, and the technicalities of the implementation are deprioritized. It is a different paradigm, in the same way that a high-level language like JavaScript handles a lot of low-level stuff for me.
  - soraminazuki 2y ago
    A programming language implementation produces results that are controllable, reproducible, and well-defined. An LLM has none of those properties, which makes the comparison moot. Having an LLM make up underspecified details willy-nilly, or worse, ignore clear instructions is very different from programming languages "handling a lot of low-level stuff."
    - soulofmischief 2y ago
      [citation needed] You can set temperature to 0 in many LLMs and get deterministic results (on the same hardware, given floating-point shenanigans). You can provide a well-defined spec and test suite. You can constrain and control the output.
      - soraminazuki 2y ago
        LLMs produce deterministic results? Now, that's a big [citation needed]. Where can I find the specs? Edit: This is assuming by "deterministic," you mean the same thing I said about programming language implementations being "controllable, reproducible, and well-defined." If you mean it produces random but same results for the same inputs, then you haven't made any meaningful points.

scribu 2y ago

“Fill in the gaps by using context” is the hard part. You can’t pre-bake the context into an LLM because it doesn’t exist yet. It gets created through the endless back-and-forth between programmers, designers, users etc.

soulofmischief 2y ago
But the end result should be a fully-specced design document. That might theoretically be recoverable from a complete program given a sufficiently powerful transformer.
- skydhash 2y ago
  Peter Naur would disagree with you. From "Programming as Theory Building": A very important consequence of the Theory Building View is that program revival, that is reestablishing the theory of a program merely from the documentation, is strictly impossible. Lest this consequence may seem un- reasonable it may be noted that the need for revival of an entirely dead program probably will rarely arise, since it is hardly conceivable that the revival would be assigned to new programmers without at least some knowledge of the theory had by the original team. Even so the The- ory Building View suggests strongly that program revival should only be attempted in exceptional situations and with full awareness that it is at best costly, and may lead to a revived theory that differs from the one originally had by the program authors and so may contain discrep- ancies with the program text. The definition of theory used in the article: a person who has or possesses a theory in this sense knows how to do certain things and in addition can support the actual doing with explanations, justi- fications, and answers to queries, about the activity of concern. And the main point on how this relate to programming: - 1 The programmer having the theory of the program can explain how the solution relates to the affairs of the world that it helps to handle. Such an explanation will have to be concerned with the manner in which the af- fairs of the world, both in their overall characteristics and their details, are, in some sense, mapped into the pro- gram text and into any additional documentation. - 2 The programmer having the theory of the program can explain why each part of the program is what it is, in other words is able to support the actual program text with a justification of some sort. The final basis of the justification is and must always remain the programmer’s direct, intuitive knowledge or estimate. - 3 The programmer having the theory of the program is able to respond constructively to any demand for a modification of the program so as to support the affairs of the world in a new manner. Designing how a modifi- cation is best incorporated into an established program depends on the perception of the similarity of the new demand with the operational facilities already built into the program. The kind of similarity that has to be per- ceived is one between aspects of the world.

izabera 2y ago

>sufficiently descriptive natural language specification https://www.commitstrip.com/en/2016/08/25/a-very-comprehensive-and-precise-spec/ https://www.commitstrip.com/en/2016/08/25/a-very-comprehensi...

soulofmischief 2y ago
No, the key difference is that an engineer becomes more product-oriented, and the technicalities of the implementation are deprioritized. It is a different paradigm, in the same way that a high-level language like JavaScript handles a lot of low-level stuff for me.
- soraminazuki 2y ago
  A programming language implementation produces results that are controllable, reproducible, and well-defined. An LLM has none of those properties, which makes the comparison moot. Having an LLM make up underspecified details willy-nilly, or worse, ignore clear instructions is very different from programming languages "handling a lot of low-level stuff."
  - soulofmischief 2y ago
    [citation needed] You can set temperature to 0 in many LLMs and get deterministic results (on the same hardware, given floating-point shenanigans). You can provide a well-defined spec and test suite. You can constrain and control the output.
    - soraminazuki 2y ago
      LLMs produce deterministic results? Now, that's a big [citation needed]. Where can I find the specs? Edit: This is assuming by "deterministic," you mean the same thing I said about programming language implementations being "controllable, reproducible, and well-defined." If you mean it produces random but same results for the same inputs, then you haven't made any meaningful points.