5 ms·

Sounds a bit like the Scala story: could be a really nice language, but the bagagge ... :)

bunderbunder 9y ago
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.
- catnaroek 9y ago
  > Concrete example: It doesn't have typeclasses. 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.
  - tueo23094 9y ago
    F# and OCaml are different languages with different goals. It should come as no surprise there are different sacrifices between the languages. Breaking compatibility with .NET, which is F#'s biggest benefit is counter productive.
    - catnaroek 9y ago
      My suggestion wouldn't “break compatibility” with .NET any more than, say, C++/CLI (or whatever it is called nowadays) does.
- vittore 9y ago
  Wait it has https://docs.microsoft.com/en-us/dotnet/fsharp/language-reference/discriminated-unions https://docs.microsoft.com/en-us/dotnet/fsharp/language-refe...
  - dualogy 9y ago
    Those are essentially ADTs --- not "type-classes" in the ML/Haskell/etc sense at all.

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.

catnaroek 9y ago
> Concrete example: It doesn't have typeclasses. 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.
- tueo23094 9y ago
  F# and OCaml are different languages with different goals. It should come as no surprise there are different sacrifices between the languages. Breaking compatibility with .NET, which is F#'s biggest benefit is counter productive.
  - catnaroek 9y ago
    My suggestion wouldn't “break compatibility” with .NET any more than, say, C++/CLI (or whatever it is called nowadays) does.
vittore 9y ago
Wait it has https://docs.microsoft.com/en-us/dotnet/fsharp/language-reference/discriminated-unions https://docs.microsoft.com/en-us/dotnet/fsharp/language-refe...
- dualogy 9y ago
  Those are essentially ADTs --- not "type-classes" in the ML/Haskell/etc sense at all.