I'd like something running on the CLR. Not because I think the CLR is very special; just because I really like Haskell but I have to work within a large ecosystem of existing .NET code.
I've been playing with it some. It's nice, but I still prefer Haskell. I want to be able to separate pure from impure code, but F# doesn't seem to enforce that. (Unless I'm missing something?)
It doesn't. In fact, F# feels like it started off as a fairly pure functional language but some Microsoft PM said "it has to support every API in .NET" and so a lot of OOP stuff was bolted on the side. It feels like 2 different worlds in one language. You can easily get by never using the impure stuff but it's still there, taking up space.
F#'s design was almost completely handled by Don Syme, in MS Research Cambridge. It is highly unlikely some PM jumped in and insisted it must do things.
The OOP part is rather coherent; I'm not sure what's bolted on - any examples? In fact, things like object expressions do parts of OOP even better than Java/C#. Overall the syntax for OOP is rather concise and neat.
Having proper interop with .NET and hence the OOP is ... pretty key to making a successful .NET language. Otherwise you lose one major point of being able to use .NET libraries.
> The OOP part is rather coherent; I'm not sure what's bolted on - any examples? In fact, things like object expressions do parts of OOP even better than Java/C#. Overall the syntax for OOP is rather concise and neat.
I'm saying I'm not sure why the OOP exists at all. Someone else pointed at that OCaml has those elements as well, and maybe that's the reason. Just in my own use, I never felt the inclination to use the OOP at all, and their existence felt like this part of the language that I didn't understand, didn't want to understand, but was there nonetheless.
F# has its origins in OCaml which has the same set of properties (ability to write impure code and has an object system, albeit one that not many people use). F# replaced that object system with the .NET one.
