For those of you out there who are using f#, what areas of functionality are you coding with it? What is the language really well suited to and what does it do with far more power and ease than say c#?
Deep Fried Bytes #24 podcast covered this:
- Algorithmic processing (including calculations)
- DSL creation
- Concurrent processing (immutable data, message queuing, asynchronous workflows)
And of course, for many systems F# may form a processing core, but it seems to me that it will more often than not be wrapped (interface, user or otherwise) with C#/VB to provide a conventional interface.
- Scientific works (Mathematical and statistical calculations, visualization, optimization,..)
- Parallel programming (F# supports asynchronous workflows, Erlang style concurrency, Parallel FX, ...)
- Language oriented programming (eg. DSLs)
- Data intensive analysis
- ...
I think advantages are mostly in development than actual generated code. It's pretty much the same as C# in the output but development is terse, free of syntactic sugar. That allows you to prototype your code much easier than C#. I like creating a function or a value binding just with a "let" single liner. You can rapidly create function pieces, merge them, pipe them together like lego bricks.
F# is very fluent in dealing with any kind of list (arrays, lists, sets, linked lists, sequences etc). I think algorithms dealing with these would be much easier to implement in F#.
On the other hand OOP and imperative syntax can be painful. Although that forces you to embrace functional programming style, it prevents you from using it as an all-purpose language.
I also don't fancy lambda expression syntax which F# inherited from OCaml. I think C# has done a better job with it.
I experimented on a simple genetic algorithm code and impressed on how terse the code can be while maintaining readability thanks to #light syntax. Here is my post on hubFS.
I currently explore the uses of F# in
- SOA
- Parallel execution
- Data Intensive
- Long running processes
I'm currently using F# to develop my next indie video game. So far I'm finding that my normal OO approach is different from how I develop in c#.
Some good things I've noticed is that I'm using smaller functions on average ie the number of lines per function is way down. It's also more natural now for me to scope a static private member function to be inside of another member instead of having it be exposed to everything in the object. Writing a collision algorithm was really easy. It's a bit early for me to say that writing algorithms in F# is easier but I'm already leaning that way.
Not everything has been roses since I started using F#. I'm still finding online documentation lacking. Expert F# has been of some help but since it skims over OO it leaves me lost a lot of times. It gets on my nerves that the author chose not to go very deep into OO when it's currently the most popular form of development. I'm not looking to dump OO. I'm looking to integrate functional into it.
The biggest advantage I've seen so far has been my codes correctness. I know it sounds funny but every time I've gotten my code to compile, it has worked as expected. I hope this is still the case when I break the ten thousand lines of code mark.
I'm considering using F# for HTML processing because the list pattern-matching syntax fits the problem domain well (Prolog is probably better, but still).
1) Simulations (Ants and Mycelium)
It's easy to leverage async workflows to make for massively parallel simulations.
2) Unit Tests for C# API
F# makes for short, sweet and very readable tests. Also, FsStory is quite nice.
3) Data Analysis and Visualization
It has great visualization libraries and it's very fast to try different things out. I also love VSLab and hope it sees another release soon.
4) Rapid XNA Development
Once you have a small framework set up to keep the object-orientedness of XNA at bay, F# development is much faster and also much easier to experiment with.
In short, I find F# to be fantastic anywhere development speed or immutability trumps API correctness. If there was a pragma or compiler flag to turn off type inference for public functions and type definitions, I'd probably be pushing to use it for my APIs as well.
F# does pretty much everything C#, only easier. It's advanced features mean you end up writing a lot less code. OO syntax is more verbose than the other F# syntax, but it's still better than using C#.
We're using it for web services, ASP.NET MVC sites, daemons,
The question is, where not to use it. Right now that looks to be mainly where tool support is lacking. So, for example, with ASP.NET, the ASPX page inline code is C#, but the controllers and everything else is in F#.
The few places where F# isn't as smooth as it should be I imagine will be worked out in the upcoming releases.
Here are some good practical uses of F# and Functional programming from Trauma Pony given as an answer to my similar question.
- Computational fluid dynamics
- Physics processing
- Ray tracing
- Data mining
- Medical imaging
- Control engineering software
- Digital signal processing
- Bioinformatics
In fact, check out this page for a lot more examples of where GPGPU has been used.
Small(ish) data processing scripts. Think parsing long log files and trying to detect "strange" behavior. Active patterns and stream processing make for nice (and fast) programs. I used to write these in C# but they were throw-away - using F# I actually find myself reusing previous scripts and extending them.
Testing using FsCheck (well ok, I guess that's cheating as I ported the thing myself...), but it's been amazingly useful (I was actually surprised at this myself ;) ) not only for testing F# programs, but .NET libraries in general. Since FsCheck is a testing DSL, I guess I should join the DSL bandwagon as well.
I've been wanting to use F# with WPF or XNA for ages now, but haven't gotten round to it.
Contrary to some I've found that once you get the hang of F#'s implicit class construction syntax, OO programming using F# is just as enjoyable, if not more than using C# or VB.
It is true that if you write a library in F#, unless you're very careful it ends up being interoperable only in theory. Truly interoperable F# libraries either need to be very careful what F# constructs to use, or write a C#/VB wrapper.
Kurt
I'm using F# to develop an engine for a turn-based strategy game I'm playing with designing. I've found that F#'s mix of functional and OO programing has let me manipulate the data in the game concisely in ways that would be too complicated in an imperative C# to want to do. It's also pretty natural to separate the state-changing actions from the folds and such that determine how the state should change, which definitely helps keep the code simpler and organized.
The biggest trap I may be falling into in the project is using type annotations of tuples for a couple of data types that are used quite intensively in one of the classes. Using tuples makes for pretty concise code, but I'm not sure that using the type annotation in the signature of the functions that use them is sufficient to maintain readable code in some cases.
I am using F# for receiving(TCP), parsing and storing binary protocol messages from industrial devices. Currently, I'm testing async workflows.
Next project is visualization and analysis of received data.