Hacker News Reader

Comment by armchairhacker | Hacker News Reader

Fully functional programming (e.g. Haskell) isn't popular because it isn't ideal and computers work imperatively.

Even in a "functional" task (e.g. compiling) sometimes you just want an imperative algorithm. And while Haskell allows this via state monads, they're clunky.

Meanwhile there's practically no tradeoff to writing functional code in an imperative language. In fact there's lots of functional code in most C++/Java/Python programs. Most "imperative" languages are actually hybrid functional and imperative, supporting "functional" constructs like lambdas and pattern matching.

99% of the time a functional program will get executed sequential and strict anyways. The other 1% of the time, in an imperative language you can explicitly encode functionality (e.g. generic stream operators which work concurrently and on lazy streams).

View on HN

Functional programming absolutely has its use cases, and I love a bit of functional style thrown into imperative language one hundred percent.

That being said, I often end up arguing with 'pure functional programmers' at work - they can be incredibly hard to work with and married to the idea that _everything needs to be functional_ because its their preference, even though your average college student is going to be able to pick up and iterate on code that just uses a damn for loop or whatnot.

I _like_ functional, I find it incredibly useful, but like everything else, its just a tool to solve a problem and there are tradeoffs.

But some of the most annoying and must-do-things-academically-because-look-how-cool-monads-are this-is-the-only-proper-way people are very vocal about functional, which is a pretty big turnoff IMO.

Haskell is a good example. There are totally cases where Haskell will make your life easier. But if you're trying to reinvent the wheel and redefine our architecture by injecting haskell everywhere you can because _you like it_, that drives me absolutely bonkers.

What are the use cases you've seen functional programming in real business?

Precisely modelling the business domain using immutable objects and pure functions is a killer feature of FP for the real world.

https://www.youtube.com/watch?v=yTkzNHF6rMs

Of course this approach requires an impure functional language (so you can have side-effect calls).

I'd imagine one of the more common use cases is data processing.

At my last job I was part of a team that built a data processing platform and we did it in a mostly functional style.

Have you tried to see the pure FP viewpoint, rather than argue?

I have personally been from an FP acolyte and back, there's some great stuff there, it will improve your non-FP code to learn an FP language. That said, bending over backwards to fit the FP mindset is suboptimal, the same way as writing fully OO code is. e.g. IMO some stuff from FP should _generally_ be avoided in favour of making code easier to read and debug - e.g. recursion, maps, monads, generators etc. etc.

"Meanwhile there's practically no tradeoff to writing functional code in an imperative language."

I would have to disagree with you there. It partly depends on what you mean, but I quickly give up on functional solutions in, say, Javascript (despite Javascript technically having all the bits I'd need!) just because of the lack of immutable data structures and cheap copying. Not to mention the constant pain point of asking "does this modify in place, or does it return a new" when dealing even with the standard library, let alone -user- code. I either need a library like Immutable.js, or I need to jump through hoops that are both not ergonomic, AND have performance penalties, or I embrace mutation (and at that point frequently rule out a fully recursive approach because the bookkeeping involved far outweighs any benefit).

Agreed. Constraints (primarily in this context immutability) are invaluable.

Writing functional, immutable style in Python is handy but can be maddening when you never know what to expect from libraries.

> Not to mention the constant pain point of asking "does this modify in place, or does it return a new" when dealing even with the standard library, let alone -user- code

I don’t see how this is a pain point, JS is pass-by-value for primitives and pass-by-reference objects. Ergonomics, sure, but isn’t the lack of pattern matching a much bigger obstacle the lack of immutable semantic sugar?

Immutability is easy to gain, though, just make your variable object writable: false.

Because any recursive algorithm that needs to backtrack requires special care.

That is, let's say I have a sodoku solver. I write a recursive solution wherein I guess the next value on the sudoku board based on the constraints. When an execution path completes and fails to be solved; my board is now populated with that 'bad' state, and I've lost the state I was in prior to the recursive call, at each level of recursion.

I either need to make copies at every step (very unwieldy and inefficient), or explicitly write the 'undo' mechanism for each step. It's doable, but it's extra bookkeeping and logic to keep track of. Whereas immutable data structures give me an ergonomic and reasonably efficient way to maintain the prior state, and to create the next state.

And, the mix of mutation and non-mutation constantly messes with me. Array.concat returns a new array, but Array.push() modifies the array in place. Array.slice returns a new array; Array.splice modifies the array in place. This -constantly- messes with me.

The lack of a feature is just inconvenience that I work around. Having a mix of modalities causes me to trip over myself constantly.

Easy solution: don’t use them, use destructuring.

    // arr.push(item);
    // return arr;
    return […arr, item];

That's a slightly more wieldy way of creating a copy of the array. So still has the inefficiencies. It also is only a syntactical help with adding things onto an array; it doesn't help with removing items.

Why would you worry about low level details for a high level language, optimization is an implementation detail. Javascript in my opinion lends itself functional style programming

Because he cares about his users who might be using his sofware on a smartphone? If you disregard performance completely, your users will either use your app because they have to and hate it or switch to something else if they can.

You also have to focus on the correct performance issues and personally I've never seen writing functional js/ts being the issue.

Define functional js/ts. If it's just "oh, hey, I am using first class functions everywhere" - yes, Javascript is great at that. If it's "I'm writing a bunch of recursive solutions for naturally recursive problems", Javascript is a pretty poor fit for it. You can do it, but it requires extra bookkeeping and care, as I mention on another comment.

I once benchmarked a simple loop, and the same loop done via recursion. The recursive solution was an order of magnitude slower.

> isn't popular because it isn't ideal and computers work imperatively.

Eh, I think it has more to do with tooling and framework support.

Imagine if the world were flipped and C++/Java/Python had zero IDE support, slow compilers, and weird/unreliable build and package management tooling, and only third-party bindings to any platform or framework. And Haskell had incredible IDE support, a fast compiler, great build and package management tooling, and official support for stuff everywhere you wouldn't have to think twice about using in a commercial context.

You'd use Haskell.

There are tradeoffs to writing functional code in langauges designed primarily for imperatively. Another comment mentioned efficiency.

Another is that in a pure language, you can look at a function and know for a fact that nothing you're seeing can ever be mutated. This eliminates a massive source of cognitive load when trying to read and understand code, as well as eliminating all sorts of bugs related to the program being in the wrong state. If you're trying to write functional code in a language not designed for it, you're missing out on those benefits.

Now, it's absolutely the case that the tradeoff may be worth making depending on the person and circumstance. But it does exist.

> Another is that in a pure language, you can look at a function and know for a fact that nothing you're seeing can ever be mutated. This eliminates a massive source of cognitive load when trying to read and understand code, as well as eliminating all sorts of bugs related to the program being in the wrong state. If you're trying to write functional code in a language not designed for it, you're missing out on those benefits.

When you write functional code in imperative languages, these constraints aren't enforced by language, but they should be enforced by convention and code review.

I use F# a lot and like it, but imperative code was problematic to do.

Now using Rust, I think I'm even more functional than ever. One key thing is that I can put a simple loop here and there (inside functions) and still the interfaces are functional.

F# has mutable and while loops also.

I’m surprised you are finding Rust good for functional programming to be honest. It lacks a do-notation system, currying by default and guaranteed tail-call optimisation.

> It lacks a do-notation system, currying by default and guaranteed tail-call optimisation.

And instead gives plain structs with separate impls, traits like Into/From that cut tons of custom-made transformation code, more uniform iterators (in F# some things not implement iterators that other things do, because everyone need to implement again all of them) and other idioms that are very practical.

Is a tradeoff, sure.

Reply on news.ycombinator.com