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

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, strict开发者_如何学JAVAly 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?

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

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.

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.

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.

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

Languages are just a tool. Like Luke, I'm a big fan of using the right tool for the job. If a particular app would benefit from using both C# and F#, then mixing seems reasonable to me.

As for how to do it, see:

Can you mix .net languages within a single project?

Bottom line: you can merge two DLLs that use different languages into a single DLL as a post-build step. Or, you can use multiple languages in a web site that's compiled on the server-side.

Have not tried it yet, but one place where I sure would like to use functional language, even though this might not be a reason to use it, is so that I can avoid what has been describe here

http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html

I would like to just name this as a verb, and execute it

calculateSomething() instead of SomtingCalculator.Execute()

Yes, in future I think that we must combine these kinds of languages like OOP (C#) with Functional language (F#) to take advantage of multicore processing. C# 4 has classes to support this but some things are done better in F#.