[Haskell-beginners] calling inpure functions from pure code

Sean Perry shaleh at speakeasy.net
Fri Oct 12 22:22:36 CEST 2012


On Oct 12, 2012, at 12:44 PM, Emmanuel Touzery wrote:
> 
> But it's also good to see that there is consensus on how to code this, if we want to maximize pure code.
> 

I am still working my way through Haskell as well. I still code more in Python or C++. In my experience mixed code and I/O is faster to develop early on. Then features start coming in, the code size grows and you start to think about maintaining it. In Python or C++ this is when you would start thinking about refactoring the I/O out of the code. I like that Haskell gives me strong nudges in this direction from the beginning.

Typical first draft of a Python function:

def foo(filename):
    # open file
    # read data
    # work on data
    # return result

typical second draft:

def foo2(handle):
    # read data from handle, now it works with all kinds of I/O sources
    # work on data
    # return result

common ending point:

def foo3(data):
    # work on data, now we do not care where the data came from
    # return result

In programming we often trade one efficiency for another. If the parsing takes a few more seconds but I can hand the code off to someone else to add the next feature then that is a worthwhile trade off for me. Or more often, I only touch the code a few times a year. The smaller and better contained the pieces the quicker I can get back to work.

A frequent problem I have as a paid developer is dealing with code bases where management fears change because testing was not a consideration. So now a few years in there is a pile of code that was well thought out originally but now is a jumbled mess and no one knows what happens when you twiddle just one part of it. In my opinion every developer needs to internalize this and plan for the future from the beginning. Now, we know that some things are going to be 30 lines long and not change much later. In those cases over engineering is not worth it, obviously. But avoiding better design out of concern for performance is a path to failure.




More information about the Beginners mailing list