You could say that "almost functional" does not really exist, just like "almost secure" does not exist.

And yes, you can still program with a non-functional language just fine he does not refute that.

Yes. And what I say is that "I get enough benefits from going halfway functional, thank you very much".

>You could say that "almost functional" does not really exist, just like "almost secure" does not exist.

You could say that but you would be wrong. Most Lisp coders for example have also used imperative code where they need it, with side effects and all. Nobody cared much about such total "functionalness" and purity as you get today from Haskell programmers (most of them non professional of course since there are far more Haskell programmers than Haskell jobs) and the like...

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.

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.

Yeah, well, for those of us who actually write programs, pragmatism matters a lot. If you're going to tell us how we should do it, but without anything like pragmatism, you're not going to get much of a hearing from the people you think you're trying to talk to.

So you don't have to mix effects with laziness, you can mix effects and other functional constructs (pure functions, immutable values, closures, map, fold, homoiconicity and macros, etc) and you still get a huge benefit.

So the theme of the article "mostly functional can't work" is wrong.

You're right. It's not really an issue of "functional" at all. It's worth noting that the author is an incorrigible (yet gentle) troll who likes to poke fun at Haskell and non-Haskell languages alike.

Whether or not I read the article correctly, tome's comment was brilliant. It very succinctly exposed the pragmatic issue at stake.