Going FunctionalIntroductionTake a look at the following piece of code. What’s wrong with it? myAwesomeFunction = (objects) -> isGreat = false for item in objects if not item.isImportant continue if item.isGreat isGreat = true break return isGreat Does it go through all the items? No but, man, is that break on the last line easy to miss. Now compare it with the following version: myAwesomeFunction = (objects) -> return _.any objects, (o) -> o.isImportant && o.isGreat Even if you’re not familiar with the (wonderful, by the way) Underscore.js library, you can pretty much guess that myAwesomeFunction returns true iff objects contain a great important object. Now, you could make a (valid) point that the original function is not a shining example of super-ninja programming skills. But that’s just another thing to point out: using for loops doesn’t push us, programmers, to be any clearer. Actually quite the opposite – it stands in our way by forcing us to remember we’re in a loop and we’ve to deal with it. When it comes to expressing our intentions, a for cycle is a low level construct; unless you read the code thoroughly and really understand, you can’t know what the purpose of the loop is. It can filter something out or transform all the items in the list. It can signal whether a certain item is present. Frankly, for all I know it can brush your teeth and sleep with your wife. It’s just too powerful. Too universal. Now, in case CoffeeScript (or JavaScript) is your language of choice, chances are you’re not writing the type of software where speed is essential. Which means (or should mean, anyway) readability beats raw speed. Hands down. And that’s when functional programming saves the day. In the next article of this series, we’ll take a look at the ‘map’ function. « Igor Tandetnik’s Passthrough APP… Now on Github! - Adding a Toolbar Button in a Bootstrapped Firefox Extension » COMMENTS
|


