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

Update: It's nearly five years since this post was written. Although much of the code will still work, some parts are now broken. (At the moment, you'd have to replace partition with groupBy and replace use(...).over(...) with useWith(..., [...]).) . I'm not going to try to keep updating this code since

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