4 ms·

Question to all the functional programming experts: When OOP got introduced people started building all these elaborate object hierarchies and design patterns o

Question to all the functional programming experts: When OOP got introduced people started building all these elaborate object hierarchies and design patterns only to find out after a while that simpler is better and most features should be used rarely or never. Is there also a risk with FP too that people fall a little too much in love with “elegant” code only to find out later that maybe simpler is better? Reading some people writing about FP I feel there is some risk of people doing this.

jolux 6y ago
Generally in FP, “elegant” == simpler.
- searchableguy 6y ago
  On that, I have seen lot of TypeFunctorMapMutatorKeywordsBeingImported to shorten the code and make it elegant...of course from the standard library or modules. When you could have written it yourself with one or two extra lines. Why? Is it simpler? Or is it unnecessarily abstracted?
  - jolux 6y ago
    I mean, that’s on a case by case basis. I personally tend to do most of my FP in OCaml and F#, which have less of the tendency towards infinite abstraction that people sometimes accuse Haskell programmers of. I don’t think the approach you describe is elegant, but this is highly subjective.
  - chowells 6y ago
    1. It's code reuse. Don't rewrite code that's already written. 2. It's harder to understand. "Why didn't this use the standard library function? Is it doing something different? It doesn't look like it, am I missing something?"
    - jolux 6y ago
      It’s definitely not _always_ just about code reuse, particularly when you start really stacking GHC pragmas and such.
mywittyname 6y ago
I've outsmarted my future-self on several occasions. So yeah, there's a risk.
yodsanklai 6y ago
> Is there also a risk with FP too that people fall a little too much in love with “elegant” code only to find out later that maybe simpler is better I know some functional programmers who write complex code because they want to use the latest features of the type system. They get additional type safety, or better code factorization, but it results in code that is very hard to read and maintain, especially for people not as skilled as the initial programmer.
bojo 6y ago
There's been a "simpler is better" conversation bouncing around the FP community as well lately. Jumping on all the shiny-new-feature bandwagons that makes code drift towards unnecessary complexity, even if it technically makes things "better" given some sort of objective context, is something a team working with these languages really needs to consider.
slaymaker1907 6y ago
The two that I can personally thing of are using higher order functions unnecessarily (i.e. sometimes it is better just to use a boolean flag rather than handing in a callback) and too much indirection (though honestly I see this more in languages like Java than functional languages).

jolux 6y ago

Generally in FP, “elegant” == simpler.

searchableguy 6y ago
On that, I have seen lot of TypeFunctorMapMutatorKeywordsBeingImported to shorten the code and make it elegant...of course from the standard library or modules. When you could have written it yourself with one or two extra lines. Why? Is it simpler? Or is it unnecessarily abstracted?
- jolux 6y ago
  I mean, that’s on a case by case basis. I personally tend to do most of my FP in OCaml and F#, which have less of the tendency towards infinite abstraction that people sometimes accuse Haskell programmers of. I don’t think the approach you describe is elegant, but this is highly subjective.
- chowells 6y ago
  1. It's code reuse. Don't rewrite code that's already written. 2. It's harder to understand. "Why didn't this use the standard library function? Is it doing something different? It doesn't look like it, am I missing something?"
  - jolux 6y ago
    It’s definitely not _always_ just about code reuse, particularly when you start really stacking GHC pragmas and such.

mywittyname 6y ago

I've outsmarted my future-self on several occasions. So yeah, there's a risk.

yodsanklai 6y ago

> Is there also a risk with FP too that people fall a little too much in love with “elegant” code only to find out later that maybe simpler is better I know some functional programmers who write complex code because they want to use the latest features of the type system. They get additional type safety, or better code factorization, but it results in code that is very hard to read and maintain, especially for people not as skilled as the initial programmer.

bojo 6y ago

There's been a "simpler is better" conversation bouncing around the FP community as well lately. Jumping on all the shiny-new-feature bandwagons that makes code drift towards unnecessary complexity, even if it technically makes things "better" given some sort of objective context, is something a team working with these languages really needs to consider.

slaymaker1907 6y ago

The two that I can personally thing of are using higher order functions unnecessarily (i.e. sometimes it is better just to use a boolean flag rather than handing in a callback) and too much indirection (though honestly I see this more in languages like Java than functional languages).