Hacker News Reader

Comment by agentultra | Hacker News Reader

It’s hard to do FP in any language that isn’t designed for it. The reason for that is on a reasonably sized team you won’t be able to get consensus on adopting an FP style. There will always be the counter-argument that FP makes the code look weird, unmaintainable, unapproachable etc.

I think the only way to adopt it is to either use a language where it’s the default or get consensus from the team.

Otherwise you can sneak in bits here and there in a functional style, just don’t start implementing monads, functors, and Applicative. Anything beyond map and basic higher-order functions will scare the locals.

View on HN

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.

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.

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.

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

> 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.

Perfect is the enemy of good. I’ll take any percentage of pure functions that I can get.

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.

> It’s hard to do FP in any language that isn’t designed for it.

I don't see why this is true, and perhaps it's because I don't have a full enough concept of functional programming.

In any language, why can't we write functions that don't modify the arguments, offer the same return for the same arguments, and modify no internal state when called? And then compose those functions together to form a full working program?

You quoted only part of the comment, it mentioned that some basic techniques can be applied but most of the intermediate-to-advanced FP patterns should not.

> In any language, why can't we write functions that don't modify the arguments, offer the same return for the same arguments, and modify no internal state when called? And then compose those functions together to form a full working program?

Here here. I am consistently baffled as to why this approach and OOP are apparently mutually exclusive, and why functional programming must be more than the approach quoted here.

Functions/methods as small/deterministic as they can be, judicious type checking, separation of concerns...maybe I'm dumb and/or inexperienced, but this approach seems perfectly fine to me, at least for the domains in which I work.

They're not mutually exclusive!

OCaml has an OOP system in place. C++ has lambdas, some "monads," etc. You can do functional programming in C#, TypeScript, even Java these days. People have even written libraries in Haskell that let you do OOP if you want.

Jack of all trades, master of none, is how I think of it. It becomes complicated trying to be a language that appeases all programmers. The C++ specifications, ECMAScript, etc are all enormous.

The Haskell 2010 report is quite small by comparison. The R6RS specification is smaller. When you have fewer things to consider and a smaller audience to appease you can do a whole lot more with much less.

When you go all in with a language that is built on functional programming principles first and foremost, you end up with a very different language than if you start with procedures and statements. You can emulate functional programming in C but it requires discipline and you don't get any feedback from the type system, compiler, or tools unless you write them yourself. When you write code in Haskell you get all kinds of feedback and the mental energy you used to spend on discipline can be used elsewhere.

> Otherwise you can sneak in bits here and there in a functional style, just don’t start implementing monads, functors, and Applicative. Anything beyond map and basic higher-order functions will scare the locals.

10 years ago you would have said the same thing about map and those "basic higher-order functions" that you say about monads, functors, and applicative.

It's a slow process. Haskell, OCaml, friends, ancestors, and descendants have been the inspiration for plenty of language features in the mainstream. When their programs get hard to write and maintain they reluctantly pluck from the fruit of functional programming.

PHP has this https://github.com/lstrojny/functional-php

Reply on news.ycombinator.com