Common combinators in JavaScript • Hacker News Board

Re: Common combinators in JavaScript

#41

Post by z3t4 » Tue, Feb 20, 2018, 9:22 PM UTC

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…

This is why I don't like math. I guess mathematicians write like that because it's faster to write on a blackboard. When I do it myself in code I always go back and rename those single letter variables to proper names. It forces me to know what the code actually resembles, not just a formula I learned by heart.

Re: Common combinators in JavaScript

#42

Post by joeframbach » Tue, Feb 20, 2018, 10:02 PM UTC

dmitriid wrote: post #37

joeframbach wrote: post #31

Earlier quoted context omitted.

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…

Ah, that does make sense. I think this happens in the React world sometimes, where a single state holds the source of truth for everything, and we end up passing parts of it around to other methods to make decisions.

   const data = getDataFromState(state);
   const transformer = getTransformersForState(state);
   const sanitizedData = transformer(data);

Re: Common combinators in JavaScript

#43

Post by Roboprog » Tue, Feb 20, 2018, 10:47 PM UTC

z3t4 wrote: post #41

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…

This is why I don't like math. I guess mathematicians write like that because it's faster to write on a blackboard. When I do it myself in code I always go back and rename those single letter variables to proper names. It forces me to know what the code actually resembles, not just a formula I learned by heart.

I’m not going to defend single letter names (although shortness does have some virtue compared to some monstrous naming conventions), but...

Most math texts have a fair amount of documentation when formulas are introduced. Perhaps substantially more than the table in this article.

Re: Common combinators in JavaScript

#44

Post by kazinator » Tue, Feb 20, 2018, 10:50 PM UTC

Roboprog wrote: post #43

z3t4 wrote: post #41

Earlier quoted context omitted.

This is why I don't like math. I guess mathematicians write like that because it's faster to write on a blackboard. When I do it myself in code I always go back and rename those single letter variables to proper names. It forces me to know what the code actually resembles, not just a formula I learned by heart.

I’m not going to defend single letter names (although shortness does have some virtue compared to some monstrous naming conventions), but... Most math texts have a fair amount of documentation when formulas are introduced. Perhaps substantially more than the table in this article.

Math papers on the other hand assume that the reader has recursively traversed and read all of the citations and knows most of the notation.

Re: Common combinators in JavaScript

#45

Post by FnuGk » Tue, Feb 20, 2018, 11:01 PM UTC

T-R wrote: post #29

tobr wrote: post #2

Is there a reason why functional programming algebra insists on using one letter identifiers?

It's intentionally to get across the idea that you don't, and shouldn't, know anything about these arguments within this scope beyond "this is a function" and "this is an argument". These functions just define how to combine things; if you knew any more about the arguments, it would be breaking the abstraction. The only better names you could really give are ones like func1, func2, arg1, arg2, which don't add any inf…

That makes sense for the arguments to the outermost function but not to the function it self. Why call it A instead of apply and the then have a big cheat sheet where you put that A means apply and T means applyTo ?

Re: Common combinators in JavaScript

#46

Post by catnaroek » Tue, Feb 20, 2018, 11:25 PM UTC

Sharlin wrote: post #8

tobr wrote: post #2

Is there a reason why functional programming algebra insists on using one letter identifiers?

Mathematicians insist on one-grapheme identifiers, partly due to tradition and aesthetics, and partly because at some point juxtaposition came to represent multiplication, so what xy means would be ambiguous.

It is for purely pragmatic reasons. Try actually writing calculational proofs using long identifiers. You will soon find yourself wanting to be drowned in lava.

Of course, a true programmer delegates even the simplest calculation to a computer, so they have less of a need for notation that is easy to manipulate.

Re: Common combinators in JavaScript

#47

Post by mikekchar » Tue, Feb 20, 2018, 11:37 PM UTC

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…

What I find interesting is that I actually don't mind the single letters at all. As others have said, a name is a name and I don't find either "substitution" or "ap" any more enlightening than "S". I also find that the currying of the parameters in the JS code is hard to read. As soon as I see the type signatures in the next chart, though, it becomes obvious what it's doing.

Re: Common combinators in JavaScript

#48

Post by kmill » Wed, Feb 21, 2018, 2:03 AM UTC

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…

Incidentally, the S combinator shows up in the J language as the "monadic hook". If f and g are functions, where f takes two arguments and is written infix (so "x f y" is how you write the application of the arguments x and y to f), (f g) x equals x f (g x). It's useful for certain idioms, like "equals rounddown" (actually written =The thing with these combinators is that they are so low level, so names for them are almost useless. If you were to program with them directly, you'd learn to use and recognize useful sequences of them. At least that's the theory for APL-like languages like J.

Re: Common combinators in JavaScript

#49

Post by tathougies » Wed, Feb 21, 2018, 2:05 AM UTC

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…

Calm down... The SKI combinators are not meant to be used by people. They are an assembly-like notation developed for language implementors.

Your critique is like someone claiming imperative coders are horrible and don't value naming because of assembly language.

Re: Common combinators in JavaScript

#50

Post by tathougies » Wed, Feb 21, 2018, 2:06 AM UTC

tobr wrote: post #2

Is there a reason why functional programming algebra insists on using one letter identifiers?

The S K I combinators were developed as the equivalent of assembly language for functional programs.

In reality, expanding a lambda expression into SKI combinators takes up a lot of space. Since the notation is mainly for language implementors, using the short mnemonics allows you to compress the size of the resultant expression.

It's the same reason why the x86 opcode is named 'mov' not 'move'.