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

For what it's worth, most of that comes directly from the Flux heritage. For example, the Flux docs at https://facebook.github.io/react/blog/2014/07/30/flux-action... explicitly describe the terms "actions" and "action creators" . There was a lot of discussion and bikeshedding in the early Redux issues over whether to use terms like "events", "commands", or even "facts" instead, but Dan and Andrew opted to keep "actions" for consistency with Flux. (Really, a very large percentage of questions about "Why does Redux do $THING?" can be answered with "Because the Flux Architecture, or other existing Flux libs, did things that way first".)

"Reducers" come from the similarity with the callbacks passed to `Array.reduce()`, "thunk" is an existing CS/programming term, and "saga" was also adopted from the backend world. So sure, a lot of these terms are new to most people (especially front-end developers), but they were generally based on existing terminology and not just picked out randomly.




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.




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

Search: