Comment by TrackerFF

> What's the benefit of learning a PURE functional programming language

1. It makes it easy to learn how to structure a program in a pure way, which is hard to do in languages that offers you a easy way out.

2. Since "everything" is pure, writing tests is easier.

3. You know for certain that if you discard the result of a function call, all the side-effects that it would normally trigger would be stopped as well.

4. A program where all side-effects are guaranteed to be pushed to the boundaries, is a program that's easy to reason about.

> a language which has adapted the best bits and pieces [...]

Languages that has adapted to best bits and pieces from X, Y, Z tend to be worse than a language specifically for X, Y and Z.

For instance, Java supports functional programming but functional programming languages are much better at it because they were designed for that specific paradigm. In the same vein, sure you can write pure programs in F#, but not as easily as in Haskell that was designed for doing just that.

> and is used to handle data and events from the real world

Pure code really only means (in practice) that side-effects are controlled, which is generally very helpful. It forces you to structure programs in a way which makes it easy to pinpoint where data is coming in, and where data is going out. It also makes for easier testing.

Being able to know, definetly, the answer to "will calling foo perform a network request" without having to read the source for foo is quite nice, especially when dealing with third-party code.

All this said, I probably wouldn't begin with Haskell. A language like Elm is much better suited for learning writing pure programs.

What's the benefit?

You start to see functions as self-contained things, as lego blocks. All the logic of the function is there in the function. It only works on values it receives as inputs (it can't read global variables). It only outputs its results (it doesn't assign them to some other global variable that you have to track down).

This makes your code modular. You can add a function in a chain of functions, if you want to perform an extra transformation. Or, you can replace a function with a different one, if you want to change something about the logic.

This is all myth. People don't write Haskell, because they read why other non-Haskellers also don't write Haskell, based on what other non-Haskellers wrote.

> a language which has adapted the best bits and pieces from the functional programming paradigm?

Why write in a statically-typed language when dynamically-typed languages have adapted the best bits and pieces from statically-typed languages?

Don't think of it as being all pure code, think of it as tracking in the type system which parts of your code may launch the missiles and which parts can't. Given the following program,

    main :: IO ()
    main = do
      coordinates <- getCoords
      launch trajectory
      where
        trajectory = calcTrajectory coordinates
    
    getCoords :: IO Coordinates
    getCoords = -- TODO
    
    launch :: Trajectory -> IO  ()
    launch = -- TODO
    
    calcTrajectory :: Coordinates -> Trajectory
    calcTrajectory = -- TODO
    

I can look at the types and be reasonably certain that calcTrajectory does no reads/writes to disk or the network or anything of that sort (the part after the last arrow isn't `IO something`), the only side effect is perhaps to heat up the CPU a bit.

This also nudges you in the direction of an Functional Core, Imperative Shell architecture https://www.destroyallsoftware.com/screencasts/catalog/funct...

Haskell interfaces with the real world. ST allows for mutability in pure context

https://github.com/serprex/Fractaler/blob/master/Fractaler.h... fractal renderer I wrote in highschool, has mouse controls for zoom / selecting a variety of fractals

https://github.com/serprex/bfhs/blob/master/bf.hs brainfuck interpreter which mostly executes in pure context, returning stdout with whether program is done or should be reinvoked with character input. Brainfuck tape implemented as zipper

your program may exist in real world, but most of it doesn't care about much of the real world

There's a video game on steam you can buy with real dollars built in Haskell.

I work full-time writing Haskell. Fintech stuff. No shiny research going on here.

I've written some libraries and programs on my stream in Haskell. One is a client library for Postgres' streaming logical replication protocol. I've written a couple of games. Working on learning how to do wave function collapse.

Believe it or not, functional programmers -- even ones writing Haskell -- often think about and deliver software for "real world," use.

> Given that you want write code that sees "real world" use, and is used to handle data and events from the real world.

Real world? As opposed to what?

Is there any benefit to answering such polemical questions as if they are not rhetorical?

I can't speak for others, but I never really understood the benefits of functional programming when my language pretty much allowed unbounded mutation anywhere. I would say there's a chance for impure languages to impede you in learning what functional programming is about (or at least my experience with F# and OCaml did not really help as much as it otherwise could have I think).

Your mileage might vary, but I've heard advice from others to learn Haskell and "go off the deep-end" because of people citing similar reasons.

In a way, one benefit is the whole ecosystem / culture / idioms built on top. Haskellers went further in that direction than most languages (except maybe scalaz and some hardcore typescript devs).

Pure functional programming doesn't preclude side-effects like IO; it makes side-effects explicit rather than implicit!

At my previous job, we used pure functional programming to ensure that custom programs only had access to certain side-effects (most importantly, not IO). This meant that it was trivial to run these custom programs in multiple environments, including various testing environments, and production.

In my experience, I only really learned how to write small functions after Haskell. The discipline it forces on you is a good training.