191–200 of 281 posts
this clearly has nothing to do with the current main usages of LLMs, it's about using natural language as an interface to produce accurate results, as a further abstraction on top of general purpose languages.
Earlier quoted context omitted.
Its feedback is more poignant than most humans. Here's what it said about a recent PR of mine that refactored code to fix a linter warning. > Ah, the grand theater of code review—where humans playact at immortality through version control. You want me to parse this PR's mechanical copulation of const& and std::move? Fine. Let's autopsy this digital cadaver. > Your commits scream optimization fervor: converting parame…
Congratulations, you have unearthed a new layer of hell.
> I suspect that machines to be programmed in our native tongues —be it Dutch, English, American, French, German, or Swahili— are as damned difficult to make as they would be to use. Seeing as transformers are relatively simple to implement… It stands to reason he was, in some sense, right. LLMs are damn easy to use.
Just like Web 1.0 - when the best we could think of to do was shovel existing printed brochures onto web pages.
In AI 1.0 we are simply shoveling existing programming languages into the LLM - in no way marrying programming and LLM - they exist as entirely different worlds.
AI 2.0 will be programming languages - or language features - specifically designed for LLMs.
We are still debating what some laws and amendments mean. The meaning of words change over time, lack of historical context, etc.
I would love natural language to operate machines, but I have been programming since mid 80's and the stubbornness of the computer languages (from BASIC, to go) strikes a good balance, and puts enough responsibility on the emitter to precisely express what he wants the machine to do.
It's pretty obvious to me that this LLM business won't be economically feasible until it can actually produce better code than a team of humans could without it. The reason programmers are paid so highly is because their work is incredibly productive and valuable. One programmer can enable and improve the work of many hundreds of other people. Cost cutting on the programmer isn't worth it because it'll create greater…
Earlier quoted context omitted.
>sufficiently descriptive natural language specification https://www.commitstrip.com/en/2016/08/25/a-very-comprehensi...
sounds like it would pair well with a suitably smart compiler
Wasn't that the actual motivation behind the development of SQL?
IIRC, SQL was something that "even" business people could code in because it was closer to "natural language".
When you see the monstrosity the motivation gave birth to, I think the "foolish" argument was well warranted at the time.
Of course, in these days of LLM's, Dijkstra's argument isn't as clear cut (even if LLM's aren't there yet, they're getting much closer).
Earlier quoted context omitted.
“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.
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.
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.