6 ms·

Isn't there a large difference between supporting interop with code written in other languages and importing all the stuff into the language itself?

noblethrasher 13y ago
Well, if the language was only meant to be an API consumer then eliding OO stuff would make more sense, but they designed it for bi-directional interop. And besides, F# was based on OCaml (as I'm sure you know), which itself was an existence proof that you could successfully bolt OO onto a functional language.
- frowaway001 13y ago
  > successfully bolt OO onto a functional language Yes, I think that's a good description. It's not great, but it somehow works (although the whole F# community tends to tell people to stay away from OOP when not necessary). Would have been interesting to explore better ways to support OOP so that it doesn't need to be considered a second class citizen, but I guess it's too late for that now.
bunderbunder 13y ago
There's an enormous difference. And it's a good thing F#'s designers chose the latter option; it's a huge win on the interoperability front. Libraries have a tendency to be write-once-use-often, so exporting object-oriented APIs from F# code is way better than consuming functional APIs from C# code.
- frowaway001 13y ago
  I think there is a huge way between allowing developers consume F# code from C# and importing all the ugliness of stuff like static members into the language. I don't think it has to be that way. What's the value of having a runtime with a language-independent intermediate representation if one just adds half of C#'s complexity into F#?
  - bunderbunder 13y ago
    Q: What's the difference between a static method and a function that belongs to a module? A: One's object-oriented jargon, the other's functional jargon. They both mean pretty much the same thing.
    - frowaway001 13y ago
      So why have both in the language?

noblethrasher 13y ago

Well, if the language was only meant to be an API consumer then eliding OO stuff would make more sense, but they designed it for bi-directional interop. And besides, F# was based on OCaml (as I'm sure you know), which itself was an existence proof that you could successfully bolt OO onto a functional language.

frowaway001 13y ago
> successfully bolt OO onto a functional language Yes, I think that's a good description. It's not great, but it somehow works (although the whole F# community tends to tell people to stay away from OOP when not necessary). Would have been interesting to explore better ways to support OOP so that it doesn't need to be considered a second class citizen, but I guess it's too late for that now.

bunderbunder 13y ago

There's an enormous difference. And it's a good thing F#'s designers chose the latter option; it's a huge win on the interoperability front. Libraries have a tendency to be write-once-use-often, so exporting object-oriented APIs from F# code is way better than consuming functional APIs from C# code.

frowaway001 13y ago
I think there is a huge way between allowing developers consume F# code from C# and importing all the ugliness of stuff like static members into the language. I don't think it has to be that way. What's the value of having a runtime with a language-independent intermediate representation if one just adds half of C#'s complexity into F#?
- bunderbunder 13y ago
  Q: What's the difference between a static method and a function that belongs to a module? A: One's object-oriented jargon, the other's functional jargon. They both mean pretty much the same thing.
  - frowaway001 13y ago
    So why have both in the language?