The thesis of this article is that strategically admitting elements of OO in an F# codebase significantly improves quality and maintainability....In my 6 years

The thesis of this article is that strategically admitting elements of OO in an F# codebase significantly improves quality and maintainability....In my 6 years of working with F#...I typically write the implementation of a large component in the functional style behind a private module, then expose its public API as part of a standalone class. I've been coding with F# since it came out. I don't claim to be a guru, but I've coded in various production environments, both self-architected and part of a larger group. I write pure functional first and then refactor and abstract as necessary. I have also decided on a policy of pure microservices: stand-alone small units of functionality joined, tested, and deployed by the environment, not other toolsets. I try to keep a completely open mind about rolling my own objects. I'm an old OO guy, I love all things OO. Sadly, keeping to these simple principles, I find no need for objects. At first I did. Then I got better. I keep looking for them to crop up. Instead, what happens is that I write my microservice production code in the domain language, with lots of descriptive parameters and methods. Then, as a I refactor, the code splits into "neat stuff that should be part of the type system" and "some construct that's actually solving the problem I want to solve" So I end up with a very small amount of domain-expressive code written using symbols that are either in the type system or should be. I'm done. That's it. Repeat and rinse -- keeping, of course, that small bit of code that actually got refactored out for re-use. This code will live in a Types.fs file. I share this file among projects. I could be more blunt. There are no components. Once you start thinking in terms of components? You've already decided you want to use OO. There's nothing wrong with that, just don't engage in circular reasoning. If before you begin you've already decided to use OO concepts, then you're using OO concepts. F# has nothing to do with anything. I'm still waiting for some good examples, and I'm trying to stay open-minded about it. So far, though, I haven't seen the need for them. This essay didn't change anything.