Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Currying vs. Partial Application (2015)

datchley.name

Post reply on HN
Print view View original

51–54 of 54 posts

Re: Currying vs. Partial Application (2015)

#51

Post by mikekchar »

agumonkey wrote: post #25
mikekchar wrote: post #12

Earlier quoted context omitted.

In what way is it not simple? It's hard to tell what you mean. The syntax is actually a bit of a nightmare if you are writing a parser, but from the perspective of a human reader, it shows you exactly what's going on under the hood.

I think, as others above, parent meant to say "simple to write but not to use".

Hmm... One way that I find easier to understand partial application is to imagine that it's an object. All of the bound variables are like instance variables in the object.

Imagine that you have a collection of items that you want to map over. Unfortunately the function you want to run takes 2 parameters instead of one. What if that function was really an object with one instance variable and a method that took 1 variable. So something like this (if it formats correctly):

  class Person {
    constructor(name) { this.name = name; }
    is(adj) { console.log(this.name + ' is ' + adj); }
  };
  const mike = new Person('Mike');
  ['smart', 'handsome'].forEach((adj) => mike.is(adj));
I think most people from an object oriented background will find this easy to understand. Instead of making an object, though, we can just make a function that binds the value in conceptually the same way:

  const is = name => adj => {
    console.log(name + " is " + adj);
  }
  const mikeIs = is('Mike');
  ['smart', 'handsome'].forEach(mikeIs);
Note: I don't have to make a lambda in the second case because I don't have to trip over `this` pointers, but I could if I wanted:

  ['smart', 'handsome'].forEach((adj) => mikeIs(adj));
Now, imagine that you have a bunch of curried functions, whose first argument is "name". Let's say "is", "jumps", "eats". You could write a function like this:

  const Person = (name) => {
    return { is: is(name), jumps: jumps(name), eats: eats(name) };
  };
This is literally a class (minus the crazy `this` pointers).

This is one of the reasons, I really like Javascript. :-)

Re: Currying vs. Partial Application (2015)

#52

Post by przemo_li »

splintercell wrote: post #50
phyller wrote: post #48

Earlier quoted context omitted.

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…

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 clea…

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

Re: Currying vs. Partial Application (2015)

#53

Post by agumonkey »

mikekchar wrote: post #51
agumonkey wrote: post #25

Earlier quoted context omitted.

I think, as others above, parent meant to say "simple to write but not to use".

Hmm... One way that I find easier to understand partial application is to imagine that it's an object. All of the bound variables are like instance variables in the object. Imagine that you have a collection of items that you want to map over. Unfortunately the function you want to run takes 2 parameters instead of one. What if that function was really an object with one instance variable and a method that took 1 var…

One major difference though, objects with multiple fields will require some sophisticated logic to ensure correct order of initialization (depending on the way constructors and setters are done). A partial function enforces some order. You can accumulate safely information and get closer to a usable and valid final piece of logic.

It's less easy when you need choice although one can use subfunctions .

In OOP you may have fluent interfaces, builder things but it's.. once again a lot for not much more.

Re: Currying vs. Partial Application (2015)

#54

Post by splintercell »

przemo_li wrote: post #52
splintercell wrote: post #50

Earlier quoted context omitted.

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 clea…

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

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.

Post reply on HN