C# vs F# for programmatic WPF GUIs

Question

I'm trying to decide where to draw the line on the use of F# and C# in enterprise software development. F# for mathematical code is a no-brainer. I like F# for GUI work even though it lacks GUI designer support but, of course, there is more resource availability of C# GUI people in industry. However, I am not too familiar with C#+XAML GUI development so I'm concerned about introducing bias.

In the case of one client, they have dozens of similar GUIs that are quite static (changed yearly) and a few other GUIs that are very dynamic (e.g. business rules engines). They already have F# code live and are already investing in F# training so skills availability isn't an issue. My impression is that C#+XAML let you build static GUIs (a few sliders, a few text boxes etc.) easily but I cannot see how the GUI designer would help with programmatic GUIs like a business rules engine. Am I right in thinking that maintaining a battery of mostly-static GUIs (e.g. adding a new field to 100 separate GUIs) will require manual labor? Also, am I right in thinking that the GUI designer is of little use in the context of heavily programmatic GUIs so something like a business rules engine would be written primarily in C#+XAML with little use of the GUI designer?

Answer 1

I've done a good amount of GUI and non-GUI programming in C# and F#, in work and play, heavy programmatic and static... and I believe your stated impression is accurate and practical. (note that I am more familiar with WinForms than with WPF, but I don't think the differences matter here).

My impression is that C#+XAML let you build static GUIs (a few sliders, a few text boxes etc.) easily but I cannot see how the GUI designer would help with programmatic GUIs like a business rules engine.

This is absolutely my experience. For mostly static GUIs, I prefer using the WinForms designer with C#. The tooling combo is great for these scenarios and is more productive than hand-coding the GUI with F# and no designer (now, if there were F# support with the designer, I would have no hesitation preferring that). I'm Only Resting is an example where I have preferred C# with the WinForms designer over pure F#.

And for heavy programmatic GUIs, I believe it is best to avoid the designer altogether, rather than to attempt to go half designer half programmatic (it gets real messy, real quick). So in these cases I definitely prefer hand-coding the GUIs in F#, since everyone knows F# is the more expressive language ;) FsEye is an example where I have preferred pure F# over C# with the WinForms designer.

Am I right in thinking that maintaining a battery of mostly-static GUIs (e.g. adding a new field to 100 separate GUIs) will require manual labor?

Probably. I don't believe there is really any ready solution for this problem since it is really quite a large one. But there might be some best practices out there for building a custom solution right for your suite of software.

Also, am I right in thinking that the GUI designer is of little use in the context of heavily programmatic GUIs so something like a business rules engine would be written primarily in C#+XAML with little use of the GUI designer?

Yes, like I said early, it is my belief that you ought not try to mix the GUI designer with heavy programmatic GUI programming.