Matthew Podwysocki's Blog

In many of my presentations lately, I’ve been using the Parallel Extensions for .NET as part of my heavy computations in F#.  By doing so, I’m able to speed up some of my heavier computations by several fold and take full advantage of my machine.  Over time, with the help of others, I’ve translated many of the functions from the ParallelEnumerable class into those that can easily be consumed by F# in a meaningful way. 

The February meeting for DC ALT.NET will be on February 25th from 7-9PM.  Check the our mailing list for continuing updates and future meetings.  This month, Paolo del Mundo will be presenting "Advanced jQuery".  With the inclusion of jQuery support from Microsoft, understanding this library is a must.  Being the language enthusiast that I am, I'm always looking for deep dives into languages, and Javascript has been one of those languages that I have a passion for.  Once again, I'd like to thank the Motley Fool for hosting us this month.  We're always looking for sponsors, so if you'd like to sponsor us, please contact me via the mailing list.

In the previous installment in my quest to make monads a little more approachable, I covered the maybe monad and how it can apply as a general design pattern for dealing with lookups that may or may not succeed.  We covered how as a functional design pattern, we can use these monads to easily compose functions together in such a way that makes sense.  This time, we’ll look at the list monad, and how you may already be using it without knowing it.

As I’ve announced earlier, and if you follow me on Twitter, I’ve been doing a bit of Haskell lately through the Real World Haskell book club that I started.  Most recently, through our learnings, we have been covering the basic fundamentals of functional programming.  The most fundamental piece to this is to understand how to apply the basic three higher-order functions, map, filter and fold.  This time, we’re covering the fold function in a neat challenge to convert functions which use explicit recursion to use folds instead.  So, what are folds anyways?

As you may have noticed my emphasis on polyglot programming on this blog.  I’ve been following the language design of Ola Bini’s Ioke with some intrigue as well as dipping my foot into languages such as Clojure.  Just as well, with some lists as Michael Feathers about his “Wish List for the Next Mainstream Programming Language” has me enumerating what pieces I’d like as well.  While doing some more investigation on the subject, I came across a post on Lambda the Ultimate entitled “What Are The Resolved Debates in General Purpose Language Design?”.  That got me asking the same question to myself, so, what are they?  The thread is a great read, especially if you’re a language enthusiast as I am.

In the previous installment in this series, I covered how you can use type classes to implement operators to allow you to do such things as approximate equals for floating point calculations, so that you could run QuickCheck property tests with relative ease.  This post will get us back on track to our refactoring tales and what tools we can use to better understand the language.

In the past I’ve extensively talked about creating monads, but not as much more around them in terms of why you might use them and what problems they are trying to solve.  Since that time, I’ve been challenged by others to actually prove not only that it can be understood by everyone, but they are very useful as well.  It’s been a form of geekery among us software professionals to say, “Whoopee! I’ve learned how to implement a monad to do x” without really explaining the reason why people should care. 

I wanted to take a brief sidebar from the refactoring conversation that I’ve been having in the past couple of posts, and focus on QuickCheck again.  In the next post, I’ll get back to refactoring with HLint.  In this post, I want to talk about using type classes to implement operators to use for QuickChecks property-based tests.