How will F# (sharp) be used?

Question

I'm having trouble placing the concepts and possiblities of the to be introduced F# language from Microsoft.

Will F# be used just for declaring functions? Or will applications be written 'entirely' in F# by mixing F# together with normal C# or VB code?

Answer 1

I've used it for half a year and I think it will become a general use language. It's fairly complex to learn so doubt it will be used too much in a mixed environment. Managers want to keep costs to a minimum.

• Refactoring speed for me is F# biggest selling point. Having built a simple video game with it, i've fallen in love with the languages constructs. At first the idea of dealing with a state engine seemed out of place in a functional language however with records, tuples and type inference it makes for very fast changes.

• F# has good readability. Once your familiar with F#, if you allow for a mix of multi-paradigm programming styles, code becomes very terse and easy to read however like all languages someone who doesn't know what they are doing can turn it into a nightmare.

My day job involves web prototyping, so I'm looking forward to see where FSharp.WebTools goes and to seeing more support for F# with Microsoft MVC.

Answer 2

Will F# be used just for declaring functions? Or will applications be written 'entirely' in F# by mixing F# together with normal C# or VB code?

We've been writing entire applications in F# for over 3 years. A lot of companies are augmenting their existing code bases with F#.

The easiest entry points for F# are things like shipping F# samples demonstrating how the API of the library you're selling can be used from F#. That is a no-brainer for any company because the samples are not mission critical so technical expertise and on-going maintenance are not an issue. F# is also a great tool for writing test harnesses for existing code in any .NET language. Again, the customer never gets that code so its reliability outside your company is not a concern. In practice, we've had no problems going gung-ho and using F# everywhere and shipping it to customers without them even knowing. That works particularly well for small companies because the massive productivity improvements give us a huge competitive advantage.

Answer 3

Your question implies that all code eventually becomes an application.

This is not necessarily the case though, and one of the strengths of F# (compared to C#, say), is that you can 'break out' your favourite IDE and just run bits of code, without all the Solution/Project/class infrastructure.

For number crunching test results, transforming data, testing out a new algorithm (even if I end up coding it in C# in the 'application'), sorting through log files, even creating a little utility to tell me how many of my C# references are actually being used in a given assembly, F# is nifty, quick, and yet rapidly 'scaleable' up to a dll if I decide to use it further.

Answer 4

I can highly recommend you to watch Luca Bolognese's talk from PDC 2008. It's not only very entertaining but he also demonstrates quite impressive use cases of F#:

An Introduction to Microsoft F# by Luca Bolognese

Answer 5

Depending on the context, you might consider both.

You can use F# to build complete .NET applications or hook it up to other .NET languages. It can consume and expose libraries from/to other .NET languages.

Answer 6

My expectation is that F# will be used for pieces of some specialized systems - the bits that involve complex threading / maths / financial / modelling / etc, where F# does well. For most other areas (UI, DAL, etc), a general purpose language like C# seems (IMO) preferable.

One of the advantages of the F# is that (in theory) you can prove code is working, rather than just test it. The threading support (thanks to immutability and the async ! usage) is also good (although PLINQ may compete on threading).

Hooking into .NET to allow proper integration between F#, C#, VB, IronPython, IronRuby, etc - really shows the strengths of each. Today if I was doing lots of COM interop, I'd consider VB (that'll change in 4.0 with dynamic); for most code - C#. For math etc, F#. Tidy.