Strictness of syntax and language. It means that ctrl+space gives you exactly right methods into popup, that if you rename the class all places that use that class and no other will be changed, you can rename method and trust that all correct calls will be renamed too and no other.

You can find all the places that call a method and know they are really all. That sort of basic thing.

E.g. not for writing, but for analyzing what unknown code does and for refactoring that code. Comparing to javascript, in js you have to be much more careful when refactoring and changing things.

I think this is possible with any statically typed language, all of which today have IDE's that can do exactly this.

Most static languages. In my experience the typscript masquerade breaks down too often and you can't rely on IDE omniscience.

> “Code should be written for humans to read and only incidentally for machines to run”

So this is a cute statement but isn't it actually false? None of us would be sitting around code reviewing each other's code for fun if there wasn't a mountain of money / value / knowledge to be extracted from a computer running the code at the end of the day.

Actually this is easily falsifiable. As soon as quantum computing becomes possible the first languages will probably be quite horrible, with painful tooling and torturous debugging and difficult to read control flow compared to current modern languages. Nonetheless, a huge army of programmers will be trying to write code for these quantum computers, for the sake of the computer, and not for any human to read.

Another "Actually this is false in the corner case I'm going to call out".

Of course its not a universal rule, its not a law of physics. Doesn't make it less useful as a guiding principle (similarly, design patterns in software architecture).

The core argument is that we're besides the point in conventional (2019) computing where we need to worry too much about optimizing code to run as efficiently as possible. The complexity and bottlenecks to delivering features is now in writing software that is meant to be worked on and maintained by a large number of humans. And for that purpose, it is better to optimize for clarity.

But it's not really a corner case though. For a lot of professional applications it's perfectly fine to make a tradeoff of complexity or readability in order to get performance. And that tradeoff is done for business reasons - because sometimes the computer is more important than the programmer.

incidentally:

1. used when a person has something more to say, or is about to add a remark unconnected to the current subject; by the way.

2. in an incidental manner; as a chance occurrence.

That quote seems pretty misinformed, code has to be a lot more connected to the machine to be runnable that that quote would have us believe.

Otherwise this would be valid code:

Ask the user their name. After they enter the name, load a game. Use some cool graphics.

That being said, perhaps that will be possible in 100 years. (Yes the first line may be possible in 10 years)

"Code should be primarily written for humans to read. Only in rare cases should the code be primarily written for the machine in mind"

In other words, don't doo premature optimization. Write the code so that it's readable, except on the chance occurrence where you need to eke out more performance.