Is anyone actually using F# in a production environment?
If so, what are you using it for and why did you decided to use F#?
Do you recommend a die-hard C# developer to learn F# or do you think it's just a fad?
Is anyone actually using F# in a production environment?
If so, what are you using it for and why did you decided to use F#?
Do you recommend a die-hard C# developer to learn F# or do you think it's just a fad?
Although not in "development", I'm planning on using it to help learn (and put fun into) physics when I go back to university after my internship. From my understanding, functional languages, like F#, are good for many scientific computing applications.
I don't think it's a fad. I think many paradigms have their place. I don't see OO dying out, but I think it will be complimented by functional programming, aspect-oriented programming, and procedural programming more often. I think that it is important to not only learn a new language, but also a new paradigm. Although I haven't learned AOP yet...I should kind of get on that.
I'd recommend F# to a die hard C# developer just because learning another language is one way a programmer can get out of a local maxima and become a better programmer. And F# isn't just a different set of semantics on top of the same syntax as most imperative languages are, it's a totally different programming style. All the more to expand the capabilities and understanding of a programmer.
You can find anecdotal evidence of F# in production on the web; e.g.
http://cs.hubfs.net/forums/thread/7066.aspx
Credit Suisse is seeking to recruit an expert in functional programming... we have recently adopted F# for implementing and deploying models on the .NET platform....
and
http://flyingfrogblog.blogspot.com/2010/02/sizes-of-industrial-ocaml-and-f-code.html
Probably the most public uses of F# has been for the Halo TrueSkill algorithm. Other than that, functional programming languages (including F#) are being used in a lot of financial institutions.
F# has a complete (almost?) superset of C# functionality, so you'll lose nothing (apart from some of the designer support). F# works with OO; it does not necesarily force you to use a functional approach to everything. Indeed, F# encourages you to use imperative/OO style when convenient.
So, at worst, F# for a die-hard C# programmer is just going to mean lighter syntax. But more probably, you'll end up with simpler, easier solutions. You can apply some of the techniques to C# too, if you decide not to use F#. And best, you'll probably have fun.
FWIW, I have a few projects in the works that will deploy with F# in production. The main driving reason is that it lets us write less code, and the code is easier to verify to be correct. Some specific features:
Type inference and automatic generalization. Letting the compiler do work cuts down on a lot of noise code. Whereas C# makes you specify everything except locals, F# infers. More than just "var someThing = new SomeThing()", F# really shines when you have lots of generics and constraints. [Some of our field declarations in C# top 300 characters, mostly related to necessary annotation (and re-annotation) of generics.]
First class functional support. Doing things in a lightweight functional way is easier in F# than in C#. C# 3.0 does a decent job, but lack of type inference/auto generalization cut down on its usefulness.
Nested declarations. This simple feature cuts some of the design overhead away, because it allows us to use a hierarchical structure inside functions, instead of just classes.
Pattern matching, discriminated unions, tuples. While simple to comprehend and attempt in C#, built-in language support allows these features to provide elegant compiler-checked code. In one recent case, we had about 50-60 lines of C# to represent something we can do in about 8 lines of F#. [And the C# version wasn't comparable, since the compiler couldn't check the code exactly.]
Computation expressions. The Seq and Async computations are extremely powerful. F# really blows C# away here, particularly in async. We can pretty much write code just like we would in C#, but then let the workflow builder do it's thing and presto, it's multithreaded. We've even created our own builder to deal with a specific problem and this made things much more natural to write.
Almost everything I've written in C# for the past while has kept me thinking "this would be so much easier in F#". Finally, I don't think C# is going to catch up. F#'s power gap is too large, and C#'s audience is too broad.
Yes. We have created products called F# for Visualization and F# for Numerics that turn F# into a high-performance interactive technical computing environment ideal for scientists and engineers. The largest-scale projects to have used F# are Microsoft's own third-party driver verifier (ported from OCaml), the TrueSkill part of Halo 3 and part of Live AdCenter.
We use F# to develop software for interactive technical computing, aimed at scientists and engineers. F# is excellent for this because it combines the benefits of the .NET platform with brevity and interactivity.
I don't think F# is a fad but I do think F# will draw new users to the .NET platform rather than steal market share from existing C# applications. I would recommend that a C# programmer learn as much as possible, not just F#, but I expect F# knowledge will become extremely valuable over the next 3 years.
Cheers, Jon Harrop.
I used F# when it was first publicly available to crunch some numbers for a mobile web application. I think the application was determining how many vistors visited the site, what device they were using and what page where they directed to. I connected to the MSSql db, ran the sprocs which did some of the heavy lifting by giving me a subset of data, used a web service to get the location for the ip, and outputted the data to a csv file. Data was broken down by day, and I threaded the sproc calls and day calculations. All this in about 50 lines, and it ran pretty well. Bare bones, because I was still learning, but met the current need. For those that are wondering, the company did not have the resources to afford a reporting solution, so that is one of the reasons I spent a couple days writing this.
I used F# for some fairly intensive web log analysis, and found it a delight. Super clean, highly factorable code, easy to write, easy to change, and very, very quick.
It also works incredibly well for generating graphics on the fly - for dynamic charts, etc.
In none-work work I started porting the Python code from "Programming Collective Intelligence" to F# - to improve my understanding of both. I know that I'm mostly writing pretty literal translations into imperative code for my first pass at this, but even there it's at least as concise and expressive as Python, which is a pretty terse, pretty functionally aware language in itself. a very thin google code project is here
Personally I've found the learning curve to be pretty high, but for the sort of data analysis and representation I do it's an incredibly good fit. And fun!
Hi, this is not directly answer to your question, but it could give you some points why F# is worth learning. I just posted an article that shows some interesting functional ideas in both C# and F# and also explains why functional programming is interesting:
T.