[daxfohl]

I'd like to see more of a focus on extension methods rather than the pipe operator in tutorials and such, and tupled args rather than curried args. Also make the OO aspects more visible. It's not so much a language thing as a presentation thing. I think these are the things that confuse mainstream developers, and it's silly to present them all up front when teaching the language. Intellisense and C# compatibility works way better if you go this route too.

[willtim]

If you want "OO aspects", you can use C#. F# should focus on being a functional language. Features like currying exist for a reason.

[MichaelGG]

F# is multi paradigm though. It's just that, especially when looking locally at code, functional style is just way better.

[willtim]

C# is also multi-paradigm, or certainly well on its way, as it gets more and more functional features. F# needs to be functional-first.

[daxfohl]

In four years full-time F# use, I still find standard LOB apps work better with an OO SOA structure at the high level. I've tried various methods of designing FP-style architectures for those apps but nothing has ever ended up nice and clean as a standard interface-based SOA (in F#) and a standard OO DI utility. At the low-level, F# is awesome for immutable records, ADTs, combinators, etc., in a way that C# would be hard to replicate just because the syntax would be so foreign.

So I think there's an opportunity for the F# market to explode as C# devs start to realize the utility of such things at the bottom level (and also for making interesting combinator-based libraries like suave). But in order to get there, I think the stepping stone has to be a change of emphasis in the F# world, to show off F# as a "better C#", starting with standard SOA-style OO-style frameworks, emphasizing a similar style (tupled explicitly-typed fn params, ext methods rather than pipe, C# naming conventions), and then just bumping the lower-level implementations of things and the domain model to ML style.

Going head-first functional-first I think leaves F# useful to just a handful of developers, where everyone else just wants their objects and DI frameworks back.

[willtim]

What exactly do you mean by "OO SOA structure at the high level"? Do you mean essentially a function from a document to a result? If so, then what exactly is object-oriented about it? I'm no expert on industry lingo, but "Service Oriented Architecture" sounds to me much more functional than object-oriented.

That you feel the need for DI frameworks is a great shame and more F#'s failing than functional programming per se. If F# had inherited the module system from OCaml, then there would be much less need to use objects. In OCaml, DI comes for free with module functors, no framework necessary. As it stands, I agree that you are somewhat forced to use objects as a module system, as F# has no other. That is what MS should fix.

[daxfohl]

I mean `class Database implements IPersist`, `class Redis implements ICache`, `class MyLogger implements ILogger`, etc.

So classes/interfaces to each service your app uses. I just use very basic autofac, declaring which implementations to use in code. (Really nothing I couldn't wire up by hand; autofac is just a tad less cumbersome).

I've heard about OCaml's module system and am intrigued by it but never used it.