3 ms·

My problem with functional programming is refactoring. If you don't have side effects when you want to do 2 things deep into the call tree to something that is

by ajuc 4y ago

My problem with functional programming is refactoring. If you don't have side effects when you want to do 2 things deep into the call tree to something that is in completely different call tree branch - you have to extract it all the way up to the common parent and pass it through all the intermediates just so that one function deep there can access it. It's incredibly frustrating when you work in a functional language, and yet it's the main benefit (no side effects). I'd like to have a language that is imperative when written and functional when read :)

mejutoco 4y ago
> I'd like to have a language that is imperative when written and functional when read :) Depending on which language Monads give you exactly that bridge between imperative and functional. In your example, you can always choose to have side effects in that deep call. Personally, I like a type-driven approach. Then, I do not care so much where functions are (they will be grouped logically, but could be anywhere), as long as the type in and the type out matches.
iterati 4y ago
I've handled this (in Clojure) either by passing a context map through the entire stack or binding some context atom at the top and using it lower down the stack. The binding is less obvious at first glance, so I prefer to pass the context, but both make testing quite easy and reduce the need for heavy refactoring.
beders 4y ago
I like that aspect because it gives you a hint that your call tree is not how it should be. Lifting out side-effects and passing the data back in is one approach, but not the only one. Turning a deep call tree into a flat pipeline is a popular other approach and often leads to less complexity, better compos-ability.
- ajuc 4y ago
  I like it when I'm done. I very much dislike it when I'm not sure yet what my code should do so it changes constantly. And that's most of the time in gamedev for example.

by ajuc 4y ago

mejutoco 4y ago

> I'd like to have a language that is imperative when written and functional when read :) Depending on which language Monads give you exactly that bridge between imperative and functional. In your example, you can always choose to have side effects in that deep call. Personally, I like a type-driven approach. Then, I do not care so much where functions are (they will be grouped logically, but could be anywhere), as long as the type in and the type out matches.

iterati 4y ago

I've handled this (in Clojure) either by passing a context map through the entire stack or binding some context atom at the top and using it lower down the stack. The binding is less obvious at first glance, so I prefer to pass the context, but both make testing quite easy and reduce the need for heavy refactoring.

beders 4y ago

I like that aspect because it gives you a hint that your call tree is not how it should be. Lifting out side-effects and passing the data back in is one approach, but not the only one. Turning a deep call tree into a flat pipeline is a popular other approach and often leads to less complexity, better compos-ability.

ajuc 4y ago
I like it when I'm done. I very much dislike it when I'm not sure yet what my code should do so it changes constantly. And that's most of the time in gamedev for example.