Code “Purity”

     The other day, I was listening to the latest .NET Rocks episode with Michael Palin… I mean Simon Peyton Jones… on functional programming and the Haskell language.  One of the things he talked about really struck a chord with me, namely function “purity” in Haskell. 
     In modern programming languages, when we call a function, we know what kind of things it needs to do its job (parameter types) as well as what kind of thing it will give back to us as an answer (return type).  For example, a function in C# may look like this:

int DoSomething(int foo){ … }

     We know that means it takes an integer and gives us back an integer.  But what it doesn’t tell us is how it affects the state of the rest of the system, like writing to a file or a database, printing something to the screen, modifying variables outside its local scope, etc.  In other words, it may have side effects.  Sometimes, we call functions precisely for their side effects ( void Foo(){…} ). 

In Haskell, though, by default functions cannot have side effects.  These are “pure” functions.  If you want a function to be able to, say, write to a file, you must explicitly declare it that way.  It actually has a different signature from a function that can’t do IO.

This got me thinking about a language I use practically every day at work, COBOL.  That’s right, boys and girls, it’s still out there, alive and (perhaps) well.  Where I work, practically all of our business logic is still in COBOL.  We’re making the transition to the .NET platform, but it’s a painfully slow process.  Anyway, as I was listening, it occurred to me that every single function ever written in COBOL is, for lack of a better term, “impure.”  It exists solely to change the state of the system.  When you call it, you must know not only what it does, but precisely how it does it.

I’m not trying to just bash COBOL here (as much as it puts a bad taste in my mouth sometimes), but to say that I think this can influence my design of programs in other languages.  It’s my hypothesis that if more of the functions that I write were “pure” in the Haskell sense, the entire system would be easier to test, debug, and understand.  If anyone else has thoughts on this, I’d love to hear them.

2 thoughts on “Code “Purity”

  1. David Mohundro

    I had always thought of it in terms of “lack of local variables” but that is a great way to put it. An additional value that “pure” functions give you is that they are inherently thread-safe. If you don’t modify state, you can do whatever you want. As Moore’s Law moves more and more into multiple cores instead of higher clock speeds, we’ll have to worry more and more about the purity of our functions.

  2. Brian Sullivan

    That’s a good point, David. I’d forgotten about the threading stuff. Multi-threading is one of those things that still makes my brain come out my ears. Functional programming even more so, actually. I’m gonna have to sit down and learn F# one of these days, if for no other reason than to be able to truly take advantage of the functional-esque aspects that are making their way into more “mainstream” languages.


Leave a Reply

Your email address will not be published. Required fields are marked *