Patterns to mix F# and C# in the same solution

Question

I studied few functional languages, mostly for academical purposes. Nevertheless, when I have to project a client-server application I always start adopting a Domain Driven Design, strictly OOP.

A complex solution written in a .Net framework could get advantages using more than a language and sometimes more than a paradigm. Mixing C or C++ with LUA or Python is a common practice, sometimes embedding prolog can be very interesting. I never tried to mix OOP and functional paradigm.

F# is a newer functional and object oriented language, I see that's it's technically very easy to mix C# with F# libraries in the same solution. But I wonder if it makes any sense: I use LINQ to satisfy many of my functional requirements.

When and how, do you think it's a good idea to mix these two languages together? I wonder if exists a set of patterns that tries that.

Do you actually use F# in a C# solution?

Solution 1

There are certain places where traditional functional techniques make a lot of sense, and lead to code that is both smaller and more concise. A classic example is text parsing and tree processing, both often appearing together when you're implementing a DSL. F# features like anonymous iterators, extensible pattern matching, and ability to define custom infix operators to serve as combinators really helps a lot here. Meanwhile, on the C# side, LINQ is a good start, but it doesn't take you all the way there.

I suggest you have a look at FParsec, and see for yourself how much better suited it is to advanced text processing / parsing than any library you could possibly write in C#.

Solution 2

I've written a WCF service in F# that acts as a translator plug-in for reading a WFS (geospatial data) service. The code turned out nice and concise.

While the standalone dll I compiled worked fine inside my colleague's C# solution, he did try to strangle me when I showed him the code. Culture shock, I think.

So did we use F# and C# in the same project? Yes and no. No, because I rewrote the thing in C#. Yes, because building and testing the prototype in F# saved me more time than it took me to translate it to C# LINQ-style.

I wouldn't want to try building everything in F#, but I'm patiently waiting for the day I can work on the data processing/algorithmic part of a mixed language solution in F# without fearing for my life.

Solution 3

You got me thinking, and I tried to decide where I would do it. There are two situations that spring to mind:

1. If I am making a castle (MVC) project I would probably have controllers in C# while all the BL and models are in F# (I tend to do domain driven design and wire the BL into the models, or via injected components [ala DI])
2. Starting a new project but incorporating existing libraries so as to not reinvent the wheel.

Further, I'm a big advocate of 'right tool for the job', so if I think one or the other would suit better, I'd use that.

Solution 4

We have an application which gets all of its functionality by loading MEF parts. Most of the parts are written in C#, but there is one part which does binary data processing which is written in F#. In this case F# was simply better suited for the job.

The F# part conforms to an interface defined in C# and the C# application has no idea it's dealing with an F# part (other than the dependency on fsharp.dll).

Of course this doesn't just apply to F#, if someone wants to write or rewrite a part (addon, module, whatever you want to call it) in a different language it will be picked up by MEF and provided to our application without any disadvantages.

We choose the language that is best suited to solve a specific problem and MEF abstracts all the specifics away from us, so we have nothing to worry about.

Solution 5

I use F# for exploratory programming in my C# solutions. E.g. I fire up my C# WPF app through visual studios F# interactive console and poke around in the running application. Can save you a lot of edit-compile-debug sessions..

View more solutions