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?

Solution 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.

Solution 2

I recently built a directed graph visualization application using purely F# and WPF.

For the 'programmatic' GUI parts, I essentially built WPF custom controls that I could operate with data binding and MVVM.

For the static parts I used XAML with out-of-the-box and custom WPF controls.

I used the FSharpX WPF Type Provider extensively for MVVM binding.

And this 'book' helped me quite a bit to get started. http://wpffsharp.codeplex.com/

Some things don't come naturally with F# and WPF but in almost all cases a reasonably elegant solution was found. Some WPF data binding strings did become large and unwieldy.

Solution 3

I don't know how exactly to answer the question as it's somewhat hard to get hold to so I just give you my 0.05$:

If you do WPF with a good MVVM (there are even Rx-Versions that are influenced by FP-land) you won't write code-behind (or almost none) - and with WPF type-providers and all the other great stuff that's around you can already write WPF-F# applications without any problem (even designer support is no problem - just use BLEND if you can - if not you can still seperate the GUI into a dumb C#-lib.)

so why don't I write most GUIs in 100% F# then?

Well to be honest... it's the lack of refactoring and tools like ReSharper - it's just frustrating that I cannot search for F#-symbols or types because there is no freaking support in VS/R#er right now.

It's strange but writting MVVM code where you have to create much trivial code for your Viewmodels seems to be easier to do in C# with the right tools right now (for example: I can configure R#er to insert me all the code for public probertys with private/public setters and INotifyPropertyChanged based on internal fields by just hitting - and choosing the right option - this will generate lot's of very dumb code but it's much faster that you could do in F#)

Solution 4

As you have pointed out, F# is a much scarcer skill among programmers in the general IT industry, whereas every man and his dog knows C# (or for that matter Java, C/C++ which easily translate across).

Thus from a purely managerial point of view it likely makes more sense to go with C#+XAML over F# because of a number of factors:

1. Programmer's salaries - hiring an F# guru adds quite a bit to the salary budget
2. Development time - this could be argued either way see 1 for a good comparison
3. Corporate risk - usage of F# greatly increases the risk factor in each of the categories:
   • Programmer leaves company and takes intellectual property with them
   • Programmer leaves company and company cannot hire a replacement => project misses deadline
   • Company does not have adequate metrics available to gauge the time required for the project
   • Language becomes depracated and code has to be ported (not as great a concern but still higher-risk than C#)
   • Etc. etc.

However, from an engineering perspective, F# (perhaps with an add-on library for visualisations) is able to simply generate a powerful GUI. C#, though, also has this capability - you can generate your entire GUI without using XAML programmatically.

As for adding a new item to 100+ GUIs, here I don't see how XAML is a disadvantage at all. If I understand your question correctly, you can use a Data Template which you can update once in XAML and have the change propagate across all your GUIs.

In conclusion I would suggest to you that unless you have a strong reason to use F#, stick with C# as it will reduce risk to your company in the long term.

Solution 5

I see alot of confusing answers and solutions here. F# and C# can be combined in solution. Let C# manage GUI and F# manage packages. Also, XAML vs WinForms is a no brainer. With XAML, There is more than enough room for code behind to do any and everything you need. If you're using WinForms then I do believe you need to retire from it immediately. WPF for example, is far more flexible and extremely powerful with GUI options far above those of WinForms. Not to mention the binding power of XAML. XAML is static but communicates with code behind just well and can communicate to any and all .NET languages. Use F#, use C# together and definitely leave the world of WinForms forever. Here is a little project that I've done. It uses only a combinatin of WPF, Silverlight, WCF, F#, C#, and VB.NET. WinForms wasn't touched and if you look closely you'll see that acheiving this with WinForms would have taken ages. I could have completed this with only one language but swapping helped save time depending on the situation but I only went forward, never backwards. WinForms as well as all other legacy options were ignored and never used.

View more solutions

Comments

[SQLMason]

I would even question the op's certainty to use F# over C#. It's not the days of FORTRAN anymore.

[ose]

Fair point. In any case, a decision of such far-reaching consequences would likely be made in the management level of the organisation. It would be hard to mount a case for F# in this case when doing a risk analysis...

[ose]

I think Dan is referring to the currently somewhat limited adoption of functional programming in comparison to imperative (which wasn't necessarily the case in the 1950s-1970s).

[SQLMason]

My point is that people used FORTRAN for mathematical programs a long time ago - a programming language that I myself used to program in. Today, there are math libraries every language. Yes, I know that F# has nothing to do with FORTRAN. @Kit, you know it's FORTRAN and not Fortran, right? ;)

[ose]

Why don't we just all agree to use LISP... ;)

[Random Dev]

anyone of you used F# before? ... it's not like F# is quantum physics or something - it's a easy lang. to get into and it's far more productive than C# - the only things lacking are indeed tooling-support in refactoring and xyz-designer. And BTW I don't think FORTRAN went away...

[Richard Anthony Freeman-Hein]

I am sad to see there is still so much FUD around using functional programming languages, and F# being hybrid even allows a smaller learning curve. :-(

[ose]

Agreed F# does provide a shorter learning curve. However, the OP asked a question about "drawing the line in enterprise software development". My interpretation is that s/he is referring to large-scale software development involving big projects with lots of staff and expensive consequences for failure. In such a situation the manager will make their decision on which language the company will pursue based on risk analysis where factors like tool support, training time and time spent finding suitable staff will rank highest.

[ose]

At the end of the day the assessment will be "do I invest X amount of money in becoming an F#-capable company?" It is not unreasonable to suggest that in a large-scale enterprise project the manager will decide that it is better to sacrifice some potential productivity gains from using a functional programming language (which the majority of the staff are unlikely to be intimately familiar with) than to introduce an unacceptable level of risk to the project (where "unacceptable" depends on that manager's assessment of the financial risk to the company).

[Totti]

That's really interesting. Thanks very much!

[Totti]

Yep, I've heard a lot of people yearn for more refactoring tools for F#. On the other hand, I've heard bilingual devs complain a lot about the amount of repetition required with C#+XAML so presumably there is less need for refactoring tools when there is less to refactor.

[Totti]

That's really interesting. Thanks very much!

[Totti]

@ose "...do I invest X amount of money...". You're making lots of assumptions that aren't true in this case. This client already have F# code live, they already have F# people and are already investing in training more. In fact, this team within the company now have more F# expertise than C#. Also, a "purely managerial point of view" should not impose a technology on the basis of global popularity regardless of its applicability.

[nicolas]

Hi Faisal, is this graph viz open sourced ? That would be a great learning tool as well.

[Totti]

"I'm Only Resting". That's exactly the kind of "static" GUI I thought a designer would be good for.

[Totti]

Yeah, I've been trying to write graph visualization tools for F# for ages but never found the time to finish them.

[Kuba hasn't forgotten Monica]

for heavy programmatic GUIs, I believe it is best to avoid the designer altogether In your cited example of FsEye, all I see by looking at the screenshot (not the code) is a static boring UI with a complex model feeding a tree view. What am I missing? What is so "programmatic" about this GUI?

[Stephen Swensen]

@KubaOber I consider binding the complex model to the tree view to be the complex part: sub-nodes are loaded lazily and in parallel, making heavy use of F# async computations. Node context menus are also created dynamically, on-the-fly. Code is at code.google.com/p/fseye/source/browse/trunk/FsEye/Forms/… . Also see screenshots for plugins: code.google.com/p/fseye/wiki/Plugins, which are loaded dynamically in a right-panel tab container. So yes "boring", but all highly data-driven GUI-creation, which I consider the qualifying "programmatic" part

[Totti]

"Let C# manage GUI". Why would I want to let C# manage the GUI?

[Totti]

"WPF for example, is far more flexible and extremely powerful". I've had many problems with WPF ranging from NGEN recompiling it every time an app starts leading to 30s startup times, to serious performance problems with TextBox, Label and Grid.

[Totti]

"XAML is static but communicates with code behind just well". From my perspective, XAML is the achilles heel of C#+WPF because it does not enforce static type checking and forces you to duplicate the same thing seven times in different places with any human errors being picked up by the customer rather than the static type checker. If I use F# instead of XAML it is more concise and completely strongly statically type checked.

[Totti]

"Silverlight". Silverlight is dead tech. I worked on a major app that was written entirely in Silverlight but, after I left, they rewrote the whole thing in WPF because Microsoft killed Silverlight.