Ask HN: When is pure functional programming beneficial?

Systems that have clear inputs and outputs. Parsers, compilers, stuff like that. SAT Solvers. Anything you could unit test without mock objects.

Mixed initiative systems (say UI code where you call into the framework and the framework calls into you) can go either way. Sometimes you can formulate the part of your code in a pure functional way which tames the chaos, if you can’t or that formulation is unnatural the chaos tames you.

System w/ immutable data structures lose a factor of two or so in performance in some cases. FORTRAN programmers won’t accept them, distributed “big data” systems will spend a lot of time marshaling and unmarshaling data and won’t accept any slowdown in their parsing code. The same could be true for something like that SAT solver.

  -module('fib').
  -export([go/1]).


  go(N) when N < 1 -> throw(badarg);
  go(N) ->
        Sqrt5 = math:sqrt(5),
        round(1.0 / Sqrt5 * math:pow((1 + Sqrt5) / 2.0, N) - 1.0 / Sqrt5 * math:pow((1 - Sqrt5) / 2.0, N)).

  rp(lists:map(fun fib:go/1, lists:seq(1, 71))).
  [1,1,2,3,5,8,13,21,34,55,89,144,233,377,610,987,1597,2584,
 4181,6765,10946,17711,28657,46368,75025,121393,196418,
 317811,514229,832040,1346269,2178309,3524578,5702887,
 9227465,14930352,24157817,39088169,63245986,102334155,
 165580141,267914296,433494437,701408733,1134903170,
 1836311903,2971215073,4807526976,7778742049,12586269025,
 20365011074,32951280099,53316291173,86267571272,
 139583862445,225851433717,365435296162,591286729879,
 956722026041,1548008755920,2504730781961,4052739537881,
 6557470319842,10610209857723,17167680177565,27777890035288,
 44945570212853,72723460248141,117669030460994,
 190392490709135,308061521170130]

    function triangle(n) {
        if (n <= 1) {
            return [1]
        }

        const p = triangle(n - 1)
        return Array.from({ length: n })
            .map((_, i) => (p[i - 1] ?? 0) + (p[i] ?? 0))
    }

   def query(parameters):
      encoded_parameters = encode_parameter(parameters)
      url = generate_rest_url(configuration, parameters)
      response = do_post(url, encoded_parameters)
      return decode_response(response)

[dead]

I consider taste a benefit, regardless of what your taste may be. There’s other things to weight, too, of course! But if the end result is that you enjoyed your time more than you would have if you were slinging Java, that’s not without merit.

Functional programming enables local reasoning about your program: since effectful code is clearly signaled with various monads, you can be sure that some pure code is such just by looking at the type. This lets me think less about the surrounding context do you understand a given block of code.

So, I would say the advantage of a pure functional programming language is that it enforces and encourages writing pure code. You can still write in the style to some degree in python, but you don’t get all of the idioms language support to make functional programming really nice.

I notice a difference in my code when I write in a pure language.

There are some cases where you really want in place mutation— graph algorithms are good example—but for most other things, I feel like functional programming wins because of how you can think about your code, and less about code actually can or cannot do.

a Haskell program is the same as a Python program

  Beware of the Turing tar-pit 
  in which everything is possible 
  but nothing of interest is easy.
      -- Perlis:54

https://web.archive.org/web/20120806032011/http://pu.inf.uni...

Haskell is syntactic sugar on top of the Von Neumann architecture (likewise Python, Rust, COBOL, Smalltalk, etc.)

The Von Neumann architecture is inherently stateful. Anything with volatile memory is.

Functional programming is an idiom, not a technology. To the degree functional programming is a technology, it is one for analog computers.

Good luck. My time has been wasted trying to be clever.

You can write a confusing unreadable Haskell script, just like you can write a confusing unreadable Python script. There’s nothing magic about functional paradigm programming.

It does, IMO, give you less foot guns related to state though. While I still actually like other paradigms, functional programming really limits how clever you can be with state. You can only pass things around immutability via parameters (At least with Haskell specifically) instead of making a confusing taxonomy of objects with unique APIs, for example.

Mutable State is to Software as Moving Parts are to Hardware :-)

https://kristiandupont.medium.com/mutable-state-is-to-softwa...

I find personally that there are some areas where FP shines -- anything that is or could be a CLI that takes some input and returns some other output is well suited. A GUI program is the manipulation of state, and it is poorly suited, though many sub parts might not be.

Systems where you need to prove correctness at least informally. It’s much easier to prove correctness of a functional program than imperative one.

It's all about minimizing cognitive overhead. This happens in a few ways when you use strict functional patterns and a tight domain model:

- You can safely make more assumptions about how your program works - You can rely on your type checker like a to-do list when extending your program

These two benefits require more discipline, but they make extension and support brain-dead easy.

For the record, you don't need Haskell to enjoy these benefits, you can get them in Python or TypeScript too, as long as you're disciplined in how you design your system.

I think the issue isn't for the most part the kind of problem the code addresses, but the social context in which the code is used. Functional programs can allow for easier reasoning about programs or paths later, which can be useful when updating, refactoring, debugging etc.

Are you _literally_ writing a simple script to do a single task which you won't save into version control? Pick whatever style will be fastest to write + run. But if you'll need to re-read it in 6 months to figure out how to re-use a portion in a different context, or the next engineer will need to migrate something out from under it in a year, or whatever else, then picking a style based on readability, testability, and analyzability can be worth it -- provided the rest of your team is on the same page.

Purely functional programming in package management and system configurations is next-level.[0] When your package installation scripts no longer are represented as actions from one state to another but as a state that is either realized completely or not, things become a lot more deterministic, manageable, and compositional. In Nix, a package is a pure function that takes in inputs and produces outputs. Given the same inputs, we have the same outputs, and so caching becomes easy, for instance, along with extensive sharing.

As an active user and package maintainer I can't count the number of times I've decided to rebuild an old project that I haven't touched in years and it still working, while in the same session working on another project using up to date libraries.

There's also straight.el for Emacs[1] which has finally made Emacs config maintenance far better for me.

[0] https://nixos.org/

[1] https://github.com/radian-software/straight.el

When you parse something instead of validation.

I wouldn't say there is any threshold where purely functional programming shines less. Fewer regressions and the system being more likely to "just work" makes it more fun to develop. So for interactive programs, servers, CLI tools, parsers et.c. purely functional programming is amazing. An elm developer reported that the prototype they wrote in elm ended up with less bugs than the actual production system. I personally experienced building a system and after I had written a few thousand lines, fixed all compiler errors and then it compiled and was just... done. No bugs where found in production.

In F#, an experience report came out where 350k lines of C# were rewritten in 30K of F# code. They also went from 3k null checks to 15 lines of null checks (Plus much more). Zero bugs were reported in the newly deployed system.[0]

Now with that said, there are exceptions where purely functional programming languages shines less:

- Places where the ecosystem is not quite as mature. If you're building a server and have to interact with Cloud services in Haskell, you'll have a bad time.

- Any kind of system where you need to do manual memory management, so systems programming, is badly suited for purely functional programming.

[0] https://www.youtube.com/watch?v=MGLxyyTF3OM&t=863s

There is probably as much value in just disciplining yourself to try and write mostly in pure functions (regardless of language - I'd recommend Javascript or Typescript as it is a joy to use and highly expressive).

This has benefits when working in large, long-lived systems where engineers can't keep everything in their head, and people come and go over the years. It is easier to reason about, to refactor, and to test, when you know that the "blast radius" of your function is just the return value.

Structure and Interpretation of Computer Programs section 3.1, Assignment and Local State, gives an overview of the costs and benefits of adding the concept of mutation to an otherwise referentially transparent language. It's from the opposite perspective: we know functional programming, now what's so great and so dangerous about imperative?

http://sarabander.github.io/sicp/html/3_002e1.xhtml

It's nice to have things pure-by-default; and sprinkle in whatever effects, etc. as desired. (Like Haskell, Idris, Agda, etc.)

For example, I've worked on a lot of Scala code which represented optional values using `Option[T]` (~= Haskell's `Maybe t`); represented possible failures using `Try[T]` (~= `Either Exception t`); and I even used the Cats library to make code polymorphic (i.e. for all `M: Monad`, or `M: MonadThrow`, or indeed `Applicative`, etc.). The older ScalaZ library is a popular alternative to Cats which does similar things. Concurrency is currently quite diverse in Scala: we mostly used `Future[T]`, but there are a bunch of alternatives out there like `Task`, etc. Likewise there are other Scala libraries/frameworks which model side-effects differently, e.g. Zio uses algebraic effects.

However, since Scala is not pure by default, we can't count on any of these fancy types to actually prevent the problems they're meant to address. For example, we can only use `Option` alongside `null`: the latter can't be avoided, since Scala isn't pure; in fact `Option` should technically introduce even more null checks (since `x: Int` might be `null`; but `y: Option[Int]` might be `null` or `Just(null)`!). Likewise, `Try` can only be introduced alongside the possibility of any exception being thrown at any time. And so on.

In contrast, we might have a project e.g. in Haskell, where `IO` appears in all of our types. Such code might use all sorts of confusing effects (e.g. early returns, mutable variables, concurrency, etc.), and may blow up in all sorts of ways, just like Scala, Python, etc. Yet at least they're labelled as such, and we're able to write other values and functions which actually do what they claim (modulo totality, unless we're using Idris, Agda, etc.).

Consider your program a model of the problem that you are automating. Depending on what you are modeling, different paradigms and styles of program will help in different ways.

What we call functional programming today is often reducing the problem down to the easy parts. Which is great and should not be discounted. But don't think of it as any more valid of a solution than anything else. And pure numerical models of the problem can often be just as fruitful in solution speed, while being utterly foreign to most programmers.

OO gets lambasted as you try and model each individual thing in a problem. In my mind rightfully so. That said, it is very common for us to model things in a way that is very "object" based. Consider the classic model of an elevator system and how that is coded by most people. You will have a set of elevator objects with states that they currently represent.

But, you could also do this fully numerically with a polynomial representing things. Expand your toolset to use generating functions, and you can even start building equations that can count the number of solutions at any given state. Still just a symbolic model, but very very different from the OO or even FP style of model that most programmers will write.

Better for the problem you are solving? Probably not, during the exploration side of things. But get the problem into a formulation that you can translate into a SAT style, and you can feed it to SAT solvers that are far more capable than programs most any individual can write. Translate the solution back to your representation for display to the users. (Or just general use in your program, as you move to the next thing.)

I mean, there's different ways to describe this but it comes down to how you want to think about state. The more pure you get the more you can focus on operations or transformations, as functional programming is really about pipelines of transformation of code & data. By having such a constraint over state it allows one to potentially find it more easier to reason about whatever domain they are solving for. However in order to achieve that there is a certain set of hoops one has to mentally go through and maintain in order to think clearly about said problems. For some that is worthwhile for others not. I generally trend towards code that is functional regardless of the language.

Related concepts that are relevant at a high level is the comparison between declarative code and imperative. Code that is functional tends to be declarative and in a way "is what it seems to be." There is also a transitive property that allows the makeup of a thing to also be its own runnable representation which makes portability or idempotent things easier to achieve.

I dare say that original "OO" in terms of "message passing" is functional in nature, but object-oriented somehow became something it is not.

Erlang is probably the best representation of a functional language ideal in my own personal opinion when weighing in the ecosystem and capabilities of the language and tooling.

IMHO the benefit of fp is it's easier to prove things. The downside is that it's more work: being able to show you've done something correctly is extra work on top of the actual doing of it correctly.

There's a point of view that if you haven't done it correctly, you haven't done it at all. There's another point of view that you just fix bugs as they found.

John Backus, one of the pioneers of functional programming, said “Functional programming makes it easy to do hard things, but functional programming makes it very difficult to do easy things.”

Can be useful for running untrusted code. You can bound your pure functional programs in time and space.

Functional is the way to go up until you have a problem that you need e.g. TLA+ to solve.

In other words, is your program a calculator or a robot?

Recommended (free) reading: Professor Frisby's mostly adequate guide to functional programming

https://mostly-adequate.gitbook.io/mostly-adequate-guide/

See discussion: https://news.ycombinator.com/item?id=22654135

I like pure FP languages for writing UIs. In particular I like languages where you can't have any undefined behavior. I like modeling the state of a page/form/component/whatever as a bunch of constructors on a custom type, each containing exactly the data you need to render the page/form/component/whatever in that given state. I guess this isn't so specific to UIs but it's where I have the most experience. Modeling something as a state machine is cool and good.

IMO pure FP is nice because _compositionality_ is nice. If my problem has lots of simple data structures that represent mathematical objects, then usually I find that most of things I want to do with them can be succinctly modeled with pure function compositions. When my problem gets more complex, including but not limited to state, monads can restore that compositionality in a way that works with the rest of my pure code.

This property is true to varying degrees outside of pure FP too. For example in Rust I find that expression-orientation makes programs fairly easy to compose, modulo thinking about ownership.