I'm not a language expert by any means, but I suspect the thinking behind that one is to make it easier to work out which code needs try/catch blocks. For example, in my own (say) C# code I often simply don't catch any exceptions which I'm not expecting, which makes them actually no better than errors. Even in production code I have only very crude handling for unexpected exceptions which leaves them still being quite error-like.
More generally I think "if the compiler doesn't beep, my program should work" is wrong. I mean, it's so massively, outrageously wrong that I can only assume I'm not quite understanding what he intended by it.
His perspective on concurrency seems a bit daft to me too (although I'm guessing there was more to the talk than the slides show). Concurrency isn't hard because it's badly implemented, it's
inherently hard. Anything which auto-solves the problems is just relocating the complexity (and maybe bugs) to some new area. I can't help suspecting someone's forgotten their
Fred Brooks.
His comment about pointers vs optional values I do agree with, but any solution comes with its own problems in terms of handling missing optional objects. Instead of endless null checks or endless try/catch blocks you end up with endless checks for whether an optional thing is actually there or not. Semantically that seems... basically the same?
Overall though, this seems like sensible stuff. He's advocating more more functional programming, which is something people have been talking about for at least 40 years and it continues to be a good idea (but apparently hard to integrate well with imperative thinking). And he's talking about the flaws of systems he's an expert in, which is always worthwhile reading.
His "effects free" thinking is very much at the heart of functional programming. I remember writing lots of OCaML back in the 90s and struggling to formulate stuff in pure functional terms. I often failed and wrote things with side effects, but at least it made me more aware of the issues.
Here's what's going to stop this being widely adopted, though: People don't like to write pure, functional code. It's been around for a while and, with a few notable exceptions, it doesn't really get used.
Developer
