I was a C# programmer for several years, and I've been writing F# full time now for a little over a year. To briefly answer your points:
- F# doesn't have tool support for _building_ UIs (e.g., Winforms designer), but beyond that, it's very good for the code which actually runs the UI (the eventing and so forth).
- You could build some functions to manipulate fragments from XML, then build some higher-level functions from those, etc., then traverse your data (whatever it is) and use the functions you've built to emit XML in a clean and _precise_ way. I think Haskell already has such a library -- perhaps someone's ported it to F#?
- You can use F# 'async' workflows to retrieve data from web APIs really easily (and quickly, if you are doing it in bulk). In fact, this is probably one of the most common code examples shown for async workflows.
In my experience, F# isn't great at everything, but in general, I'm much, much more productive writing F# than I ever was/am in C#.
>You could build some functions to manipulate fragments from XML, then build some higher-level functions from those, etc., then traverse your data (whatever it is) and use the functions you've built to emit XML in a clean and _precise_ way. I think Haskell already has such a library -- perhaps someone's ported it to F#?
Can you share some experiences with F# in bigger projects? I'm a little bit worried about the accessibility of larger code bases with global type inference. I would say that I have a pretty good grasp of the language in general, but I usually feel lost without IDE support or comments because heavy usage of things like currying and type inference assures that the signature of a function is pretty meaningless.
Currying and type inference do not make function signatures meaningless, unfortunately however, reading their types is a skill that you need to practice for it to become natural.
As for global type inference the one in F# is only partially global (between Scala and ML , Haskell). Anytime you are dealing with ad-hoc polymorphism, even when F# has inferred the types, you will often have to put the type in. Full point free programming also does not always resolve if you are into that.
I have gotten into the habit of putting types and names for complicated functions in comments (///). I also write short descriptions for particularly dense pieces of code and have gotten in the habit of writing clearer, less dense code with full names because otherwise it does take longer to mentally unpack. That is, functional languages make it easy to write stuff like: let wu wp wn nu y x = wp * (exp (nu * y * x)) , wn * (exp (-nu * y * x))
- F# doesn't have tool support for _building_ UIs (e.g., Winforms designer), but beyond that, it's very good for the code which actually runs the UI (the eventing and so forth).
- You could build some functions to manipulate fragments from XML, then build some higher-level functions from those, etc., then traverse your data (whatever it is) and use the functions you've built to emit XML in a clean and _precise_ way. I think Haskell already has such a library -- perhaps someone's ported it to F#?
- You can use F# 'async' workflows to retrieve data from web APIs really easily (and quickly, if you are doing it in bulk). In fact, this is probably one of the most common code examples shown for async workflows.
In my experience, F# isn't great at everything, but in general, I'm much, much more productive writing F# than I ever was/am in C#.