Lodash v3.0.0

It is, however, amazingly convenient and capable of saving a lot of time in bug fixes.

Isn't what's a "requirement" something that THEY get to decide for their code base?

Some code that I've written using Ramda.js:

  var predicateListFunc = function(props) { return R.allPredicates(R.map(R.curry(R.eqProps), props)); }
  var compareProperties = R.unapply(predicateListFunc);

  var mergeLists = R.unionWith(compareProperties("Property1", "Property2"));
  var groupById = R.groupBy(R.prop("Property1"));
  var getGroups = R.compose(R.toPairs, groupById, mergeLists);

  var groups = getGroups(list1, list2);

I don't know if this answers your question, since I wrote in about an hour of learning Ramda.js, and there might be an easier way of doing it.

Here's a fiddle:

http://jsfiddle.net/Gk6uu/10/

This slideshow [1] by one of the authors of Ramda.js goes over a JavaScript example in OO style and refactors it to functional style. Currying is used to complete the refactoring.

I've linked to the slides on currying but you'll need to back up to follow the whole example.

[1] http://scott.sauyet.com/Javascript/Talk/FunctionalProgrammin...

There is an excellent talk called "Underscore, you're doing it wrong!". The talk explains how well designed param order with currying leads to very short and expressive code -- and how underscore missed the boat. This aspect of it should be interesting as it's related to this post. It's well worth the watch.

https://www.youtube.com/watch?v=m3svKOdZijA

One situation where I felt compelled to use lots of currying was when I was working with a promise library for async code. There are lots of little callbacks you need to use and you benefit from having combinators that act as function versions of js operators, like "+", "[]" and so on and currying helps cut down on the number of combinators you need.

That said, I didn't end up being a big fan of it in the end. Other people can get confused by the new abstractions the combinators introduce and whenever you pass the wrong number of arguments to a function you end up with very tricky runtime errors (this isn't an issue in Haskell because the type system checks this for you)

"A programmer’s pipe-dream is to write code, and be able to use it repeatedly with little effort. It’s expressive because you write in a way that expresses what is needed, and it’s reuse because.. well, you’re reusing. What more could you want? Curry can help.":

http://hughfdjackson.com/javascript/why-curry-helps/

It makes the syntax a bit better for combining functions. Seems like a small thing, but with all the complaining about nested callbacks I guess it's good. See Ramda, who came up with this concept, for a deeper discussion of the benefits.

http://fr.umio.us/why-ramda/

Coming from a Python background, Ramda's (function, iterable) feels way more natural than vice-versa:

https://docs.python.org/2/library/functions.html#map

It's only lazy if it's part of a chain

Chaining is deferred until `value()` is implicitly or explicitly called. However shortcut fusion does not apply to `forEach`.

But if you want backward compatibility, you still probably want to use something like Lodash. I'd also argue that Lodash's/Underscore's interface is far better thought out than the standard library. The standard library has so many absurd gotchas, like `["2", "2", "2", "2"].map(parseInt)`. The verbosity of Javascripts lambdas also makes composition of simple parts more arcane looking than necessary, and having a whole bunch of composable/chainable utility functions does a lot to help people write self-documenting code.

Interestingly, in practice lo-dash actually doesn't proxy through to the native implementation for things like map and forEach. Just using loops ends up being more performant because of some edge cases in the ES5 spec for those methods that lo-dash and underscore don't follow.

http://benmccormick.org/2014/11/12/underscore-vs-lodash/

The most important feature is chaining and lazy evaluation.

I think the most useful functions are the typechecking utilities (typeof in javascript is the most useless keyword the human kind engineered in a language).

In the end is a very nice library to work with when it does not get in the way (of course, if you are using `_.each([], fn)`, you should think again and use `Array#forEach` or a nice `for`)

It should start being called "the jQuery effect" since it's one of those libraries that comes to be considered by the community as a standard way to patch the environment. Not only that, but some people begin to develop very strong, quirky aesthetic preferences for seeing it in their code.

They used too say that when the project was new. Perhaps now they feel the project is established enough that it can stand on it's own without trying to position it as a drop-in replacement for underscore.

Lazy.js claims to be even faster than both with support for lazy evaluation to boot. Not quite a drop-in replacement like lodash is, but I think it only requires a minor tweak.

That's an interesting perspective. I don't have any inherent problems with large libraries, but my problem with some of these 'monoliths' is that other libraries start to depend on the entire library when they only need a small piece of functionality that the library provides.

Substack wrote an article [1] explaining some of the problems that monolithic libraries cause in an ecosystem.

[1] http://substack.net/many_things

I remember trying this a while ago and being disappointed at the amount of dependency code brought in for a rather trivial function, but the modularization is looking much better than it was last time I took a look.

Thanks - it sounds as if you could use it as a drop in replacement for underscore.

There are two kinds of JS developers, those that use LoDash at least once per function and those that have never heard of it!

It's only lazy when using the chaining syntax - and that one was never a standard replacement since `_.map(arr, fn)` returns a wrapper around a value and not a value.

Are you talking about this?

    // in 2.4.1
    _([1, 2, 3]).forEach(function(n) { console.log(n); });
    // => logs each value from left to right and returns the lodash wrapper

    // in 3.0.0
    _([1, 2, 3]).forEach(function(n) { console.log(n); });
    // => returns the lodash wrapper without logging until `value` is called
    _([1, 2, 3]).forEach(function(n) { console.log(n); }).value();
    // => logs each value from left to right and returns the array