3 ms·

Stateless functions can save a lot of headaches enabling one to pay more attention to state in fewer places, create good tests and so on.

badpun 4y ago
They're pretty hard to use consistently in languages which aren't accomodating for them though, such as Haskel or Scala. In Java, C++ etc. you can't really program without majority of your functions having side effects - or at least I haven't yet seen anyone doing it.
- adamkl 4y ago
  It’s true that people don’t do it, because of language conventions, but there is no barrier to entry when it comes to writing functions (or methods in these languages) that operate solely as transformations of inputs to outputs. You then orchestrate these “pure” functions with simpler side-effectful methods that handle the external dependencies (data fetching/writing etc). There’s no pushback because of “strange” FP patterns, code looks just like normal imperative code, but the tricky logic can be isolated in pure functions. The push back is only because of the strong OOP conventions.
  - dack 4y ago
    creating and transforming immutable data structures can be a big pain in some languages though, and that's it's own barrier. java is a good example but it's getting better with record types etc
  - badpun 4y ago
    > but the tricky logic can be isolated in pure functions That's not really FP though. In FP, you only have pure functions and not a mix of pure and impure.
    - adamkl 4y ago
      Perfect is the enemy of good. I’ll take any percentage of pure functions that I can get.
agentultra 4y ago
Too true! Having gone through the difficulty of learning what a functor is, what a monoid is, semigroup, monad, etc... I'm better for it. I can see why they're so useful in programming. I can see how they can help me write simple programs. However there was a time when I thought these concepts were complicated and obtuse. I couldn't see their benefit. I'm glad to have relieved myself of such pesky illusions. The problem I'm alluding to is that on a team of developers with mixed levels of experience and backgrounds it is hard work to find consensus in general. If you've gone through the trouble of picking a programming language to work in and you have established that the style of programming will be OO, coming in and suggesting that the style should change to FP is going to be a hard sell. You can tell them about all the benefits... but without having been through the process you won't get good feedback beyond anything superficial or downright ignorant. And if you try to shovel it on them anyway in your little corner of the code you'll risk causing quite a bit of controversy! You can get away with an acceptable amount of functional programming style on most teams these days... but going beyond the ones I mentioned will usually draw such unwanted attention. The other facet of it is that programming in a functional programming style, beyond the very fundamental ideas, in a language that isn't suited for it poses a difficult proposition: you have to maintain the rules yourself. If you break one, use an escape hatch just once, let a bit of something sneak in; you've broken all of your promises and the usefulness of it is gone. In a language designed for functional programming first you don't have to waste this mental energy on ensuring functions are pure, that values are immutable, that equality is maintained, that the laws are preserved, that side-effects are limited to a scope; etc. So definitely, take these ideas from functional programming if they help you write better programs, or help you understand your programs better! If you're not using an FP-first language be aware of the trade offs and difficulties.

badpun 4y ago

They're pretty hard to use consistently in languages which aren't accomodating for them though, such as Haskel or Scala. In Java, C++ etc. you can't really program without majority of your functions having side effects - or at least I haven't yet seen anyone doing it.

adamkl 4y ago
It’s true that people don’t do it, because of language conventions, but there is no barrier to entry when it comes to writing functions (or methods in these languages) that operate solely as transformations of inputs to outputs. You then orchestrate these “pure” functions with simpler side-effectful methods that handle the external dependencies (data fetching/writing etc). There’s no pushback because of “strange” FP patterns, code looks just like normal imperative code, but the tricky logic can be isolated in pure functions. The push back is only because of the strong OOP conventions.
- dack 4y ago
  creating and transforming immutable data structures can be a big pain in some languages though, and that's it's own barrier. java is a good example but it's getting better with record types etc
- badpun 4y ago
  > but the tricky logic can be isolated in pure functions That's not really FP though. In FP, you only have pure functions and not a mix of pure and impure.
  - adamkl 4y ago
    Perfect is the enemy of good. I’ll take any percentage of pure functions that I can get.

agentultra 4y ago

Too true! Having gone through the difficulty of learning what a functor is, what a monoid is, semigroup, monad, etc... I'm better for it. I can see why they're so useful in programming. I can see how they can help me write simple programs. However there was a time when I thought these concepts were complicated and obtuse. I couldn't see their benefit. I'm glad to have relieved myself of such pesky illusions. The problem I'm alluding to is that on a team of developers with mixed levels of experience and backgrounds it is hard work to find consensus in general. If you've gone through the trouble of picking a programming language to work in and you have established that the style of programming will be OO, coming in and suggesting that the style should change to FP is going to be a hard sell. You can tell them about all the benefits... but without having been through the process you won't get good feedback beyond anything superficial or downright ignorant. And if you try to shovel it on them anyway in your little corner of the code you'll risk causing quite a bit of controversy! You can get away with an acceptable amount of functional programming style on most teams these days... but going beyond the ones I mentioned will usually draw such unwanted attention. The other facet of it is that programming in a functional programming style, beyond the very fundamental ideas, in a language that isn't suited for it poses a difficult proposition: you have to maintain the rules yourself. If you break one, use an escape hatch just once, let a bit of something sneak in; you've broken all of your promises and the usefulness of it is gone. In a language designed for functional programming first you don't have to waste this mental energy on ensuring functions are pure, that values are immutable, that equality is maintained, that the laws are preserved, that side-effects are limited to a scope; etc. So definitely, take these ideas from functional programming if they help you write better programs, or help you understand your programs better! If you're not using an FP-first language be aware of the trade offs and difficulties.