It all depends on the lens one chooses to view them. None of them are really "functional programming" in the truly modern sense, even F#. As more and more mainstream languages get pattern matching and algebraic data types (such as Python), feature lambdas and immutable values, then these languages converge. However, you don't really get the promises of functional programming such as guaranteed correct composition and easier reasoning/analysis, for that one needs at least purity and perhaps even totality. That carries the burden of proof, which means things get harder and perhaps too hard for some (e.g. the parent poster).
raddan|4 months ago
It’s pretty easy to stick to pure F# if what you want is the pure functional programming experience. But what I like about it is its pragmatism, and this is a big reason why it’s the language I chose for the course. It is by-value, eagerly evaluated by default, and has an easy-to-learn idiomatic syntax. It has a large and well-behaved standard library, and you can use C#’s excellent standard library if you need additional things (e.g., mutable data structures). I have used F# in many performance-sensitive applications, and the fact that I can say “you know, inside this function, I’m going to use mutability, raw pointers, and iteration” has been a lifesaver in some places. But because it is a functional language, I can also abstract all that away and pretend that it is functional.
I understand why other FP folks dislike this approach. But the insistence on purity makes many problems artificially difficult. Debugging a lazily evaluated program is a nightmare. There are lots of times I want a well-behaved language but I am not willing to do CS research just to solve common algorithmic problems. The generally pragmatic streak from the SML family makes them easy to love.
maleldil|4 months ago
grumpyprole|4 months ago