F# is gaining independence from .NET

I also value F# for reasons that have very little to do with functional programming. I like the sum types, I like the generics, I like the syntax, but when I make things with it I do not get very functional, in fact I find the more aggressively functional approaches to be extremely confusing to reason about. Where functions take in partially applied functions and so on, it is very hard to read. Maybe thats fundamentally true, maybe it is just me, I don't know.

There is pretty broad agreement that pure functions and immutable variables are good to strive for. And since F# doesn't force you to do that even when it is a bad idea, things are quite nice. When mutating state is the simpler thing to do, you can do it.

Where things can get weird is when you start passing partially applied functions to other functions, and then you use type inference on function signatures on top of that. Glancing at the function signature its completely opaque what is going on. Hopefully you aren't in github and have working code lens and then you get a type signature to help, but it gets very verbose and confusing, and is still hard to reason about, for me anyway.

A thing I find helpful with F#, no matter what style you use, is always type out the types in function signatures. Yes this has downsides occasionally when a refactor might have just worked without adjusting types through a chain of functions, but I think it is a net win for productivity.

Okay. I don't want to go too far off topic here but the OP is about F# so I'm certain many enthusiasts will be here, and I have been waiting for this moment to get an answer to a very specific question regarding Elmish:

What is the point of the Elm architecture?

I cannot figure out why the `model`, `view`, `update` architecture is preferable to its OOP counterpart. That is, simply defining an interface for each of the above where `IView` and `IUpdate` each contain a single method with the appropriate parameters. That is objectively[0] cleaner!

The current recommendation is to create these ungodly unions for handling the view/update logic. It feels ridiculous and really starts to gum up your modules with implementation logic that is _entirely_ unrelated.

FP and OOP each provide different (opposite) faculties when dealing with the expression problem. FP says[1], "I want to optimize for adding new _behavior_ to the same pieces of data" (one can add functions that operate on the same data without needing to recompile). OOP says[2], "I want to optimize for adding new _data_ with the same kinds of behavior" (one can add classes encapsulating different data that have the same operations without needing to recompile). How does the above square with an architecture built around a set of _single_ functions that operate on different (changing) pieces of data?

The Elm architecture seems to have chosen the exact wrong paradigm (and its associated semantics) for optimizing change! You aren't adding behavior as you build out your application in this architecture. You are adding _data_! The "behavior" is defined exactly one time (in the signatures of the `view` and `update` functions) and doesn't change. I must be missing something... is this really just so we can say "the complier will let us know if we forgot to handle a case"? That seems like a pretty hefty trade-off if you ask me. F# has this beautiful multi-paradigm capability and, in this case, it's been woefully ignored.

[0] Okay fine maybe not objectively, but it certainly seems preferable to modularize this logic.

[1][2] I get it. They don't actually say anything, but the general approach to the EP remains true for most cases.

I understand what you are saying. I'm not sure how your points are at odds with the OOP counterpart I describe though. The essence of your response seems to be "because we want to use a pure FP paradigm" to which _I_ would add "despite a clear downside to which F# has the capacity to avoid".

If the framework only expects every `Model` to contain 2 methods (`view`, `update`) and never any more (which is the case), I see no reason at all to adopt the Elm architecture. The interface for `update/view/model` is well-defined and un-changing. It's clearly sitting on the wrong side of the expression problem.

The program loop could work exactly the same no? Just re-organize:

    let (model',cmd') = program.update msg state

to:

    let (model', cmd') = state.update msg // I'm not sure where/how program fits in

My question is truly as simple as trying to figure out the advantage of the chosen semantics (in F# - I don't know Elm). It can't possibly just be "because we want to stay on the Functional programming realm" can it? Immutability can be achieved in any paradigm. Forgive me if I am coming off overly controversial - I don't mean to be.

https://guide.elm-lang.org/webapps/structure.html - Even here in the "MVC" section the documentation _recommends_ you organize your project according to type (containing the `view` and `update` functions). This is very-much akin to my critique. If you reach the point in your project above you have essentially regressed back to OOP (in FP clothes).