> Is F# a good alternative to C# for writing purely object-oriented code?

Yes! F# is perfectly suitable for OO code, and supports all the same features that C# and VB do, plus Object Expressions, which are a really cool way to implement an interface in an ad-hoc way.

You can learn more here: https://fsharpforfunandprofit.com/series/object-oriented-pro...

Lots of folks in the F# community would encourage you to adopt a functional pattern (as I would as well), but since so much mindshare in the world is currently surrounding object orientation, I think it's great to use F# for OO code and slowly start to sneak in functional patterns. F# is a very "clean" language in that regard.

> One more question. I work at a place with a very restrictive firewall. F# 3 projects worked fine, but with F# 4 the build fails to download nuget packages. Is there a way to use the latest version without Internet connection? I can download anything from microsoft.com, as that site is whitelisted, but nuget.org is not.

Hmmmm. You should be able to build F# 4.1 projects in VS 2017 without an internet connection, but it currently does take a dependency on System.ValueTuple to support struct tuples. This is a point-in-time problem that C# shares as well, because System.ValueTuple is not in the .NET Framework yet. It will be in a future .NET Framework release. This shouldn't limit you, though - you can still do anything in-box, just without using struct tuples.

Naturally, anything involving NuGet packages will be off-limits in your case. So that does cut you off from some of the awesome community packages out there. Have you considered hosting an internal NuGet feed with a package cache so that you're not limited in this way? A lot of companies do this.

>supports all the same features that C# and VB do

My understanding is that while F# indeed supports almost all OOP paradigms nevertheless partial classes are not supported in F#. Do I miss something?

No you're right, partial classes are not supported.

> For my current project I have a very low level spec/architecture, that says class Abc does Xyz, classes A1, A2, A3 implement a strategy pattern, etc. It's designed with C#, VB.NET or Java in mind, but the dev team would prefer F# or Scala.

This sounds like a horrible environment to work in. If you don't trust your developers to make those kind of decisions for themselves then what are you even paying them for? That gives them no ability to exercise their skills and I would not expect any good developer to stay long in such a place.

Frankly it suggests a level of brokenness in your process that I've always found unfixable. I'd advise finding a better job.

I haven't used F# in a while, but it seemed pretty clean for OOP with a couple of caveats. You have to explicitly implement interfaces and do a lot of casts to use interface members, which is ugly compared to the rest of F#. It's also difficult (impossible?) to have circular references between types unless you cram it all into one file.

It's probably possible to convince me that the limitation on circular references is actually a feature, but implicit interfaces would be really nice to have.

If I ever dive back into to F#, I think I will treat it as "procedural first with a neat type system" and limit the use of both OO and functional features to where they markedly improve the code.

> If I ever dive back into to F#, I think I will treat it as "procedural first with a neat type system" and limit the use of both OO and functional features to where they markedly improve the code.

This may be a good strategy; I would urge you though to try doing top-down design in F# using modules and interface (.fsi) files. E.g., let's design a calculator GUI app in F# using, say, Windows Forms. Sketch out the interface first:

    (* Calculator.fsi *)
    namespace CalculatorApp

    module Calculator =
      type number = Zero | One | Two | ... | Nine
      type op = Plus | Minus | ... | Sqrt

      (*
      Holds the app model. Note that it is mutable; the keypress operations
      return `unit`, i.e. they update the `t` value in place.
      *)
      type t

      val init : t
      val press_number : t -> number -> unit
      val press_op : t -> op -> unit
      val calculate : t -> double

      (*
      Draws the app and hooks up event handlers to the above operations.
      *)
      val render : unit -> System.Windows.Forms.Control

Then in the implementation file (Calculator.fs), fill in the blanks based on the types! Of course you'll need a separate file for the main entry point, but that's good practice anyway.

> It's probably possible to convince me that the limitation on circular references is actually a feature

Have that in Haskell as well. As the community largely views FP as "type-driven development" and Haskell as a "typeful language", it isn't uncommon to have a single module just for listing all the Algebraic Data Types (not their "methods" though, that's more an OOP concept anyway). Having all ADTs at a glance has its own benefits in terms of "high-level overview" etc too of course.

But of course the question was about OOP so you're right calling this a "caveat" in that respect.

I'm for writing idiomatic code and F# is a functional first language.

You can write object oriented code, but functional code looks so much better.

By the way, the strategy patter translates very well to functional programming. Just pass a function with the behaviour you want!

you can write an equivalent F# class as any C# class, however, with a spec like that, sounds like it would better off as C#

IIRC from the Wikibook, multiple inheritance isn't supported. (Wasn't in C# back-in-my-day either though ;)

It's not supported by the underlying .NET object model, so no .NET language can handle it without reinventing the wheel in a way that's incompatible with the rest of them. Since cross-language interop is one of the bigger benefits of OO in .NET, no-one really bothers.

It isn't, F# supports OOP but does not advocate for it. Most class hierarchies would likely work better as discriminated unions in F#.