for building invisible machines

Menu

Functional Programming in JavaScript and Ruby

[UPDATE: I’ve been lucky enough to have some commenters who know much more about functional programming than I do. There’s some good reading in the comments, and you especially should read them before using this stuff in production.]

I’ve been playing with functional JavaScript tonight. It’s not the greatest of OO-functional hybrid languages, but it’s good to supplant my fledgling functional skills with something besides Ruby. Plus, I’m not the onlyonedoing it, so I can compare notes. And who doesn’t love JavaScript, right? …right?

Before I get much farther, I should thank Adam Turoff for his post What’s Wrong with the For Loop. It gets at the root of the why we’d use a functional programming language instead of an OO or procedural one, and (bonus!) it helped me grok Ruby’s inject method (it’s the same as my new friend fold). Go read his post, it’s good for you. And if you like it, we recommend the 1981 SICP lectures. Robusto!

Here we go!

Introductions to functional programming usually discuss three methods: map, find, and fold. The names aren’t always the same, but those are the three amigos of functional programming. They all do something different to arrays (or lists, or collections, or whatever you want to call them):

find does what it says. You give it some criteria, it returns all the matching elements. The criteria is expressed as a function, a little bit of code that says “yes, I want this one,” or “no, skip it.” If we’re picking out the red gumballs, you could say (in Ruby) gumballs.find_all { |ball| ball.isRed? }find is also known as filter. [Ruby only calls it find_all because it uses find for returning just the first match.] Po-tay-to, po-tah-to.

fold takes each element, and “folds” it into a running total. Think of summation—you’re folding each new number into a running tally. In Haskell (and, it seems, many functional languages), it comes in two varietes, fold_left and fold_right, which just mean “start from the left” and “start from the right”. Ruby calls it inject, which confuses some people (like me).

map is the mathiest of them (don’t be scared, it’s easy!). In English, we’d say “change each item like this, and give me the new results.” Let’s down-case a list of words. “Change each word to lowercase, and give me the downcased words.” words.map { |word| word.downcase }. The name “map” comes from functions in math (surprise), where you map each input to one output. The whole y = f(x) thing…f is for “function”. Ruby also calls this collect.

Now, none of these comes predefined in JavaScript. How can this be? Well, all the JavaScript engines out there are in browsers, and we know that “when browser elephants battle, it is the JavaScript grass that suffers.” The browser developers are busy with other things. But this oversight means we have some easy examples to write. It’s boring to re-implement existing stuff, just for the exercise. So here we go—I’ll compare examples in JavaScript and Ruby.

A quick word about JavaScript’s open classes

JavaScript has open classes, just like Ruby. In other words, you can re-open a class definition, give it a method, and then start using that method on instances of that class. JavaScript’s OO is prototype-based, not class-based, so it looks a little weird:

“For the prototypical Array, the Array from which all other Arrays spring forth, create a property called ‘first’, which shall be this function, which returns the first element of the Array…” Just a Biblical way of defining a method for a class.

Open classes is good news, because it’ll make our job of adding map, find, and fold possible, since they’ll be going into the Array class.

find is a function, and it takes the function isAMatch as a parameter. One of the hallmarks of the functional programming style is that functions are first-class citizens in the language: they can be treated like any other variable, so they can be passed around as parameters, and returned from other functions. [Closures and anonymous functions are also major features.] isAMatch is a function that tells you whether we should include any given element of the Array. Use find like this:

The first example uses an in-line, anonymous function; the second uses a named function. Both work fine, but here is where we start to see JavaScript’s awkward syntax get in the way. Consider the Ruby version:

In Ruby, every expression returns a value, so return disappears. And Ruby’s blocks mean we don’t need to wrap our match condition inside function(i) { ... }. But Ruby’s find_all won’t take a reference to a method as a parameter:

Once you’ve defined a function in JavaScript, you can pass it around by name, like any other variable, but you need that function(i) { ... } syntax around your test. In Ruby, find_all takes a block instead of parameters, so you can’t pass a reference. Given how nice blocks are in Ruby, I guess this can be forgiven, but it’s a little weird.

Fold

Now we’ll get into the recursive guys. find is a pain to implement recursively in JavaScript, so I did it iteratively, but recursion works well for fold and map. Since recursion seems to be more idiomatic in functional languages, we’ll use it here.

The first is straightforward recursion. If the list is empty, we’re done, so return the base value (zero, if we’re adding). Otherwise, combine the first value with whatever the rest of the items fold up to. [If you have trouble writing recursively, this is the canonical pattern you should probably follow: if done, do base case; else, do this element, then the rest of them.]

The second is a little different. You’ve got a starting base, the tally so far, and a combineFunc that folds each value into the tally. If the list is empty, we’re done, so return the tally. Otherwise, fold the first item into the tally for the rest of the list.

It the first, you hang around, waiting for the answer to the rest of the problem, before you add in your part of the sum. In the second, you push your part of the sum down into the next round of processing, so you don’t have to remember anything. When the answer comes back from the recursive call, it’ll already have your part of the sum in it.

[The first one is a “linear recursive process”, the second is “linear iterative process”, even though both are recursive procedures. If your interest is piqued, check out this SICP page, but it’s not needed for this article. For the rest of this post, I’ll be using the linear recursive version, because it’s conceptually clearer. Thanks to mfp for keeping me honest.]

Notice how similar fold_w_block and fold_w_proc are to the JavaScript fold_recursive. The thing that differentiates fold_w_block and fold_w_proc is how they’re used. The definitions themselves are nearly identical, except for the order of the parameters. Look at sum_w_proc and sum_w_block…sum_w_block is a bit clearer, isn’t it? But if you use blocks, you lose the ability to pass a function reference as a parameter.

Again, it’s basic recursion…if we’re out of items, return the empty list (ie, this). Otherwise, make an array of the first mapped item, and concatenate it with the rest of the mapped items. Again, with JavaScript, you can pass your function in-line, or by reference.

As before, calling map with a block certainly looks nicer than by passing in functions, but you lose the ability to define a function somewhere, and pass it in by name, like we did with cube in JavaScript.

Wrap-up

If you want to explore functional programming, both JavaScript and Ruby are good candidates. They both have their goods and bads. Up to now, I’ve only used Ruby, but JavaScript certainly has its benefits, and exposure to both balances out my understanding.

I hope that, if you were curious about functional programming before, this was a helpful read. If you’re a functional programmer, and I got something wrong, please let me know…I’m still learning. For instance, I now better understand how recursive processes differ from linear recursive processes.

Like this:

Related

Post navigation

21 thoughts on “Functional Programming in JavaScript and Ruby”

On the subject of `fold` and `map`: you should not implement them recursively in Javascript. They’re usually implemented recursively in FP languages because:

* They work on (linked)lists/conses, which are inherently recursive structures. Javascript doesn’t have conses, only arrays. The slicings, array concatenations and single-element array creations of the recursive implementations generate _a lot_ of garbage and straing the JS interpreters.

* FP languages all implement tail-recursion optimization, and even when the functions aren’t tail-recursive they’re usually quite efficient at recursion. Javascript doesn’t implement tail-recursion optimization (which makes your tail-recursive fold — “fold-linear” — completely useless even though it would work in e.g. Scheme or SML) and is overall fairly bad at recursion (not as bad as PHP or VB, but still plenty bad).

So you should probably implement them iteratively, it’s not that hard (and both are actually much shorter, unless you want to implement both `foldl` and `foldl1` as a single function in which case you get an ugly conditional.

Likewise for Ruby by the way, don’t overuse recursion when you don’t have to.

On a side note, since map and filter (and some other functions) have been implemented natively in Firefox 1.5+ as part of JS 1.6 (http://developer.mozilla.org/en/docs/New_in_JavaScript_1.6#Array_extras), I’d strongly suggest using the same names in your implementation, and testing if the methods exist beforehand so that you don’t overwrite them when they’re already available. I’m noting that they didn’t implement folds though. Shucks

Good points. I implemented map, fold, and find to test out my understanding of functional programming concepts, and the bits of SICP I’ve been reading — not for serious usage. I did write them all iteratively at first, and they were shorter, but still very imperative…I wanted to stretch out a bit. I guess I should’ve made that clearer.

Still, implementing them iteratively is probably a good thing, especially if, like you said, we check first for their existence before clobbering a native implementation with our own attempt. My thinking is that if more programmers are used to them, their thought patterns will shift a bit, maybe rise to a higher level of abstraction. Which would be good for everyone.

As far as map and filter in JS 1.6, I’d heard bits about that, and my excitement was tempered by the suspicion that IE 7 wouldn’t include them. Turns out I was right…

It seems you have gotten some terminology mixed up. You’ve written that fold_recursive (foldr) generates a “recursive process” and fold_linear (foldl) a “linear recursive process”, but If I’m reading the SICP page correctly, foldr generates a linear recursive process and foldl a linear *iterative* process (i.e. the function is tail-recursive).
(Also, note that you aren’t using the “base” argument in fold_linear).

“Look at sum_w_proc and sum_w_block…sum_w_block is a bit clearer, isn’t it? But if you use blocks, you lose the ability to pass a function reference as a parameter.” >

Well, does this count?

[1, 2, 3].fold_w_block(0, &lambda{|a,b| a+b}) # => 6

(Another small braino: you say that fold_w_block and fold_w_proc are based on fold_linear, but they’re actually foldr…)

The basic outcome is that Javascript is absolutely terrible for recursion probably due to a very high function call overhead (which given that it must do a load of runtime analysis to support closures probably shouldn’t be all that surprising), at least in Microsoft’s implementation.

Doing this sort of thing in C++ is interesting because the functor objects passed into things like std::transform (the C++ name for ‘map’) can store state. Clearly breaks the ‘no side effect’ rule, but can be used for some interesting effects.

Personally I think Javascript is a great language to do this sort of experimenting on because nearly everybody has several pretty good implementations on their computer.

Nathan,
> Given isOdd as defined above, you can pass that method directly without the block.

My point was to show that Ruby doesn’t let you pass the method name like a regular parameter like JavaScript does, and I think your examples bear that point out…though I didn’t know about &method(:sym). How does it work? Does it return a method pointer? I don’t have my pickaxe handy…I’ll have to read up.

mfp, allow me some time to consider your comment. I was -pretty- sure I had my linear recursive and recursive straight, but I’ve been wrong before. Like I said, I’m still learning.

Kirit,
> Personally I think Javascript is a great language to do this sort of experimenting on because nearly everybody has several pretty good implementations on their computer.

My thoughts exactly. When I started the coding for this post, I was on lunch break from an ASP.Net class, so rather than install Ruby on the machine, I used the ubiquitous JavaScript. I scanned your “Recursive rights and wrongs”, I’ll give it a more thorough read soon.

> My thinking is that if more programmers are used to them, their thought patterns will shift a bit, maybe rise to a higher level of abstraction. Which would be good for everyone.

I do agree with that, even though nothing beats using actually functional languages to understand what Higher Order Functions are about (and have a hard time coding in Java after that)

> As far as map and filter in JS 1.6, I’d heard bits about that, and my excitement was tempered by the suspicion that IE 7 wouldn’t include them. Turns out I was right…

‘course you are, I don’t think Opera and Safari implement JS 1.6 either. As a matter of fact, I’m pretty sure only Mozilla browsers implement them, for the moment at least.

> JavaScript 1.5 includes these methods already

No, that’s in Javascript 1.6, the confusion comes from the fact that the first implementation of JS 1.6 is Firefox 1.5 (and Firefox 2.0 is the first restricted implementation of JS 1.7)

> It seems you have gotten some terminology mixed up. You’ve written that fold_recursive (foldr) generates a “recursive process” and fold_linear (foldl) a “linear recursive process”

I think he meant that foldr was a recursive process executed in constant memory (which is true in a strict-evaluating tail-optimizing language, which javascript isn’t). His terminology is debatable, but that’s the feeling I got

> The basic outcome is that Javascript is absolutely terrible for recursion […] at least in Microsoft’s implementation.

You’ll find that the other implementations fare no better. Maybe we’ll see a better support for recursion with the first JIT implementations (e.g. Adobe’s Tamarin http://www.mozilla.org/projects/tamarin/), but for the moment JS is one of those language which make you want to use FP, but forces you to be very careful about it.

> My point was to show that Ruby doesn’t let you pass the method name like a regular parameter like JavaScript

Yes, but that’s because just writing the name of the message in Ruby means that you’re sending the message to the objet (foo.bar is exactly the same as foo.send(:bar)) while in javascript the semantic is that of a “method call”: writing the method name (foo.bar) is not enough, you have to call it (foo.bar()) for it to be executed.

> How does it work?

Taken straight from `ri Object#method`:

Object#method
obj.method(sym) => method
————————————————————————
Looks up the named method as a receiver in _obj_, returning a
+Method+ object (or raising +NameError+). The +Method+ object acts
as a closure in _obj_’s object instance, so instance variables and
the value of +self+ remain available.

Kirit, the issue I have with your post is that the second category is far too closed: you consider that recursion is bad period, while the issue really is that most popular langages suck at recursion (e.g. in languages such as Erlang or Scheme recursion is not only a powerful tool but one that’s used often) (the fact that these languages usually lack iterative structures helps, too)

>Kirit, the issue I have with your post is that the second category is far too closed: you consider that recursion is bad period

Is that really what I said? That certainly wasn’t the intent. It is certainly a tool I use often, but I’m ultimately careful with it because it can be a source of problems.

Here is my summary:

>Recursion is a very powerful tool and it often enables us to spot algorithms that we wouldn’t otherwise see. We should however be very careful of using it in production software, especially where the parameters for the recursion ultimately derive from user input, or any other non-trusted source.

In languages like Scheme (which I specifically mention) writing tail recursive functions is really writing a loop anyway because you know the language is going to convert it for you.

The reason for writing the subject up in that was because I hadn’t seen anybody point to the obvious problems involved in exhausting the stack with recursive functions.

Despite much hiding of heads in sand about the issue it is still an important consideration whenever recursion is used. That isn’t the same as saying don’t use it though.

> In languages like Scheme (which I specifically mention) writing tail recursive functions is really writing a loop anyway because you know the language is going to convert it for you.

I don’t think it’s “really like writing a loop anyway”, it’s the same to the machine, but you sure think recursively, not iteratively, even if the code is executed iteratively.

Plus I didn’t limit my scope to iterative structures: while tail-recursive implementations clearly are the best, functional languages often have very powerful and efficient recursion abilities even on non tail-recursive functions. And they still don’t have any iterative structures.

Masklinn, I know this sounds like we’re arguing, but I can’t bring myself to believe that we actually have any real difference of opinion here. We may be looking out over the landscape of software development in different directions, but we’re seeing the same features.

I think we both agree that there are all sorts of algorithms that are easier to find and to understand in recursive forms.

I think we also agree that it is better to write those recursive functions that are tail recursive so that they consume O(1) memory rather than O(n).

The only other thing I say in my article is that sometimes non-tail recursive functions are better off re-written because the heap is bigger than the stack and is less likely to be exhausted.

We’re writing for different audiences so of course our emphasis is in different places, but I don’t think we disagree anywhere.

I’m going to have a think about adding some notes to my article to clarify where the issues I raise are of concern primarily to people using non-functional languages in case it can be mis-read.

I think the second “iterative” fold function is a fold_right function and it’s different from the first. Also, in my opinion, the second function looks almost like a for-loop so you might just as well do so (a fold_left though):

Sorry for the last comment… it’s the first function that is fold_right, and the second function is supposed to do a fold_left, but doesn’t do it correctly. I think the it should be combineFunc(tally, this.first()) in the recursive call.