[Mindstormy]

I view Ramda as a redflag in most any code base I see it in. Anecdotally, every large codebase I have worked with that heavily used Ramda is generally held together by one very smart engineer. Once that engineer leaves the company, the code base falls apart because no one else can understand it very well and it takes ages to fix bugs or ship new features. So these days I champion against Ramda simply because I think it just takes to much effort for a typical engineer to understand and it is usually at odds with the rest of the companies code.

[dmix]

Sounds like you've worked with people abusing Ramda. It's not that complicated when used as a utility library rather than some hard FP approach to programming...

I've been using Ramda for years and I'm really struggling to see how any of the code in our projects have been complicated by it vs lodash or any other similar utility library.

[solardev]

But then why use Ramda at all then? There's plenty of non dogmatic libs that don't try to get you to curry your functions and spice your parameters and traumatize your children or whatever. Ramda encourages (in its official docs) unreadable code for the sake of style purity...

[dmix]

Because I prefer the FP style, arg orders, name schemes, documentation, and Ramda is just generally very clean and simple. And you absolutely do not need to use currying when using Ramda. It's entirely optional (just pass 2 arguments...). I tried it a couple times using Currying with Ramda but it mostly makes confusing code so I never did. That was probably 7-8yrs ago and I still use the library daily.

Idk what type of code bases you guys have worked on but I've never had anything close to a situation where it complicated my Codebase or had other devs who were confused by it.

I can imagine someone abusing currying and getting fancy with 10 levels of functions wrapped in another function that gets passed around but honestly that is just bad programming.

Simplicity and clarity is something that is necessary in all programming, FP is not unique, and this library doesn't push you one way or the other, unless you use it for absolutely everything.

[phatskat]

> And you absolutely do not need to use currying when using Ramda. It's entirely optional (just pass 2 arguments...)

I think this would be my only argument against Ramda vs something like Lodash, at least in a project with other contributors. Like, I’ll never use the currying because it doesn’t appeal to me. But if another engineer does, and uses it extensively, then we have a situation of “because it was easily available, someone did something that makes the rest of us have to stop and pick apart during review/debugging/whatever”.

[solardev]

That is a totally fair and reasonable reply. Thanks for the detailed thoughts!

[frfl]

I kind of worked in a place similar to this. But I think having someone who understands engineering as opposed to just functional programming is important. The codebase I worked on was quite functional, written in TypeScript with libraries like fp-ts, io-ts. It did take a while to figure out some of the things, but ultimately I think the engineer who was leading really understood not to go full pure Haskell-in-JS since others on the team weren't hardcore FP programmers.

[88913527]

How far can this argument be extended? We can go back to vanilla JS/HTML/jQuery; these are all "easy to understand" things. But then too much spaghetti code builds up and then progress grinds down (much like in the Ramda team situation). You need some abstraction and order to maintain consistent productivity levels over the long-term.

[axblount]

I don't think they're arguing against abstractions. Just this one in particular.

[solardev]

I might also argue that sometimes writing the same dumb basic declarative code 20 different times is still faster and easier to read, debug, and maintain than trying to write one master class to handle every possible edge case.

IMO it's one thing if you're writing an engine or library where you have to ensure extremely high quality and good coverage. Or maybe you just work for an incredibly well run outfit where newcomers are deeply trained in the ins and outs of your codebase and style. But no place I've personally worked with has been like that.

If you're just building a bog standard business app for a small or medium business, I don't think purity of code is typically the primary bottleneck. Likely turnover and poor documentation and lack of on-boarding and sudden frequent pivots will be bigger deals, all of which are significantly complicated by over-abstracted code that can't be modularly changed by a single developer.

People worked with vanilla HTML and JS for decades, maybe using server side includes for some basic DRY. It wasn't pretty, it was hecka tedious, but it also wasn't Inception-level nightmarish like some modern abstractions are. There's an ideal level of abstraction for a given team and codebase, IMO, and it's not always "more abstraction is better" (not that you were arguing that). It's just a process of discovery and design by fire that gets you there, not usually a lone genius that produces a masterpiece in any one particular style.

[pygy_]

Ramda is basically a language.

You replace most core JS constructs with higher order functions.

From there stems your observation.

[koolba]

What’s the alternative for functional transforms in redux selectors?

[danenania]

I like immer for this kind of thing: https://github.com/immerjs/immer

You can do immutable transformations without getting bogged down in FP abstractions.

[solardev]

If you use something like redux toolkit query, it already abstracts that for you using Immer internally. You can just write a simple arrow function or use lodash or underscore or whatever pleases you.

https://redux-toolkit.js.org/usage/immer-reducers

[woolly]

I have used lodash/fp successfully in Javascript projects at current and previous job. Not sure about the TypeScript support.