What are some good practices when trying to teach declarative programming to imperative programmers?

Question

I offered to do a little bit training in F# at my company and they seemed to show some interest. They are generally VB6 and C# programmers who don't follow programming with too much passion. That being said I feel like it is easier to write correct code when you think in a functional matter so they should definitely get some benefit out of it.

Can anyone offer up some advice on how I should approach this?

Ideas

• Don't focus on the syntax, instead focus on how this language and the idioms it promotes can be used.
• Try and think of examples that are a pain to write in an imperative fashion but translates to elegant code when written in a declarative fashion.

Answer 1

Functional programming is an odd beast for me. I learned F# and Haskell, wrote a few simple programs and love using them, but never had the "flash of revelation" that some people talk about. But slowly, I noticed that more and more I was writing code that was meant to be immutable, breaking up tasks into more, smaller functions, and trying to use delegates a lot more. Its a thing that, if you like it, creeps into your work because the value of those techniques are self-evident.

Now, more practically for training: I find that two concepts really click Functional Programming as a style to me.

First, FP style is based on structure of data, not composition as in OOP. I looked at something like List in C# as being a clever trick to generate type-safe lists, something that composed the type (string) into the other type (list). After learning FP, I look at generics more like Monads now. List is a structured form that code can take, and it decorates the strings.

Second, and perhaps more useful to C#/ASP programmers, is the idea that FP works on recursion and repetition, while OOP works on mutability and looping. I tend to think of the ASP page lifecycle as a kind of FP now: each request is processed from scratch through the entire life-cycle, so the entire page is, in effect, one big slowly recursing program. If you can narrow that notion down, you get a better idea of how an imperative program can be structured around loops of functions that take in data, operate over it, and return out new data instead of modifying the old.

The trickiest hurdle, at least for me, to overcome with this approach is that sinking feeling that you're wasting tons of resources when using mutable objects would save a ton of memory. In GC we trust, and I just had to learn to let go of performance concerns until I'd actually seen the program run and verified if there even were any, and if so to use a profiler to see exactly where the problems were.

Answer 2

I would recommend:

• the presentation Taming Effects with Functional Programming by Simon Peyton-Jones
• the book Real World Functional Programming: With Examples in F# and C# by Tomas Petricek and Jon Skeet

Answer 3

Many imperative programming languages (Ada, C/C++, Turbo Pascal, FoxPro) have the ability to define pointer to functions or procedure name literals that can be evaluated (and the procedures named after the literal invoked) at run time.

The traditional example is qsort in C. Build on that the notion that you can define algorithms that execute other algorithms on data structures. Obviously this is just a fraction of what functional programming is. But I've found that this is a good starting point to get the idea to sink in.

Once that sinks in, then you can start delving into other things (immutability, share-nothing, etc.)

Answer 4

Can anyone offer up some advice on how I should approach this?

Sure:

• Pick your examples carefully so your F# code not only solves a problem elegantly but also much more elegantly than is possible with C#/VB. Pattern matching and type inference are your friends here.

• Use one example to highlight the benefits of new feature found in F#, e.g. asynchronous workflows, active patterns.

• Don't be afraid to give impure examples using mutable data structures when appropriate. F# is impure for a reason.

• Don't present F# as a panacea. Describe applications for which F# is not well suited as well as those for which it is much better suited than other .NET languages.

• Point at toy samples they can study as well as successful real-world projects that used F# (Bing AdCenter, Halo 3 etc.).

• Explain everything in terms of how F# can help them to solve problems more easily. Avoid religious debates. Stay positive about F#, not negative about other languages. Arm them with facts and evidence but let them draw their own conclusions.