On: Currying vs. Partial Application (2015)

[splintercell]

With all due respect, I don't think you understand the purpose of currying and partial application. In your defense, the article merely explains what currying is, but does not explain why you need it.

For instance while writing functional Javascript code, I never curry my methods, instead I use helper methods from functional libraries such as lodash or Ramda to curry.

Where currying is useful is in cases like this:

  ```javascript
  //Definitions
  const filterUsers = (fieldName, value, users) => //Implementation
  const sortUsersBy = (fieldName, users) => //Implementation
  const takeUsers = (count, users) => //Implementation

  //Without currying
  UserService
   .getUsers()
   .then(users => filterUsers('active', true, users))
   .then(users => sortUsersBy('age', users))
   .then(users => takeUsers(3, users));

  //If these methods were curried
  UserService
   .getUsers()
   .then(filterUsers('active', true))
   .then(sortUsersBy('age'))
   .then(takeUsers(3));
  ```

Here is a video which explains proper uses of currying (and does it very well) [1]. Here is another article if your coworker start using functional programming and you want to stop them [2].

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

2. https://brianmckenna.org/blog/howtostopfp

[phyller → splintercell]

Ok +1 for the super cynical article about how to stop functional programming :D

But obviously that's a cheap shot for an example, no one would have a problem with the function he starts out with, he doesn't need to have a side effect. The problem is when you are in an OOP app, with an OOP language, doing things that really lend themselves to OOP, and trying to shoehorn everything into FP because it's How Smart People Program. And the result is not less complicated, but way more complicated.

I've got these opinions because I've already been that guy saying please stop writing this complicated stuff that I don't understand. I'm not an idiot, we've just got a huge amount of work to do, and the time it takes for me to piece all this together and find the bugs is not worth it, especially because it is going to be just as opaque to you when you have to come back to it in a few months.

I'm not saying FP isn't the best thing ever and someday I'm sure it's going to take over the world, and given all the time in the world and a clean sheet I might choose it myself right now. But I care about working as a team more than the finer points of coding philosophy, and making simple, effective, and on time code. I'll choose practical over principle if I have to, though I'd prefer to have both. And if that means FP, then let's do it, but so far my experience has been the opposite.

For context, we are talking about JavaScript apps, and my comments are limited to front end apps using OOP frameworks and fetching data in the form of objects from a REST API.

[splintercell → phyller]

I used to be the guy who would say that people need to stop writing code which others can't understand, but then I migrated to, "why am I working at a company where I need to lower the bar so much that making changes in a code you understand well takes ages".

I joined that school when I used FP for my own project (I use Elm, and RamdaJS+JS) and found how amazingly handling bugs and complicated logic became. This clearly came with a higher barrier to entry for other people to understand my code (but this cost only needs to be paid once, I look at other people's functional code and I got no problem understanding it btw).

I understand large companies where logic needs to be written so simply so that anyone can understand it (Python philosophy "Code is read a lot more times than it is written"), but they don't end up with fewer bugs, it's just a LOT LOT BIGGER codebase, with 5 million for loops, doing 1500 things in one for loop.

In fact, before I fully went to FP side, I started writing my JS code without using for loops or forEach. Even this simple change of writing code using map/reduce/filter/drop/reject/take etc made code lot simpler to maintain, reason with, and eliminate bugs.

[przemo_li → splintercell]

If you stopped using native loops / forEach how do you handle iteration for the sake of creating side effects?

+1 for including take/drop alongside map/reduse/filter

[splintercell → przemo_li]

In my experience, there is almost never a need for creating a loop on an array purely for the sake of side effect.

For instance, if you want to write something on the log, then loop and collect everything into a single array (using map) and then perform the side effect with a single command (which is a lot more performant in most cases).

For asynchronous side effects, create an array of promises using a map, and then run a Promise.all() on that array if you need to resolve all of them.

But again, if your experience is different or in your requirements, it is not possible to create a map/reduce/filter transoformation for side effects, then I'd love to hear about it.

[ebola1717 → splintercell]

The point-free style is harder to read and reason about imo, especially since the data gets transformed in that pipeline. We use scala, and will avoid currying for this reason.