Dijkstra On the foolishness of "natural language programming"

> 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 undetected mistakes.)

If I didn't know who wrote this it would seem like a jab directly at people who dislike Rust.

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.

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.

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.

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.

> 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.

I'm not sure you tried to understand what I've depicted.

As long as you don't know how the end result should look like there are no "mistakes".

The whole point of explorative work is to find out how to approach something in the first place.

It's usually impossible to come up with the final result at first try!

After you actually know how to do something in general tools which help to avoid all undetected mistakes in the implementation of the chosen approach are really indispensable. But before having this general approach figured out too much rigidity is not helpful but instead a hindrance.

To understand this better read the linked article. It explains the problem very well over a few paragraphs.

"Rust as both language and community is so preoccupied with avoiding problems at all cost that it completely loses sight of what matters, delivering an experience that is so good that whatever problems are there aren't really important."

Eh, I'm being mugged by Rust-lovers. But as soon as I read Dijkstra's snotty remark about how making mistakes is the opposite of easy (!?) I had an intuitive reaction of "balls". Maybe that was a mistake, but it came easy.

> You have a price to pay for "not being allowed to do mistakes": Explorative work becomes quite difficult

This is a huge deal for me.

At the beginning of most "what if...?" exercises, I am just trying to get raw tuples of information in and out of some top-level-program logic furnace for the first few [hundred] iterations. I'll likely resort to boxing and extremely long argument lists until what I was aiming for actually takes hold.

I no longer have an urge to define OOP type hierarchies when the underlying domain model is still a vague cloud in my head. When unguided, these abstractions feel like playing Minecraft or Factorio.