4 ms·

I think shoehorning fp onto go just results in people having a wrong first impression of fp, damaging them for years or forever. fp is so much more than map, fi

by eska 2y ago

I think shoehorning fp onto go just results in people having a wrong first impression of fp, damaging them for years or forever. fp is so much more than map, filter and reduce.

xelamonster 2y ago
I agree, but I also appreciate this because missing map/filter/reduce is probably my biggest pain point when writing Go. Nested for loops and explicit filters are so ugly and hard to read, for me that alone undoes any of the appeal of the language's "simplicity".
- ljm 2y ago
  I'm only partly convinced that bringing functional abstractions to various kinds of collections/iterators/enumerators, etc. adds value to Go, both in terms of reading code and writing it. That's pretty much as far as 'functional programming' goes when this topic comes up. It brings Java libraries like vavr to mind. The concept has appeal if you appreciate the aesthetics of functional programming but your codebase will be filled with places where you have to convert between the sexy functional style and the boring shit in order to get anything done. It's better to just roll with the language and stick to where it excels. It may not be as easy on the eyes and it may also be boring to write, but a lot less can go wrong with it.
eyelidlessness 2y ago
I can’t speak to Go, but I encounter this attitude in other languages where I have more experience. In one particular case, TypeScript, I have quite a bit of experience “shoehorning” FP to very good results. I find the attitude tiresome. Sure, in an abstract sense, there’s “more” to FP than these common abstractions. But there’s also less: FP is ultimately about acting on values. The “functional” part is an acknowledgment that a “function”, in its mathematical sense, is the common abstraction which achieves that. Map/filter/reduce are no more fundamental to that than any of the typical academic concepts often found in ML-family languages. Nor, as a detractor on Twitter suggested to me recently, are persistent data structures essential. Values are the essential concept, and all else that FP offers are in service of that concept. You can apply the same principles in nearly any language. You may need to build up your own implementation of some common abstractions to benefit from them. You may find certain patterns inherently awkward due to language semantics, or sometimes just syntax. Ultimately it’s still rewarding, from the perspective that one will be using said non-FP-paradigm language anyway. Because working with values is its own reward. And it’s incredibly rewarding, even if limited. I don’t think it does anyone any good to gatekeep that on the basis that the compromise… is a compromise. Sure, it’s worth pointing out that there are limited benefits. But none, in my experience, so limited that they negate the benefit entirely.
fellowniusmonk 2y ago
I worked with a group that basically elixir-fide typescript for the frontend and ruby for the backend. It was insanely slow and unintrospectable, to get elixir syntax for ruby they had to abuse blocks horribly, refactoring was decent for already existing components but as an org they had the slowest ruby "new feature" development I've ever seen in 20 years. Don't throw away all your debugging and IDE tools just to shoehorn a different language paradigm into your existing codebase, if you can prove to me that you have put co-commiserate effort into the tooling and can actually demonstrate this fact practically then you are good but probably still wasting time and should switch to elixir/f# or whatever. This group hired me because I was the only outside senior level person that was a rubyist and an elixir guy with a lot of FP work in the data space willing to give them a shot (fp is good, it's a good tool but not a panacea, fp is borderline an academic cargo cult nerd snipe in how people proselytize and get into it imo) and I was at a career point where I was doing a lot of exploratory stuff so I found them intriguing since they did have a real product in prod. In my interview process, I didn't vet their actual dev process nearly enough, total waste of time for people who want to do product development with any velocity.

by eska 2y ago

I think shoehorning fp onto go just results in people having a wrong first impression of fp, damaging them for years or forever. fp is so much more than map, filter and reduce.

xelamonster 2y ago

I agree, but I also appreciate this because missing map/filter/reduce is probably my biggest pain point when writing Go. Nested for loops and explicit filters are so ugly and hard to read, for me that alone undoes any of the appeal of the language's "simplicity".

ljm 2y ago
I'm only partly convinced that bringing functional abstractions to various kinds of collections/iterators/enumerators, etc. adds value to Go, both in terms of reading code and writing it. That's pretty much as far as 'functional programming' goes when this topic comes up. It brings Java libraries like vavr to mind. The concept has appeal if you appreciate the aesthetics of functional programming but your codebase will be filled with places where you have to convert between the sexy functional style and the boring shit in order to get anything done. It's better to just roll with the language and stick to where it excels. It may not be as easy on the eyes and it may also be boring to write, but a lot less can go wrong with it.

eyelidlessness 2y ago

I can’t speak to Go, but I encounter this attitude in other languages where I have more experience. In one particular case, TypeScript, I have quite a bit of experience “shoehorning” FP to very good results. I find the attitude tiresome. Sure, in an abstract sense, there’s “more” to FP than these common abstractions. But there’s also less: FP is ultimately about acting on values. The “functional” part is an acknowledgment that a “function”, in its mathematical sense, is the common abstraction which achieves that. Map/filter/reduce are no more fundamental to that than any of the typical academic concepts often found in ML-family languages. Nor, as a detractor on Twitter suggested to me recently, are persistent data structures essential. Values are the essential concept, and all else that FP offers are in service of that concept. You can apply the same principles in nearly any language. You may need to build up your own implementation of some common abstractions to benefit from them. You may find certain patterns inherently awkward due to language semantics, or sometimes just syntax. Ultimately it’s still rewarding, from the perspective that one will be using said non-FP-paradigm language anyway. Because working with values is its own reward. And it’s incredibly rewarding, even if limited. I don’t think it does anyone any good to gatekeep that on the basis that the compromise… is a compromise. Sure, it’s worth pointing out that there are limited benefits. But none, in my experience, so limited that they negate the benefit entirely.

fellowniusmonk 2y ago

I worked with a group that basically elixir-fide typescript for the frontend and ruby for the backend. It was insanely slow and unintrospectable, to get elixir syntax for ruby they had to abuse blocks horribly, refactoring was decent for already existing components but as an org they had the slowest ruby "new feature" development I've ever seen in 20 years. Don't throw away all your debugging and IDE tools just to shoehorn a different language paradigm into your existing codebase, if you can prove to me that you have put co-commiserate effort into the tooling and can actually demonstrate this fact practically then you are good but probably still wasting time and should switch to elixir/f# or whatever. This group hired me because I was the only outside senior level person that was a rubyist and an elixir guy with a lot of FP work in the data space willing to give them a shot (fp is good, it's a good tool but not a panacea, fp is borderline an academic cargo cult nerd snipe in how people proselytize and get into it imo) and I was at a career point where I was doing a lot of exploratory stuff so I found them intriguing since they did have a real product in prod. In my interview process, I didn't vet their actual dev process nearly enough, total waste of time for people who want to do product development with any velocity.