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?
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
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.
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.
I use F# in the following areas:
DLLs and libraries. Pretty much all the new code I write in my free time is F#, and I only reach for C# when I need a quick GUI.
Multitherading. At work, I've been slowly introducing F#. I got a chance to demonstrate what it can do by moving some ugly single-threaded VB.NET to multithreaded F# using async workflows and mailbox processors.
DSLs and Parsing. At my last company, I used FsLex/FsYacc to parse SQL into an AST. A variation of the prototype code made it into this tutorial.
Scripting. I totally <3 scripting with .fsx files. Their a handy way of writing small scripts without having to write a full-blown executable. Its also nice to modify the sourcecode and run it again with no downtime. I've modified the default behavior of .fsx files to run fsi rather than opening in VS when they're double-clicked.
Certainly, it is feasible to write entire programs in F#. However, I think that most programs will not go this way. F# will most likely be used for the complex algorithms and application logic (the heart of the program), while C# will probably be used for the "outside" (the GUI, etc.). .NET is imperatively structured, so in places where you are using the libraries heavily, C# will probably be more "natural" than F#.
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.
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.
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.
