?

Log in

No account? Create an account
entries friends calendar profile Elf Sternberg's Pendorwright Projects Previous Previous Next Next
The Functional Programming Crock - Elf M. Sternberg
elfs
elfs
The Functional Programming Crock

Quick, what’s the difference between these two expressions?


// Javascript

var add21a = function(a) { return a + 21; };

var add21b = (function(b) {
    return function(a) { return b + a };
})(21);

// Coffeescript

add21a = (a) -> a + 21
add21b = ((b) -> (a) -> b + a)(21)

When I first encountered functional programming, I internalized the definition of a pure function: A pure function is one that always returns the same result given the same arguments.  You should always write your code in a transformative way: Given a set of inputs, write the toolchain to unambiguously create a set of outputs and, only then, perform the side-effect of updating your presentation to reflect your result.


It wasn’t until I was knee-deep into a program with a lot of functions-writing-functions that I stopped to ask myself the question posed above.  I was peeling off dozens of functions that, themselves, were created with closures that retained a lot of state, were themselves mapped to various inputs into the system, and were themselves responsible for producing the output.


The magic is that each individual function was pure: it always gave the same result given the same arguments.  But each function itself was created by a pure function that, given the same arguments, produced the same pure function.  So, was the entire result pure?


The answer, apparently, is yes.  The answer to my question above is, there is no difference.


On the one paw, I understand the point being made here: I can reason about my code much more rationally.  The products of each step are smaller, more reasonable, and generally easier to comprehend, so both ensuring that the code is correct, and debugging it, are facilitated by the functional approach.  On the other paw, this approach allows one to create a vast array of functions rather than a large object with a single function and a vast array of data, with the possibility of code sprawl now simply existing in a different form.


I like functional programming.  It fits my brain, as the Python folks say.  But I don’t think we should at all kid ourselves about the complexity of writing software, or the possibility of anti-patterns emerging out of functional programming.  I’d be happy to say that there are fewer anti-patterns in languages like Haskell or Coffeescript, but the ones left behind are much harder to manage, avoid, and debug.


 

2 comments or Leave a comment
Comments
bolindbergh From: bolindbergh Date: September 11th, 2013 06:24 pm (UTC) (Link)

add21a("foo") returns "foo21"
add21b("foo") returns "21foo"

This is not what I'd call no difference.</pedantry>

elfs From: elfs Date: September 12th, 2013 07:15 pm (UTC) (Link)
Meh. Typesystems would fix that problem by rejecting your silly attempt.
2 comments or Leave a comment