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

21–30 of 55 posts

Re: Common combinators in JavaScript

#21

Post by always_good »

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 use is for anyone except someone who already groks what the S combinator does and is for?"

How does this not apply to any and all identifiers and symbols and functions?

What use is a given function until you read its signature, implementation, and docstring?

You could use this to condemn all abstraction. After all, even a function you take for granted comes at the expense of indirection.

It just so happens that we as craftsmen make trade-offs. Imagine a pattern that shows up so much that you can extract it into a function like a combinator. For instance, look at parser combinators. Yes, you'd have to credentialize in some patterns, but once again, that's what we do every day as we work on what amount to machinas of abstraction.

Re: Common combinators in JavaScript

#22

Post by Nadya »

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 use is Chinese for someone who doesn't read Chinese? The S combinator written like that is perfectly legible and fine for someone who is already familiar with the S Combinator. I don't see the problem there and I don't already grok the S Combinator. I do appreciate writing code under the assumption people working on the code would have some level of prerequisite knowledge.

I'm sure you'd get a kick out of Co-dfns [0]. But once you learn to "speak" APL programming it makes a lot more sense. I'd highly recommend, if you have the time, to listen to the author explaining the code for the compiler [1].

[0] https://github.com/Co-dfns/Co-dfns/blob/master/codfns.pdf

[1] https://www.youtube.com/watch?v=gcUWTa16Jc0 / HN discussion: https://news.ycombinator.com/item?id=13638086

Re: Common combinators in JavaScript

#23

Post by marcosdumay »

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…

Standard names are good names.

That said, Math is very contextual while development has many varying scope levels. Single letters identifiers are normally not a good choice in a global context because of collisions, however good names they may be.

Re: Common combinators in JavaScript

#24

Post by sctb »

ycmjason wrote: post #14
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…

Ehhhh, I hate reading this kind of comment. Can I suggest try to be more humble and read more before having an opinion on something?

This comment breaks the guidelines. Please don't post like this.

https://news.ycombinator.com/newsguidelines.html

Re: Common combinators in JavaScript

#25

Post by [deleted] »

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…

[deleted]

Re: Common combinators in JavaScript

#26

Post by johnhenry »

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…

I think you've interpreted this as meant to be useful tool for programmer -- and there your criticisms would be spot on. However, this is more of an interesting note for mathematicians than anything else.

Re: Common combinators in JavaScript

#27

Post by bluetwo »

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…

I agree with your gripe.

We are in a field where backgrounds vary widely.

A little "what am I looking at and why do I care" would be useful on this page.

Re: Common combinators in JavaScript

#28

Post by wereHamster »

tobr wrote: post #2

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

Because it truly doesn't matter what 'x' is. It could be a number, string, an Array, Map, React Component, a very specific VerifiedUserWithBillingAddress object from your domain that you're working in right now.

So then what name do you want to give 'x' in `I = x => x`? Is `something` better, more readable?

If you write these functions ad-hoc in your modules as local helper functions, then by all means, use a more appropriate name:

    [1,2,3,undefined,6].map(anIntegerOrUndefined => anIntegerOrUndefined)
But the functions presented here are not those that you should have to write yourself. They are available in the Haskell base library, in JS you can import ramda or other packages. The important thing is to know how and when to use them.

Re: Common combinators in JavaScript

#29

Post by T-R »

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 information, just add noise. Trying to get any more specific than that would leave the reader trying to interpret the meaning of the name, but the whole point is that it's strictly "apply this thing to that in this way, without looking at what they are". Even fix-point, which is unarguably cryptic, really needs a paragraph explanation for the unfamiliar more than it would benefit from better names.

Post reply on HN