The devil codes in Pramda - Wandering in the JavaScript Functional programming world

 Article originally published on Hello.js

As a Perl coder, I'm a big fan of functional programming.

If that sounds odd to you, think about all that features that are considered as idiomatic Perl :
  • List processing (map, grep)
  • High order functions (Mark Jason Dominus ;-) )
  • Lazy evaluation (iterators)
  • Lamda calculus (closure)

Functional programming is a fascinating thing but it’s not so easy to use consistently. We all love the concept, feel the inner power. We all use lists, closure, functions as parameter, but how many of us manage to fully apply functional programming everywhere and commit to pure functions and immutability ?

I recently discovered a wonderful library for functional programming in JavaScript that could help you embrace functional programming even more and I'd like to share it with you: it's called Ramda.
There are several other functional programming libraries (more on that below) but what makes Ramda so practical and somewhat unique is its combination of auto-currying and the design choice to put the data last. These two things empower you and give you endless possibilities through composition.

You probably already know how map and grep can compose to solve many different tasks in a clean way. Now imagine that Ramda offers you one hundred of such functions. The number of combinations, solutions and tasks that you can solve easily just explodes! *1
This might seem theoretical, but for a simple demonstration of how Ramda can ease your life, just read  “Why Ramda ?” by Scott Sauyet.
Among the other things that make Ramda so powerful, Iis its ability to mix with promises through ‘pipeP’ and ‘composeP’. Being able to use both functional programing and promises through a clean syntax is priceless to me.

I should also underline the fact that Ramda promotes immutability: it doesn’t mutate input data by default but still allows you to produce modified one through 'assoc'.
As a final note: Don’t be scared by Ramda’s API, it offers probably far more than you want,  but everything you need. Follow the easy path:  just pick/learn functions one by one.

That being said, it would be unfair to limit functional programing in Javascript to Ramda. If you'd like go further and explore the domain, here are some other projects that I'd suggest to examine:

The well known  'generic' libraries offer functional tools, like the venerable  underscore,  lodash and it’s speedy brother lazy to name a few.

The reactive programming world also provide functional features with RxJs, Kefir or Bacon for the UI.

And if you want to experiment immutability, the choice is your : You can climb on the shoulders of a giant and use Facebook’s immutable or favour speed with mori or try the frozen object approach of icepick.
In a future article I'd like to talk about my current favourite youtube tech channel : 'funfunfunction'  so stay tuned! It's a really great channel about functional programing, JavaScript and other topics of interest.


Oh, and if you wonder about the title:
I like Ramda so much that I wanted to use it in my daily work, and started to write a port in Perl: Pramda (Perl Ramda). Any resemblance to any film title is purely coincidental...

*1 Functions like ‘transpose’, ‘unfold’, ‘times’, ‘allPass’, ‘cond’ are the first examples that come to my mind, but I bet you’ll learn to love the others while using Ramda.


Unknown a dit…
Hi, looking forward to your Ramda port on CPAN, but I am a bit skeptical. What is the additional value of another bunch of utilities which are already on CPAN (List::Util, List::MoreUtil) or are simple enough to write them "in place".

I am a big fan of immutability and "functional style" in my Perl programming. Most my Moose accessors are ro and the objects interfaces are getting thinner and thinner until they consists of single method, so the object can be replaced by a coderef. But I can not see how some library in Perl (or Javascript) can do something like "emphasizes a purer functional style. Immutability and side-effect free functions are at the heart of its design philosophy". For example everywhere I supply any callback to map, grep, apply it is only my responsibility to make it side-effect free.

Also "Ramda functions are automatically curried" is a "killing" feature for me. Having a function which either does something or (if not supplied enough parameters) returns curried version of self may be a sexy feature and very temporary relieve for author but it is a nightmare for any future readers, including the later version of author. In typeless perl (Javascript) you are not able to recognize intention - author wanted to have curried version of function from mistake - author forgot to supply the args. Doing it explicitly (curry(add)(1)) is ok.

Good luck with Pramda.

Posts les plus consultés de ce blog

What is the average salary for Perl programmers in 2020?

On the move

Rewriting my .vimrc from scratch