The Philosophy of Ramda

The Goal

We're writing Ramda so we could code in a manner not readily available in Javascript. Given data that looks like this:

// `projects` is an array of objects that look like this
//     {codename: 'atlas', due: '2013-09-30', budget: 300000, 
//      completed: '2013-10-15', cost: 325000},
// `assignments` maps project codenames to employee names,

Ranging Near and Far

Quick question: if you have a function of three parameters,

function f(a, b, c) { /* ... */ }

and the first and the third parameters are optional, what's the expected behavior when it's called with two parameters?

f(x, y);
  --> {a == x, b == y, c == undefined, ...} // or
  --> {a == undefined,

Iffy Literals

Today a colleague noticed that he was using a IIFE where a simple object literal might do, and he asked my opinion. The code looked something like this:

var codeWords = (function() {
    var list = ['ABC', 'DEF', /* ... */ 'XYZ'];
    var found = function(test) {
        return list.indexOf(test) > -1;

    return {
        list: list,

Favoring Curry

My recent article on functional composition in Ramda breezed over an important topic. In order to do the sort of composition we would like with Ramda functions, we need these functions to be curried.

Curry? Like the spicy food? What? Where?

Actually, curry is named for Haskell Curry, who was

Why Ramda?

When buzzdecafe recently introduced Ramda to the world, there were two distinct groups of responses. Those accustomed to functional techniques -- in Javascript or in other languages -- mostly responded with, "Cool". They may have been excited by it or just casually noting another potential tool, but they understood what