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?


  • 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.
  • F# and declarative programming?????
    – P Shved
    Sep 21, 2010 at 19:48
  • @Pavel - Is that a question? Sep 21, 2010 at 19:50
  • 3
    @Pavel - OK, care to explain why you made the statement? This is the second time you've made extremely vague comments. It is very rude. Sep 21, 2010 at 20:13
  • 3
    en.wikipedia.org/wiki/Declarative_programming Functional programming is a type of declarative programming. Also, +1, good question. Sep 21, 2010 at 20:20
  • 2
    @Chaos, in my opinion, F# doesn't support declarative programming paradigm. Its eager evaluation and imperative features make the language merely a convenient, functional-like form of denoting the same imperative statements you use in, say, C#. Come on, even make is more of a declarative language than F# or Caml! (Ironically, this makes your job easier. )
    – P Shved
    Sep 21, 2010 at 21:20

4 Answers 4


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.


I would recommend:


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

  • Correction: What I mean to say is build on the notion that you can define parametrized algorithms that can take OTHER algorithms as parameters and execute them on data structures. Oct 13, 2010 at 1:30

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


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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.