What is F# lacking for OO or imperative?
c#, f#, language-design, oop, user-interface
Solution
With regards to OO stuff, my list might be
- You mentioned some things about interfaces and virtuals that can be annoyances or hindrances; lack of auto-props you mentioned is also a shame
- OO frameworks sometimes require many mutually recursive classes, which F# currently forces you to put in one file (in a 'type ... and ... and ...' block)
- If you need to call two different base constructors in a derived class, you have to use the 'explicit' class syntax (as mentioned here)
That said, F# has strengths in the OO department too, like type inference, local functions, succinct syntax, ... so overall I might call it a wash in the 'heavily OO' department.
(I have done almost no UI programming of any kind, so am not qualified to weigh in there.)
(EDIT: I also want to interject that, even though you're explicitly choosing to exclude 'tooling' from the question, I think tooling matters a bit, and in this respect the other managed VS languages excel.)
Problem
Many times I hear that F# is not suited to particular tasks, such as UI. "Use the right tool" is a common phrase. Apart from missing tools such as a WinForms/WPF/ORM designer, I'm not sure what exactly is missing in F# -- honestly! Yet, particularly with UI, I'm told that C# just does it better. So, what are the actual differences and omissions in F# when using it imperatively? Here is a list I came up with: Lots of missing tool support F# is still beta Your developers don't know F# - I'd like to not consider those points, as they aren't really intrinsic to F# Mutables need "mutable" or need to be ref, ref needs ! to dereference Mutables assign with <- and ref uses := ( they're both 1 more character than just = ) val needs DefaultValueAttribute to get a default value F# doesn't emit implicit interfaces Protected members are more difficult to deal with No automatic properties Implemented virtual members on abstract classes require two definitions Quotations-to-LINQ-Expression-Trees produces trees slightly different than C#/VB (annoying for APIs that expect their Expressions in a specific format) No stackalloc F# doesn't have the ?: conditional operator Pointers might be considered more cumbersome in F# Delegates/events might possibly be considered more cumbersome (I'd argue they're easier, but at a minimum they're different) No automatic type conversions (like int to float, or implicit casts) No special syntax support for Nullable (C#'s ? type annotation and ?? operator, as well as using operators on nullables.) No automatic upcasting to common base class or boxing (ex: let x : obj = if true then 1 else "hi" // this won't typecheck) Values can't be discarded without a warning ("ignore" to get around it) Doesn't have C-style syntax :) To the question: Which of these are a hindrance to writing imperative or OO code? Why (short examples)? Which ones did I miss? What are the best workarounds, and why are they not enough? Please note, I'm not talking about writing so-called idiomatic F#, and I'm certainly not talking about functional programming. I'm more interested along the lines of "If I were to force myself to write UI or imperative/OO code in F#, using F# OO/imperative features and class types, what hurts the most?" Bonus If you don't know F# but use C# or VB.NET and think it's a better tool for some situations, please indicate the specific language features and syntax you find appealing.