People are supposed to communicate symbolically with LLMs too
Dijkstra On the foolishness of "natural language programming"
91–100 of 281 posts
Re: Dijkstra On the foolishness of "natural language programming"
#92> It was a significant improvement that now many a silly mistake did result in an error message instead of in an erroneous answer. (And even this improvement wasn't universally appreciated: some people found error messages they couldn't ignore more annoying than wrong results, and, when judging the relative merits of programming languages, some still seem to equate "the ease of programming" with the ease of making un…
Rust? Since when is Rust the pinnacle of static type safety?
After I've worked for some time with a language that can express even stronger invariants in types than Rust (Scala) I don't see that property anymore as clear win regardless circumstances. I don't think any more "stronger types == better, no matter what".
You have a price to pay for "not being allowed to do mistakes": Explorative work becomes quite difficult if the type system is really rigid. Fast iteration may become impossible. (Small changes may require to re-architecture half your program, just to make the type system happy again![1])
It's a trade-off. Like with everything else. For a robust end product it's a good thing. For fast experimentation it's a hindrance.
[1] Someone described that issue quite well in the context of Rust and game development here: https://loglog.games/blog/leaving-rust-gamedev/
But it's not exclusive to Rust, nor game dev.
Re: Dijkstra On the foolishness of "natural language programming"
#93> It was a significant improvement that now many a silly mistake did result in an error message instead of in an erroneous answer. (And even this improvement wasn't universally appreciated: some people found error messages they couldn't ignore more annoying than wrong results, and, when judging the relative merits of programming languages, some still seem to equate "the ease of programming" with the ease of making un…
As a person who dislikes rust, the problem is the error messages when there's no error -- quite a different problem. The rust type system is not an accurate model of RAM, the CPU and indeed, no device.
He's here talking about interpreted languages.
He's also one of those mathematicians who are now called computer scientists whose 'algorithms' are simple restatements of mathematics and require no devices. A person actively hostile, in temperament, to the embarrassing activity of programming an actual computer.
Re: Dijkstra On the foolishness of "natural language programming"
#94> It was a significant improvement that now many a silly mistake did result in an error message instead of in an erroneous answer. (And even this improvement wasn't universally appreciated: some people found error messages they couldn't ignore more annoying than wrong results, and, when judging the relative merits of programming languages, some still seem to equate "the ease of programming" with the ease of making un…
I would have thought of people who unironically liked fractal-of-bad-design-era PHP and wat-talk JavaScript.
I guess some kinds of foolishness are just timeless.
Re: Dijkstra On the foolishness of "natural language programming"
#95> It was a significant improvement that now many a silly mistake did result in an error message instead of in an erroneous answer. (And even this improvement wasn't universally appreciated: some people found error messages they couldn't ignore more annoying than wrong results, and, when judging the relative merits of programming languages, some still seem to equate "the ease of programming" with the ease of making un…
Rust? Since when is Rust the pinnacle of static type safety? After I've worked for some time with a language that can express even stronger invariants in types than Rust (Scala) I don't see that property anymore as clear win regardless circumstances . I don't think any more "stronger types == better, no matter what". You have a price to pay for "not being allowed to do mistakes": Explorative work becomes quite diffic…
I can't remember if I came up with this analogy or not, but programming in Rust is like trying to shape a piece of clay just as it's being baked.
Re: Dijkstra On the foolishness of "natural language programming"
#96> It was a significant improvement that now many a silly mistake did result in an error message instead of in an erroneous answer. (And even this improvement wasn't universally appreciated: some people found error messages they couldn't ignore more annoying than wrong results, and, when judging the relative merits of programming languages, some still seem to equate "the ease of programming" with the ease of making un…
Rust? Since when is Rust the pinnacle of static type safety? After I've worked for some time with a language that can express even stronger invariants in types than Rust (Scala) I don't see that property anymore as clear win regardless circumstances . I don't think any more "stronger types == better, no matter what". You have a price to pay for "not being allowed to do mistakes": Explorative work becomes quite diffic…
> Explorative work becomes quite difficult if the type system is really rigid
Or to put it another way, the ease of programming is correlated with the ease of making undetected mistakes.
Re: Dijkstra On the foolishness of "natural language programming"
#97> Machine code, with its absence of almost any form of redundancy, was soon identified as a needlessly risky interface between man and machine. Partly in response to this recognition so-called "high-level programming languages" were developed, and, as time went by, we learned to a certain extent how to enhance the protection against silly mistakes. It was a significant improvement that now many a silly mistake did result in an error message instead of in an erroneous answer.
I feel that we’ve collectively jumped into programming with LLMs too quickly. I really liked how Rust has iterated on pointing out “silly mistakes” and made it much more clear what the fix should be. That’s a much more favorable development for me as a developer. I still have the context and understanding of the code I work on while the compiler points out obvious errors and their fixes. Using an LLM feels like a game of semi-intelligent guessing on the other hand. Rust’s compiler is the master teaching the apprentice. LLMs are the confident graduate correcting the master. I greatly prefer Rust’s approach and would like to see it evolved further if possible.
Re: Dijkstra On the foolishness of "natural language programming"
#98Earlier quoted context omitted.
I'm not so sure it's about precision rather than working memory. My presumption is people struggle to understand sufficiently large prose versions for the same reason a LLM would struggle working with larger prose versions: people have limited working memory. The time needed to reload info from prose is significant. People reading large text works will start highlighting and taking notes and inventing shorthand forms…
So is more compact better? Does K&R's *d++ = *s++; get a pass now?
No, but *++d = *++s; does.
Re: Dijkstra On the foolishness of "natural language programming"
#99Earlier quoted context omitted.
>sufficiently descriptive natural language specification https://www.commitstrip.com/en/2016/08/25/a-very-comprehensi...
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.
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."
Re: Dijkstra On the foolishness of "natural language programming"
#100Earlier quoted context omitted.
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.
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."
[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.