Functional Programming – How and Why

Re:Functional Programming – How and Why by mckravchyk on Monday January 02, 2023 @06:55AM (#34216976)

I was trying to evaluate FP one time, try to get it, but I can't envision using it in a pretty complex front-end where many things inter-depend on each other. With imperative programming I can easily step through the code and reason about the flow of execution, looking at FP, I can't help but think the codebase would become very hard to reason about and extend. Side effects are inevitable so if you are going to have side effects in a monad, what's the point anyway, one way or another you have side effects. Unit tests may be easier, but it's still trivial to do mocks. Mutability? I'm using a custom map type for global state entities that helps me deal with it and I'm also very mindful whenever I assign anything to an object property (in JS).

I respect FP, but I don't envision using it personally, and by the way, I don't get how OOP is getting bashed on HN so much. Like google FP + HackerNews and there are articles about FP like this one, google OOP + HN and you get "OOP is not just bad, it's super-duper-hyper-ultra atrocious".

[ Parent | on HN ]

Re:Functional Programming – How and Why by valcron1000 on Monday January 02, 2023 @07:46AM (#34217343)

I suggest trying to build an app using Angular and just observables to handle all state + interactions. In my experience, it's the best way to build an UI where "many things "inter-depend on each other". It's on a whole other level compared to using React with `[name, setName] = useState("")`

[ Parent | on HN ]

Re:Functional Programming – How and Why by kephasp on Monday January 02, 2023 @08:11AM (#34217491)

My team builds frontends in Elm and backends in Haskell and we experience the opposite: FP made the code very easy to reason about and plugging things together is easy too.

[ Parent | on HN ]

Re:Functional Programming – How and Why by consilient on Monday January 02, 2023 @11:31AM (#34219808)

> Side effects are inevitable so if you are going to have side effects in a monad, what's the point anyway, one way or another you have side effects.

Imagine a style of programming where everything is assumed to be asynchronous, all the way down to language primitives. Someone who only ever wrote AsyncScript would look at TypeScript, say "Requests are inevitable, you're always going to end up in async/await anyway, so what's the point?"

This is exactly the relationship between imperative and pure-functional programming: the point of having explicit effect monads (or some other tracking system) is that it makes it possible to write code that isn't in them.

[ Parent | on HN ]

Re:Functional Programming – How and Why by mckravchyk on Monday January 02, 2023 @11:50AM (#34220109)

I agree, I missed the point. Come to think of it, this is probably the biggest advantage of functional over OOP.

[ Parent | on HN ]

Re:Functional Programming – How and Why by mhuffman on Monday January 02, 2023 @05:22PM (#34224510)

> I don't get how OOP is getting bashed on HN so much.

I think a lot of the OOP bashing comes from soooooo much bad OOP code out there (I'm looking at you "enterprise JAVA")!

This is also the reason some people have a bad taste in their mouths about other things: PHP, JavaScript library hell, etc.

[ Parent | on HN ]

Re:Functional Programming – How and Why by mckravchyk on Tuesday January 03, 2023 @12:12AM (#34227957)

I did try to evaluate again and I think the biggest deal breaker that would prevent me from using it is the added complexity and boilerplate. That impression is definitely amplified be me not having practical experience with it, nevertheless, it's plenty more code to do the same thing and extra effort to split the side effects from pure operations, going out of your way to make the data processing pure, which adds boilerplate to the code and also some runtime overhead as well. Imperative feels like the shortest distance between 2 points.

I feel like I would be more likely to get burned by the above point (complexity and boilerplate) vs. a mutated state bug or a "gorilla is holding the banana" problem, especially considering that the former is an ongoing effort and the latter is things you only need to deal with at times, if ever.

[ Parent | on HN ]