Hacker News new | past | comments | ask | show | jobs | submit login

It's not that I don't understand there were reasons for choosing the names. I just think they were confusing reasons. :)

It reminds me of Haskell, where monad is such a terrible name. Same with functor, applicative functor, etc. Yes, all these names aptly and mathematically describe what they do, but the most precise name will not help beginners understand.

For instance, if reducers were called "state updaters", I think people would be less confused. Same if "map state to props" was called "get props from state".

Sometimes you gotta give up on giving the most precise name and instead give a name that is the most clear for the greatest number of people.

FWIW, I agree with you--I feel like there's a distinct "pull the ladder up behind you" notion in the land of bleeding-edge software (not just FP, but I'm lookin' that way), where a vocal and influential chunk of the community has decided (and enough others have followed along) that a certain kind of exclusive specificity and conscious choice of high-level vocabulary matters more than the other people who might benefit from the stuff. And then inertia means things don't get better.

Many programmers are bad at naming things. Many are bad at doc. None of this stuff is actually hard, it's just made hard and made unfriendly in unfortunate ways.

It's lovely how counterintuitive it is that (in this case) "map" reduces state and "reduce" modifies and/or enlarges state.

Applications are open for YC Winter 2020

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact