MVU vs OO: Elmish.WPF + LanguageExt (for the C# parts)

[YkTru]

@louthy Thank you for this amazing library, I'm using it on every project. I've also watched your standpoint on OO vs FP in your video https://www.youtube.com/watch?v=xwDhKV7CqAY, and I'm trying to follow here what I think I understand are your recommandations, so please don't hesitate to tell me where I'm not following them actually.

I am using Prism (MVVM) architecture for all my WPF projects, though the complexity and boilerplate is becoming increasingly annoying (too many projects, interfaces, services, model wrappers, extremely repetitive tasks (for module+services creation/registration etc.), no straightforward serialization, VM part being overly complex, etc.)

I spend way more time creating/organising files and folders "to make all of this work together" and navigating than actually coding. So I've decided to shift toward F#'s Elmish (Elmish.WPF more precisely) so I can focus more on what the code is actually doing (and because I feel more comfortable in F#), and i want your advice please:

Context:

• I've tried many UI frameworks for Desktop, and WPF is for my needs the best option so changing it is not an option.
• I'm starting a new huge Desktop App for data annotation (AI style); a lot might change, it must be resilient/flexible/modular ++
• I don't like C# language very much: I find it noisy++, and no proper DU is for me unacceptable
• MVU looks to me like a good paradigm shift from OO and MVVM for a more FP oriented way of composing WPF apps.
• I intend to use LanguageExt for consistent data interactions between C# and F#

Questions:
Q1 - Would you, considering my specific context, recommand that library/approach and if not, which other(s)? What would you use?
Q2 - Do you see any trade-offs (except interop challenges), "dangers", bad practices, potential mid/long term issues using Elmish.WPF/MVU for a complex Desktop app?
Q3 - (sorry I might not be clear enough here) I know using 3rd party OO-oriented C# libraries directly in F# can be a pain (interop through adapters can help though), I was thinking to call those libraries in F# as "services" (in the FP sense) from wrapped C# classes (eg: "MakeC#StuffAdapter" wrapping the MakeC#Stuff class which is doing the actual work). My understanding is that I could keep the purity by exchanging only input/output (data) making them bounded context/IO (Haskell). I intend to use LanguageExt's Result/Option/etc. for smooth/consistent/compatible data flow between F# and C#, isolating "logic bugs" in C# component if any. Does this make sense? What else would you suggest? (for async/sidefx Elmish uses cmd which I guess could help for such scenario)

Thanks alot

[louthy]

I don't use WPF, Elm, or Elmish and I've not really been near F# for a number of years now. So, I'm not sure I'm going to be able to give you the general advice you're looking for.

A few points though:

• Don't use the Result type. The docs cover the reasoning
  • It is very likely that I will deprecate it in v5.0 of language-ext
• In terms of language terseness, it's not that hard to get C# to almost F# levels of terseness - which is kinda the point of this library, to make the functional style in C# much more declarative and easier to 'see'
• Discriminated unions:

You can make DUs with records, and its not too heavy on the syntax. The biggest issue is a effective completeness checking due to the types being 'open'.

public abstract record Maybe<A>;
public record Just<A>(A Value) : Maybe<A>;
public record Nothing<A> : Maybe<A>;

C# isn't as elegant as F# but I moved away from F# due to its relative neglect in Microsoft land. The tooling breaking constantly during the .NET Core migration period was enough for me to drop usage of it for good. Interop is always painful (FSharpOption being null in C# is awful!) and as you pointed out, using C# libs in F# is weird.

[YkTru]

Many thanks for taking time to share your advices.

I made some researches, and apparently F# is now fully stable compared to .Net Core migration period

Wouldnt using this alleviate the "FSharpOption being null" problem?: https://github.com/louthy/language-ext/blob/main/LanguageExt.FSharp/Prelude.cs

It looks great to me on first sight, is there a reason why you would not advise to use it?

Thank you again

[louthy]

I made some researches, and apparently F# is now fully stable compared to .Net Core migration period

Oh for sure, it's better now, but what was clear during that period is how little MS cared about F#. It was an afterthought.

We'd built some semi-substantial projects in F# and it really stopped us in our tracks when our projects just wouldn't build any more. It was a really frustrating time that knocked any good will out of me. I even had members of the F# team joining me on Teams to try and work out why my projects just wouldn't build. So, yeah, I'm scarred by the experience basically.

Wouldnt using this alleviate the "FSharpOption being null" problem?:

Yes, but that's kinda that point. It shouldn't need to exist. You'll see lots of issues with F#/C# interop, like accessing the DUs in C# is really awkward, as well as the interop with FSharpFunc which is horrific.

If (as I think you're saying) you have the chance to start a greenfield project, then perhaps even the language should be up for discussion? Personally, I don't feel F# has enough advantages over C# to make the loss of world-class tooling, world-class compiler, etc. worth it. Now, if you said you were thinking of Haskell, or some other FP language that has an ecosystem built around it, then I'd say "yeah, go for it!"; but F# has some serious compromises because of its big brother: C#. But also because of the lack of ambition for the language: Dom Syme has already stated that advanced features like higher-kinds will never be in F#, so what's its major advantage? DUs?

Obviously I am biased, so you can take this with a pinch of salt, but I'd rather do FP in C# with language-ext than I would work with F#. The tooling is just sooo much better that it's hard to get up to the level of productivity that's possible in C#.

I even found this when working on a Haskell for much of the past year. Haskell is a beautiful language, with the ML style syntax of F#, and a type-system to die for. But damn did I miss my C# debugger, fast compile times, refactoring tooling, etc. etc. etc.

Anyway ... if you're still thinking F#, then I'd recommend going 100% F#. The interop is just too annoying to make it worthwhile doing any part of the project in C#.