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?

Answer 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#.

Answer 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.