11–20 of 26 posts
This is not in any way similar to what humans do.
Feel this strongly. That all of the "autocomplete"-style improvements that LLMs to programming are indications of massive deficiencies in programming: we're in many ways stuck in a ~2010-era model of what programming is, which is actually quite medieval and useless. Probably programs as "text that you run on a computer" is, long-term, not how anything is going to be done. After all, what is a prompt but a (lossy, err…
Suppose that an LLM would produce excellent, production-ready code automatically given high-quality architecture and design documentation and proper requirements. Could we offload the code generation to the machine and focus on producing architecture and design documentation? And would that provide meaningful improvements? I don't know the answer to that. But it's an interesting point that's buried in the article is…
Often it feels more efficient to take shorter steps, try something in code, we how it looks, update docs, show a demo, etc. That was true before LLMs and I think LLMs make it even more true.
Suppose that an LLM would produce excellent, production-ready code automatically given high-quality architecture and design documentation and proper requirements. Could we offload the code generation to the machine and focus on producing architecture and design documentation? And would that provide meaningful improvements? I don't know the answer to that. But it's an interesting point that's buried in the article is…
Feel this strongly. That all of the "autocomplete"-style improvements that LLMs to programming are indications of massive deficiencies in programming: we're in many ways stuck in a ~2010-era model of what programming is, which is actually quite medieval and useless. Probably programs as "text that you run on a computer" is, long-term, not how anything is going to be done. After all, what is a prompt but a (lossy, err…
This is in some ways a circular argument / problem. Because, what does a well-specified formalisation of a problem solution look like? It looks like a programming language. Since COBOL, the dream has been a language which is formalised for computers while being understandable and able to be written by "business users". We've been promised this future by COBOL, Visual Basic, SQL, and many others. And what does the rea…
LLMs are great (sometimes) for conversational editing where there's a fast, iterative back and forth between description, code, clarification and touch-ups, etc. But trying to avoid code entirely eventually makes everything harder, not easier.
Feel this strongly. That all of the "autocomplete"-style improvements that LLMs to programming are indications of massive deficiencies in programming: we're in many ways stuck in a ~2010-era model of what programming is, which is actually quite medieval and useless. Probably programs as "text that you run on a computer" is, long-term, not how anything is going to be done. After all, what is a prompt but a (lossy, err…
Feel this strongly. That all of the "autocomplete"-style improvements that LLMs to programming are indications of massive deficiencies in programming: we're in many ways stuck in a ~2010-era model of what programming is, which is actually quite medieval and useless. Probably programs as "text that you run on a computer" is, long-term, not how anything is going to be done. After all, what is a prompt but a (lossy, err…
... And you want a representation of that abstraction to persist on disk?
... But it shouldn't be "text"?
Why not?
And how will you communicate it? You want to prompt in lossy, error-prone, inexact text, and then trust that an opaque binary blob correctly represents the formalization of what you meant? Or go through feedback cycles of trying to correct it with more prompting, but without the ability to edit manually?
> but no amount of text-generation gets around the fact that maybe text generation is... not... what we should be doing, actually.
Well, sure. But that isn't a problem with text; it's a problem with boilerplate in our designs.
Feel this strongly. That all of the "autocomplete"-style improvements that LLMs to programming are indications of massive deficiencies in programming: we're in many ways stuck in a ~2010-era model of what programming is, which is actually quite medieval and useless. Probably programs as "text that you run on a computer" is, long-term, not how anything is going to be done. After all, what is a prompt but a (lossy, err…
Right. If an LLM is capable of writing good boilerplate code for you then your programming language is too low level. We need higher level languages which abstract away most of the repetitive patterns. What would a language look like where the code has much higher "entropy" but is still human readable and maintainable? Like could we design a language that combines all of the productivity advantages of APL / Lisp / Pr…
You can get a lot of APL / LISP feeling out of carefully written Python or JavaScript. Not the metaprogramming stuff, sure. But a lot of that in LISP depends on homoiconicity, which is one of the biggest things making the language "not usable by average developers".
Feel this strongly. That all of the "autocomplete"-style improvements that LLMs to programming are indications of massive deficiencies in programming: we're in many ways stuck in a ~2010-era model of what programming is, which is actually quite medieval and useless. Probably programs as "text that you run on a computer" is, long-term, not how anything is going to be done. After all, what is a prompt but a (lossy, err…
Every time people attempted on this they ended up with a programming language that is harder to use than usual programming languages.
SQL was marketed as "fourth-generation programming language."
Two other examples that come to mind: Github Actions, and node-based visual programming.
Feel this strongly. That all of the "autocomplete"-style improvements that LLMs to programming are indications of massive deficiencies in programming: we're in many ways stuck in a ~2010-era model of what programming is, which is actually quite medieval and useless. Probably programs as "text that you run on a computer" is, long-term, not how anything is going to be done. After all, what is a prompt but a (lossy, err…
> Can we formalize that abstraction such that the prompt is an exact specification, just, at a super high level Every time people attempted on this they ended up with a programming language that is harder to use than usual programming languages. SQL was marketed as "fourth-generation programming language." Two other examples that come to mind: Github Actions, and node-based visual programming.