You can have perfect safety, or you can have a workable system delivered in a timely manner.
And there are probably very good reasons why a language like Haskell is not likely to be chosen for this kind of application. Consider predictability: Haskell may make it easy to prove algorithmic correctness, but its laziness makes runtime characteristics more difficult to reason about because they're hidden behind so much abstraction. This could make it very difficult to deal with stuff like subtle bugs related to timing issues that might crop up in an electromechanical system.
Not Haskell and not even Lisp.
The last thing you want from a perfectly safe system is some lazyness smartness in the compiler hitting at the wrong time and affecting execution time, memory use etc, or things like GC pauses.
I do every time I get in a plane.
This one might come down to conflicting definitions of "safe". The author seems to define safety purely in relation to the number of language features with which you can contrive to shoot yourself in the foot. You seem to also take into account the number of language features you can use to make it harder to shoot yourself in the foot.
I think there's some value in both definitions. The author's perspective captures a lot of what worries me about languages like C++. But it also fails to give C++ any credit for all the language improvements that have materially improved the overall quality of most C++ code over the past couple decades.
I did, did you?
>His point was that introducing some functional features to imperative languages do not confer them the safety benefits found in type systems such as Haskell's.
And my point was that I don't want ALL the safety benefits found in type systems such as Haskells. If I would, I would be using Haskell. Or rather, while I might want it, I also want other things more, so I wouldn't sacrifice all of them to get it.
His point was that mostly functional "does not work" which is a BS thing to say, because it's an absolute statement. And his whole article revolves around that absolute, e.g.:
>The idea of "mostly functional programming" is unfeasible. It is impossible to make imperative programming languages safer by only partially removing implicit side effects.
Nope, you can very much make them safer. It might not make them the "safest" it can be, but it can totally make them safer. Even merely substituting for loops with map and fold will eliminate lots of potential bugs.
Heck, you can even make C much safer by just removing pointer arithmetic or just adding a built-in string type. Either of those two things alone would eliminate tons of bugs while the language would remain the imperative thing that it is.