Matthew Podwysocki's Blog

Recently, there has been an effort launched called the “Anti-If Campaign” in which they deride the use of if statements and instead, focus on Object Oriented Principles in order to create more flexible designs.  Now certainly, I have a sympathetic ear to this cause as I’ve seen code that literally walks off the side of the screen due to nesting of if statements.  Pattern matching to me, especially at the top level of the function is actually quite beautiful in a way, such as the implementations in Haskell:

When I was reading through Real World Haskell, I was struck several times by the mention of providing safe function alternatives.  The idea is to provide a function that in all cases returns a value as well as the one which is meant to accept valid input and throw exceptions should that contract be violated.  There is a real performance consideration to be taken into account as a function which repeatedly throws exceptions as logic will tend to overwhelm a system and slow it down significantly.  Imagine if you will an application which reads a large directory to check each file for an X509 certificate, whether it has one or not, and it throws an exception if one is not present.  The problem of course is there is no way to determine whether a file was signed at the time using the .NET class without resorting to P/Invoke (my favorite).

As you may have noticed, I’ve been covering a bit about concurrency on this blog lately, and for good reason.  Between Axum, Erlang, Scala and F#, there is a lot to explore with actor model concurrency, task based concurrency, data parallel applications and so on.  In the next couple of months, I have some talks coming up on concurrency and in particular with F#.  I’ve been covering a bit of that with F# and mailbox processing, but I wanted to step back a bit into the asynchronous workflows and hitting against a well known API. 

After revisiting the Haskell Wiki recently, I wanted to look at memoization again for a brief second after talking about it a while ago.  In particular, there were two competing ideas, one around using a generic dictionary/map for storing the memoized values, the other using a lazy list approach.  I wanted to briefly look into those as possible solutions.

As you may have noticed on this blog lately that I’ve been focusing on Asynchronous Workflows.  In those adventures, I’ve been taking well known APIs such as Twitter, Bing, among others and seeing what I can do with them.  In this instance, when using LINQ to XML, I’ve run into a slight syntax problem.

UPDATE: Removed code and explained that what I had was not intended behavior

The June installment of DC ALT.NET will be on June 10th, 2009 from 7-9PM.  Stay tuned to our mailing list to stay up to date with the happenings of the group.  We’ve moved up the schedule just a little bit to accommodate our presenter, who will be attending Ruby Nation later that week. 

While working on a side project recently, I came to rediscover some of the consequences of one of my earlier posts on “Side Effects and Functional Programming”.  It’s important that we realize that when we are creating our programs to beware of lazy evaluation and side effects.