Agreed for ML. However, F# is not exactly ML. It lives on top of, and has to interoperate with, the existing .NET ecosystem.
That means, for example, that a lot of the datatypes you'll end up dealing with are object-oriented. Those can be difficult to work with in a generic way without resorting to reflection.
It is a really nice language. Being able to interoperate with .NET is a strength, not a weakness. It's quite principled in its design, it's just that some of its design principles are pragmatic ones.
Concrete example: It doesn't have typeclasses. This was a deliberate and thoughtful move. The designers haven't been able to figure out how to implement type classes in a way that wouldn't interact poorly with the rest of the .NET ecosystem, so they've opted to keep them out rather than introducing a hacky implementation. Contrast this with Scala, where it's very easy to accidentally break compatibility with Java code when you're working with traits.
It's not like type classes are themselves suuuper-principled.
> Being able to interoperate with .NET is a strength, not a weakness.
Being able to interoperate with .NET is a good thing. Letting the .NET object model permeate the whole language's type structure is less of a good thing (to put it mildly). OCaml did the right thing w.r.t. objects: You can use objects if you so wish, but the language doesn't ram them down your throat.
13 comments
[ 2.8 ms ] story [ 33.9 ms ] threadWow! This code looks horrible. Why don't you just accept the fact that the language is strongly typed and abolish reflection altogether?
That means, for example, that a lot of the datatypes you'll end up dealing with are object-oriented. Those can be difficult to work with in a generic way without resorting to reflection.
Concrete example: It doesn't have typeclasses. This was a deliberate and thoughtful move. The designers haven't been able to figure out how to implement type classes in a way that wouldn't interact poorly with the rest of the .NET ecosystem, so they've opted to keep them out rather than introducing a hacky implementation. Contrast this with Scala, where it's very easy to accidentally break compatibility with Java code when you're working with traits.
It's not like type classes are themselves suuuper-principled.
> Being able to interoperate with .NET is a strength, not a weakness.
Being able to interoperate with .NET is a good thing. Letting the .NET object model permeate the whole language's type structure is less of a good thing (to put it mildly). OCaml did the right thing w.r.t. objects: You can use objects if you so wish, but the language doesn't ram them down your throat.
Breaking compatibility with .NET, which is F#'s biggest benefit is counter productive.