[Taken from my post of the same name on F# mail list]
What would smooth the transition of a C# programmer to F#?
While some people here advocate "shock treatment" -- functional is a
different way of thinking so throw away your OO preconceptions and start
over without classes -- that approach (IMHO) is unlikely to appeal to anyone beyond
the highly motivated.
I want to discuss an alternate approach: "augment your bag of tricks with
some new ones".
This approach is designed to make the way as smooth as possible.
Begin by showing how to do in F# what you already know how to do in C#.
Take a number of simple C# fragments, and re-write them in F#, showing each
of the features that map 1:1. Start with C# 2.0 features only.
Early on, will have to discuss mutable vs. non-mutable values, since values
are mutable by default in C#. Show why non-mutable values are a good thing.
Then start introducing new features. Justify each feature by starting with a
design goal, solving it in C# as best as possible. Then show how using one
new feature of F# results in simpler code. NOTE: At the same time, can show
the migration from C# 2.0 to C# 3.0, where 3.0 adds a new
functionally-inspired feature similar to the F# one.
Start with features that are easy for an OO programmer to grasp:
* local functions.
* discriminated union & match.
* sequence comprehension & yield.
* functions as parameters.
Rather than insisting on a pure functional style, show how even a partial
rewrite using one of these features simplifies a given code snippet.
In particular, I have found the following "blended functional + OO" style to
Define interfaces, and implement classes which implement those interfaces.
Use a DU whenever there is "choice between alternatives". Show how a DU is a
powerful way to work with several related classes, rather than deepening the
inheritance hierarchy. That is, encourage a "flat" OO style, where each
class directly implements interfaces, but does not inherit from other
classes. Have an interface hierarchy, but not a class hierarchy.
NOTE: My insistence on using even this limited amount of OO appears to be
controversial, based on reactions from experienced functional programmers.
Only after all this solid ground is established, would I demonstrate the
power of (advanced / higher-order / more abstract) constructs:
* replacing iteration with recursion
* functions that return functions