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

Common combinators in JavaScript

gist.github.com

Post reply on HN
Print view View original

31–40 of 55 posts

Re: Common combinators in JavaScript

#31

Post by joeframbach »

skrebbel wrote: post #3

This site embodies everything I dislike about functional programming: an attitude that shorter and less specific is better. What use is a line like const S = f => g => x => f(x)(g(x)); for anyone except someone who already groks what the S combinator does and is for? Why do these combinators have single-letter names anyway? Does that help anyone? Even Haskell, heaven on earth for single-letter guess-what-i-mean coder…

const S = f => g => x => f(x)(g(x));

I'm more likely to write

    const geed = g(x);
    const effed = f(x);
    const S = effed(geed);
I have no idea when I would actually write a structure like this though. Can someone please fill those names in with something like `buildComparator` or `Math.max.apply` or something, anything, that remotely makes sense?

Re: Common combinators in JavaScript

#32

Post by Kequc »

maze-le wrote: post #13
skrebbel wrote: post #3

This site embodies everything I dislike about functional programming: an attitude that shorter and less specific is better. What use is a line like const S = f => g => x => f(x)(g(x)); for anyone except someone who already groks what the S combinator does and is for? Why do these combinators have single-letter names anyway? Does that help anyone? Even Haskell, heaven on earth for single-letter guess-what-i-mean coder…

No one would implement this in a real productive project. This is for explanatory reasons only, and aimed at people already familiar with combinatorial logic. >> I think programming in general, and FP in particular, will become a better place if we all grow up a bit and stop pretending we're too smart to need good naming. I with you on this, but I think this is a bad example. And while we are at it, documentation mat…

> No one would implement this in a real productive project.

Oh my word. If it's code on the internet someone will use it. Especially functional programmers who have somehow landed themselves in a JavaScript position. I've seen much stranger code pulled off the internet and used in production applications by professionals.

That's why it's important to generally publish the best code possible whenever we can.

Re: Common combinators in JavaScript

#33

Post by msla »

skrebbel wrote: post #3

This site embodies everything I dislike about functional programming: an attitude that shorter and less specific is better. What use is a line like const S = f => g => x => f(x)(g(x)); for anyone except someone who already groks what the S combinator does and is for? Why do these combinators have single-letter names anyway? Does that help anyone? Even Haskell, heaven on earth for single-letter guess-what-i-mean coder…

Combinators aren't just programming, they're primarily mathematics. If you think mathematical notation needs to be more verbose, say that, but at least have some idea of what you're saying before you try to dump this supposed problem on a different field.

Re: Common combinators in JavaScript

#34

Post by Jtsummers »

joeframbach wrote: post #31
skrebbel wrote: post #3

This site embodies everything I dislike about functional programming: an attitude that shorter and less specific is better. What use is a line like const S = f => g => x => f(x)(g(x)); for anyone except someone who already groks what the S combinator does and is for? Why do these combinators have single-letter names anyway? Does that help anyone? Even Haskell, heaven on earth for single-letter guess-what-i-mean coder…

const S = f => g => x => f(x)(g(x)); I'm more likely to write const geed = g(x); const effed = f(x); const S = effed(geed); I have no idea when I would actually write a structure like this though. Can someone please fill those names in with something like `buildComparator` or `Math.max.apply` or something, anything, that remotely makes sense?

You'd use something like this when `f` and `g` are also parameters to your function.

  some_function(f, g, x) {
    var effed = f(x);
    var geed = g(x);
    var S = effed(geed);
    // some other logic
  }
Not the S combinator, but consider being able to pass a comparator function to your sort function in C. Or passing an arbitrary predicate to `filter` or an arbitrary binary function/operator to `fold`. The S combinator itself may not be that useful, but higher order functions in general are very useful.

You'll also see their utility if you use tacit programming (programming without variables). Again, maybe not the explicit combinators listed here, but the mode of operating is the same. Tacit programming is easily explored through J, APL (less accessible due to the character set), the various MLs and Haskell.

Re: Common combinators in JavaScript

#35

Post by dmitriid »

skrebbel wrote: post #3

This site embodies everything I dislike about functional programming: an attitude that shorter and less specific is better. What use is a line like const S = f => g => x => f(x)(g(x)); for anyone except someone who already groks what the S combinator does and is for? Why do these combinators have single-letter names anyway? Does that help anyone? Even Haskell, heaven on earth for single-letter guess-what-i-mean coder…

That's why this exists: https://github.com/hemanth/functional-programming-jargon

:)

Re: Common combinators in JavaScript

#37

Post by dmitriid »

joeframbach wrote: post #31
skrebbel wrote: post #3

This site embodies everything I dislike about functional programming: an attitude that shorter and less specific is better. What use is a line like const S = f => g => x => f(x)(g(x)); for anyone except someone who already groks what the S combinator does and is for? Why do these combinators have single-letter names anyway? Does that help anyone? Even Haskell, heaven on earth for single-letter guess-what-i-mean coder…

const S = f => g => x => f(x)(g(x)); I'm more likely to write const geed = g(x); const effed = f(x); const S = effed(geed); I have no idea when I would actually write a structure like this though. Can someone please fill those names in with something like `buildComparator` or `Math.max.apply` or something, anything, that remotely makes sense?

It's one of those things that you arrive at yourself. You rarely, if ever, understand them from Haskell-ish mathematical-ish constructs like these.

Sometimes you could end up with this code in situations like this:

   const data = getDataForUser(user);
   const transformer = getTransformersForGDPR();
   const sanitizedData = transformer(data);
where getTransformersForGDPR returns a single function that may contain a chain of data transformations.

The example is contrived, of course, but you do end up with similar constructs especially if you have been exposed to functional programming.

Re: Common combinators in JavaScript

#38

Post by dmitriid »

Kequc wrote: post #32
maze-le wrote: post #13

Earlier quoted context omitted.

No one would implement this in a real productive project. This is for explanatory reasons only, and aimed at people already familiar with combinatorial logic. >> I think programming in general, and FP in particular, will become a better place if we all grow up a bit and stop pretending we're too smart to need good naming. I with you on this, but I think this is a bad example. And while we are at it, documentation mat…

> No one would implement this in a real productive project. Oh my word. If it's code on the internet someone will use it. Especially functional programmers who have somehow landed themselves in a JavaScript position. I've seen much stranger code pulled off the internet and used in production applications by professionals. That's why it's important to generally publish the best code possible whenever we can.

> Especially functional programmers who have somehow landed themselves in a JavaScript position.

Or Haskell programmers who have somehow landed themselves in any position. I've seen Haskell implemented in Erlang :)

Re: Common combinators in JavaScript

#39

Post by demircancelebi »

skrebbel wrote: post #3

This site embodies everything I dislike about functional programming: an attitude that shorter and less specific is better. What use is a line like const S = f => g => x => f(x)(g(x)); for anyone except someone who already groks what the S combinator does and is for? Why do these combinators have single-letter names anyway? Does that help anyone? Even Haskell, heaven on earth for single-letter guess-what-i-mean coder…

Your comment reminded me one of the essays of PG. http://paulgraham.com/power.html Although I agree with you in general, I think it actually can make us smarter if some piece of code requires us to think on it to internalize.

Re: Common combinators in JavaScript

#40

Post by ljm »

joeframbach wrote: post #31
skrebbel wrote: post #3

This site embodies everything I dislike about functional programming: an attitude that shorter and less specific is better. What use is a line like const S = f => g => x => f(x)(g(x)); for anyone except someone who already groks what the S combinator does and is for? Why do these combinators have single-letter names anyway? Does that help anyone? Even Haskell, heaven on earth for single-letter guess-what-i-mean coder…

const S = f => g => x => f(x)(g(x)); I'm more likely to write const geed = g(x); const effed = f(x); const S = effed(geed); I have no idea when I would actually write a structure like this though. Can someone please fill those names in with something like `buildComparator` or `Math.max.apply` or something, anything, that remotely makes sense?

It looks like something you’d do when the function args are the wrong way around and you rely on currying, and you don’t have a clojure style ‘thread-last’ operator.
Post reply on HN