In what areas does F# make "absolute no sense in using"? [closed]
Don Syme in his SPLASH talk says that F# is NOT intended to be a replacement for C# even though it has the general capabilities. He goes on to say that there are areas where F# makes no sense in using, but doesn't expand on the thesis.
- Can somebody please tell me what areas should be avoided while using F# ?
- You could also mention areas where C# shine.
Related question:
In what areas might the use of F# be more appropriate than C#?
Solution 1:
My take is that replacing a language as rich and mature as C# would be very expensive. So, for example, at the moment, C# is absolutely the best choice for WinForms development if using the Visual Studio WinForms designer can give you an advantage: F# has no WinForms designer.
C# also has better LINQ-to-SQL support at the moment. I'm sure there are many other examples along these lines.
Then there is requiring the entire C# skilled workforce to update their skills to F#, while preserving C# skills for maintaining applications, again expensive.
Finally, C# is an excellent language with a lot of great features, some F# doesn't even have like co/contra variant generics and out of the box support for dynamic programming against the DLR (F# just has an unimplemented operator).
So by not expecting F# to replace C#, F# can evolve in new ways instead of spending all it's time playing catch-up in areas already well-covered.
Solution 2:
This is a tricky question, because it isn't very well qualified. Are you talking about the language in general, or are you talking about the language together with current IDE support? Or are you talking about using F# given the libraries available?
Language in general - I don't think there are areas where using F# would be an absolute nonsense. It would be great for systems programming of fully managed OS (e.g. Singularity) and I think that functional programs would be easier to verify formally (which could be a big deal for OS). For low-level embedded systems, you could use meta-programming and langauge-oriented facilities (e.g. to model signal flow in hardware etc.)
Language with current IDE - The current F# IDE has some limitations - it doesn't work with WinForms designer (but it works well with Blend and WPF).
Language given developer education - It is more difficult to hire F# programmers than to hire C# programmers. If you're creating some application that doesn't have any complicated core (e.g usual "interface for a database") then developing it in C# will be cheaper (If you could hire good F# developers they would likely finish it faster and with less bugs, but it may not be worth the cost).
Language given libraries available - If you want to restrict yourself to using F# with just libraries that work well with it then the domain shrink a bit more. For example, LINQ to SQL and ASP.NET MVC can be used with F#, but it isn't perfect. However, for many projects it would make sense to develop your own libraries and then F# becomes great language for that.