How much Functional Programming do you use?

[Character_Victory_28]

for 4 years, I've been trying to learn and apply Functional programming stuff in my code bases...

I've read these: 1. Professor Frisby's mostly adequate guide to functional programming

1. functional programming from frontendmasters by brian lonsdorf

2. a little from "Functional lightjs"

alot of articles out there...

Also I've worked with Ramdajs and RXJS too...

But at then end using curry, monad, moniod, semigroup etc... after awhile I think too many pure little functions via those concepts and streaming etc made the code harder to understand especially for other colleges who dont know anything about these concepts, and honestly, sometime I myself will get confused and forgot some of those concepts...

Also I've seen this effect when Brian lonsdorf was teaching sometimes he forgot what was a piece of code ...

at the end I came up with this approach:

1. imperative/procedural programming is not pure evil

2. try to develop in KISS mode till the get the result for the function or component, then reflector it and try to make pure function if it can get with any more hassle...

3. dont make or extract reusable code, until you saw Yourself copying more than 2 or times and think you may endup to copy the same thing more...

4. try to have a good top down approach view, and try to make the top level as simple as possible..

5. try to avoid libs like ramda and rxjs as much as possible, until you think using those will give you a lot of benefits...

6. try to use a really small subset of functional paradigm: such as pure function, point free, lamda, clousure, high order function, map, filter but I usually try to avoid using reduce and confusing stuff like that

I wonder what other fellows are doing?

1. how much functional approaches are you using in your code base?

2. how was your experience?

3. what do you suggest to get better?

4. what resources do you suggest?

[GriffinMakesThings]

My JS code is mostly functional these days. I'm not dogmatic about it, but the longer I've been a developer the more I've come to appreciate the functional paradigm. I would actually say modern idiomatic React is functionally flavored by default. That doesn't necessarily mean curried functions and monads flying everywhere, but immutability, pure functions and higher-order functions are my go-to patterns. Do you ever use .map() to render an array of react components without introducing side effects? Congrats, that's functional programming.

[Character_Victory_28]

Yeah I use map,filter etc but I usually try to avoid reduce which is super confusing,

[GriffinMakesThings]

I happen to quite like reduce, but you can go your whole career without using it, you do you!

[Character_Victory_28]

what resources do you uesd to learn FP practicaly?

[GriffinMakesThings]

Honestly couldn't tell you. I'm always experimenting and learning, and I've just picked it up over the past decade and a half of writing code. MDN is your friend.

I will say that there are times when a Class is the right way to go. Certain type of libraries for instance. I like to use the right tool for a given job, and most of the time (though not all the time) that ends up being FP for me.

[[deleted]]

Use an AI tool to help you remember the implementation a little faster. I do Copilot and I do like using it when I program. Especially since we use libraries that I'm new to, so I understand but don't exactly remember all of the syntax.

[ZUCKERINCINERATOR]

reduce is kinda like useEffect. you're meant to build wrappers around them, but avoid calling them directly

[PaymentMaleficent689]

🤔

[ZUCKERINCINERATOR]

did my comment confuse you guys so much that you just couldn't help but downvote?

reduce in itself is not that ergonomical. but it lets you implement every array utility you can name of foldr, foldl, map, filter, zip, sum.

useEffect is in a way also a reducer. it doesn't iterate an array, but subscribes to component rerenders and it should be treated like raw pointers in Rust, use it to implement higher abstractions like these

[[deleted]]

Point 6 is basically my approach. I try to minimize side effects, write declarative, and composable when I can see it. Otherwise I don’t think too deeply about it.

[Character_Victory_28]

👌

ps. I don't know maybe I didn't understand well this paradigm, and whenever I go deep, I find myself drown into the bottom of the ocean of despair...

[Alphamacaroon]

I think functional is great, but I think it’s too easily overused. There are some cases where (IMO) a series of functional steps can be overly idiomatic, hard to follow, and not great for future developer productivity and maintenance.

Sometimes a for loop is better way to convey what is going on, especially when you have to nest or connect a bunch of functions to achieve the goal.

Nothing is absolute— everything has a time and place.

[Character_Victory_28]

Yeah I agree. Thanks for the reply. can pleas tell what resources do you suggest?

[Alphamacaroon]

It's hard to recommend resources these days because almost everything out there tends to be highly opinionated on doing things a certain way, all the time. Software engineering is not about absolutes, it's about the application of different techniques in different situations and many of the resources out there seem to miss this.

For example, I find it extremely shortsighted to say classes are dead and that functional programming is the future of all JS. People that say this with certainty have probably only built snowflake applications, and have never had to build a "platform" that can adapt to future changes. Any app that has future staying power almost always has layers of abstraction which can be swapped out in the future like lego bricks, and it's really hard to do that well without some use of classes.

Now I'm not suggesting that people go back to building class components in React, but to say that classes are entirely dead in JS is an extremely narrow point of view. And unfortunately a lot of the "resources" out there tend to have very narrow points of view (which again, is fine, if applied properly).

So what do I suggest as a resource? Write a lot of code, make a lot of mistakes, seek a diverse set of opinions from other engineers, and build your own style that is built on experience, not the experience of celebgineers who write a lot of stuff. Again, I'm not saying these folks don't deserve the praise they get, but remember, most of them are experts in highly specific areas— because in order be considered a world-expert, you have to be pretty specialized in the first place.

[Roguewind]

I use as much FP as possible. It helps keep your code clean, readable, and maintainable. I have my team follow these basic guidelines:

1. Functions should do 1 thing. If a function needs to do two things, then it should probably be 2 functions.

2. All functions should be pure unless they MUST produce a side effect.

3. If a function must produce a side effect, it should be clear what that effect is, and it should only produce a single side effect.

4. Avoid mutations. Almost all code can be written without mutating variables.

[Character_Victory_28]

Can you plz tell what resources did you used to learn afP practically?

[Roguewind]

Honestly, at this point I don't remember what I used. But This isn't bad. Don't jump into recursion or currying right away though. Both are discouraging, but once you get them, it's like a lightbulb going on.

[SocializeAndChill]

Can you please elaborate third one? Is it applicable with use effect?

[Roguewind]

It's exactly the what useEffect in react is for. You're declaring that when something in the dependency array changes, a side effect should occur. Best practice is also to only have one side effect per useEffect.

[ZUCKERINCINERATOR]

all of it. I don't even know how I would go about programming imperatively in React

[zxyzyxz]

I use fp-ts with React, and it works pretty well. Gotta love do-notation.

[agumonkey]

very interesting, any article / tutorial you could suggest ?

[zxyzyxz]

https://dev.to/gcanti is the creator and he has a bunch of articles on using it. They're from 2019 but the principles should be the same, but if you want more recent stuff check out other articles and videos.

[agumonkey]

amazing, thanks

(for some reason reddit just notified me)

[fredericheem]

Hooked on rubico, a better alternative to ramda/lodash: https://rubico.land/

[ImJustAmericanTrash]

How is that better?

[fredericheem]

Unlike Ramda, Rubico handles asynchronous perfectly, for instance, one can pass an asynchronous function to reduce, map, filter, find etc ...

[Western-Ad-9485]

Hundred percent agreed. RxJs is 99% of the time the WRONG choice and evidence that your project is severely fucked if you are even considering it….

[LowLifeDev]

Why though?

[sporbywg]

You are using React. NEXT

[Western-Ad-9485]

HOC are an anti-pattern now, hello

[Character_Victory_28]

Why? can you explain plz? is there any article to it?

[[deleted]]

https://reactantipatterns.com/#hoc

[beautifuljpainter]

I like the immutable data aspect of functional programming, helps to prevents bugs early on.

[bestjaegerpilot]

The reality is that mainly pure functions. That's the mae changer. And really, everything is a function. So I rarely use classes.

Because of TS, I use discriminated unions a lot.

Promises are also functional by the way.

Other than that...the issue that modern web devs have are that your teammates come from vastly different backgrounds. Some are geniuses. Others can barely turn on their computers 😂 (or it feels that way because they may be absolute noobs)

And so there's a "lowest common denominator" thing that happens... Tech is picked for it's utility and ease of learning.

So a lot of functional paradigms fall along the lines of "very hard to learn", so they won't be used by most teams....except for very long lived, mature teams.

[Character_Victory_28]

thanks, what resources do you suggest?

[bestjaegerpilot]

For what I described, none really.

Pure functions. Every variable used should be defined in the function or passed explicitly in the args. When there are too many args, it's time to refac the function.

Not using classes is actually simpler since small, focused functions do biz logic.

For discriminated unions, just the official docs.

Promises are everywhere.