Interesting read. To his defense: the argument is not that Optionals are too complicated, but that it’s a wrong path for language design — instead programmers have to test their code properly.
I like optionals, but I see his point too.
I like optionals, but I see his point too.
But at the end of the day, he's a guy with a long career in programming, which makes him significantly better than the median, but it doesn't make him three sigma above.
In this case, he's got a pretty good short- to medium-term argument that if you have a robust testing and verification suite, AI code that passes it all is a terrific outcome.
I'm really not convinced about long-term. Possibly, AI ends up writing even better in the future and we never have to worry about human maintainability.
But it's also possible AI is at/near its limit, and we'll always need human maintainers. In which case, incomprehensible vibe coding might be a problem.
This does not require a new language feature every time there is a bug, as he asserts. It requires language features to let you be descriptive in your type definitions so that invalid program states don't exist by definition. You literally cannot write one down. It's the same idea as saying you can't assign a Monkey to an int64. Scala's ZIO also shows that in fact you can type-infer whether a given path will produce errors or nulls, so you don't need to have perfect knowledge up front or go back and change tons of code if that changes. Errors can automatically propagate, and you need to handle them once, somewhere. Checked exceptions were a fantastic idea; you just need to let the compiler infer them everywhere.
Or you just rely on the type checker to say you're not allowed to pass a Book to a variable of type Account, and you never use casting (incidentally, I don't remember where, but I remember Clean Code having some example of "good" code that relies on casts, which shows the mindset). Then you literally can't even write a test case for this, because it's impossible to write the illogic at all.
If the compiler produces wrong code, all bets are off. Your tests can also miscompile. Your unsafe code could modify another thread's stack memory between instructions and act as an evil gremlin so that literally no line is trustworthy, so even your null check is pointless. Or you could... not do that, and treat your programs as logical reasoning.
Charles Babbage even addressed this:
> On two occasions I have been asked, 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question.