Functional Programming for Everyday .NET Development

Posted by Jeremy Miller on September 30, 2009

I’ve been an object bigot for most of my career.  Nothing saddens me like having a giant pile of stinking procedural goop code dumped on me in a maintenance cycle.  However, since I got exposed to Ruby several years ago with its mixed support for Functional Programming techniques and passing blocks, I’ve found plenty to like about programming with very basic FP techniques.  About a month ago I was having lunch with a developer friend in Austin and we were debating whether or not the new Lambda stuff in C# 3.0 is really that important to everyday development.  I argued yes, and to hopefully show the affirmative case, I wrote a new article in the October issue of MSDN Magazine entitled “Functional Programming for Everyday .NET Development.” 

My goal with this article was to show how we can incorporate bits of functional programming into our everyday work.  To keep with the theme of “everyday” I stayed with C# and JavaScript rather than F# and no examples about solving the Fibonacci sequence because that’s just not a real world scenario;-)  By absolutely no means should you think this article is meant to be an inclusive explanation of all things FP.  All I was aiming for is to give developers a reason and starting point to learn much more about Functional Programming.  If nothing else, *I* learned quite a bit in the course of writing this article.

I would certainly encourage anybody reading this article to go farther and think about where FP techniques might work better than OOP.

I received quite a bit of help on this article from Chance Coble and Chris Patterson.  I wasn’t able to incorporate some of their feedback just because of time constraints, but I still appreciate the help guys.

And now, I’m dreadfully behind on the next (and possibly last) MSDN article.  Look for “Internal Domain Specific Language Patterns” the next time out in December.

 

I was lamenting on Twitter yesterday that I haven’t blogged in over two weeks, what I think is a new personal record for futility.  I definitely don’t consider these types of self promotion posts as real content, so I’ll get back to blogging something or other real soon.

About Jeremy Miller

Jeremy is the Chief Software Architect at Dovetail Software, the coolest ISV in Austin. Jeremy began his IT career writing "Shadow IT" applications to automate his engineering documentation, then wandered into software development because it looked like more fun. Jeremy is the author of the open source StructureMap tool for Dependency Injection with .Net, StoryTeller for supercharged acceptance testing in .Net, and one of the principal developers behind FubuMVC. Jeremy's thoughts on all things software can be found at The Shade Tree Developer at http://codebetter.com/jeremymiller.
This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • http://realfiction.net Frank Quednau

    Surely you have learned FP techniques well before writing said article? StructureMap’s Setup is full of functions – when I e.g. provide SM with code to call in the event of me needing an instance of IFoo, that sounds to me like a continuation.

  • http://codebetter.com/members/Suddenlink-Communications/default.aspx Suddenlink Communications

    I was thinking the same thing frank – good points

  • http://codebetter.com/members/jmiller/default.aspx Jeremy D. Miller

    @Frank,

    There’s a difference between doing something and having a deeper understanding of what you just did — plus I really believe pattern and concept names are very important for developers. What I had to do was to move up a level or two in Bloom’s Taxonomy and I learned the formal names for some of the techniques I’d already been using. Once you know the formal names, a quick trip to google suddenly opens up a lot more knowledge.

  • Eyston

    If you are looking for blogging topics, I’d be interested to see your take on Object Mothers which you tweeted about recently. Thats my current stumbling block regarding brittle tests. As I grow a domain object it breaks existing tests plus becomes a huge pain to setup just to test a single property / behavior. Looking at a few Ruby frameworks makes me jealous, but I’m not sure how to match the capabilities without creating a ton of methods or overloads. Plus if you want to avoid having a domain object in an invalid state you might not have public setters for everything. This leads me to putting a bunch of stuff in the constructor, but I can’t imagine having a constructor take a laundry list of properties is a good pattern.

  • FenianEMT

    Any particular reason the next may be your last MSDN article? I’ve found your Patterns in Practice articles to be among the best features of MSDN Magazine since you started writing them.

  • http://codebetter.com/members/jmiller/default.aspx Jeremy D. Miller

    @FenianEMT,

    Nothing major, but this next one is the last one on my contract and I haven’t been contacted about continuing + the changes that they’re going through.

    I’d like to take a hiatus for a bit.

  • DaRage

    Amazing post. Full of insight and distilled knowledge. Thank you.

  • Jeff

    A very nice article which I hope will help motivate my colleagues to embrace functional idioms and techniques.

    In figure 2, why does the code sample start with ‘frepublic’? Is this a dark hint that functional programming is a vast right-wing consipiracy? D:

  • http://blog.mike-obrien.net mob

    On the delayed execution sample did you mean to return an IEnumerable instead of a concrete list? So for example this:

    var startables = container.Model.PluginTypes
    .Where(p => p.IsStartable())
    .Select(x => x.ToStartable());

    startables.Each(x => x.Start());

    With the conversion to a concrete list, the iteration is not delayed until the .Each(…) but happens twice, once on the conversion and then again on the .Each(…). I might just be misunderstanding your example though.

    Anyways, great article! MSDN really needs more valuable content like this. I hope you’re able to continue writing for them again at some point.

    m

  • http://awkwardcoder.blogspot.com/ Awkward Coder

    Great article, thank you.

    It’s a reassuring feeling once you realise you’ve been using these techniques without realising there formal definitions.

    One question about the AsynchronousExecutor example code, any reason why you copied the continuation to a local variable before executing the sync. context send method?