[SomeCallMeTim]

> React begs to differ.

React is good for certain classes of UI, granted. I use another FRP-style library (not React) to render UI in my current game, and it works well -- except that it doesn't mesh well with me trying to control it from an OO game, but I've created an interface that works.

But imagine creating Adobe Photoshop, Maya, or Microsoft Word entirely in React, and tell me again that FP would be the ideal choice.

For any particular dialog that pops up? Absolutely.

For the entire app? You'd end up with a "god object" that would make the app unmaintainable. OO gives you compartmentalization that you don't get with FP.

FP is great for problems up to a certain complexity. After that it falls apart. Thing is, 98% of apps don't come close to that level of complexity, so there are lots of people who never even work on an app that won't work well with FP.

In the RectIterable example you gave, I'm afraid I don't know enough Haskell to comment on it intelligently.

Is "instance" adding an interface to TileMap/HexMap so that either can be passed in as a parameter that requires a RectIterable? Can other interfaces be added that way to TileMap/HexMap?

In my editor, can I say something like myTileMap.iterateRect after doing this, or do I need to know that iterateRect exists and remember exactly what it's called?

The last point is salient: Discoverability is a huge part of the UI of a programming language, and memorizing all of the exact function names that are appropriate for a data structure is not fun.

[pka]

> For the entire app? You'd end up with a "god object" that would make the app unmaintainable. OO gives you compartmentalization that you don't get with FP.

Well, not quite; take a look at the Elm architecture [0]. It's basically what Redux gives you, but more explicit.

The idea is, that yes, while you have a god object in the top-most component, child components don't know anything about it; they operate on their piece of state completely independently. This makes UI elements perfectly composable and reusable, since in the end, a UI element is just a pure function and nothing more.

Not to mention other nice side-effects (sorry :)) of pure UI architectures, like time-travelling debugging, sane logging and so on.

> FP is great for problems up to a certain complexity. After that it falls apart.

I disagree completely. FP, and moreover pure FP, is especially well suited for complex problems. Pure functions are testable (if you haven't heard of QuickCheck / generative testing, you've missed out) and as I said above, composable.

If anything, I've never seen a big OO program made out of truly reusable components. Because classes and methods are often impure, before calling a method one must make sure that the correct environment is set up in the right way (if you've ever forgotten calling initSubsystem() before subsytemDoSomething() you know what I mean).

One can rip out a pure function from one codebase and reuse it, as-is, no modification necessary, in another one without any problems. How often does this happen in a big OO project?

> Is "instance" adding an interface to TileMap/HexMap so that either can be passed in as a parameter that requires a RectIterable? Can other interfaces be added that way to TileMap/HexMap?

Yes, and yes. In Java, when you have a class like this:

    class A implements B, C {
    ...
    }

in some library, you can't add D to the list of implemented interfaces.

In Haskell, you can:

    instance D A where
      ...

Haskell assumes an "open world" - i.e. everybody can add instances to a data type even after it has been defined already.

I can't give you a complete overview of the differences between ad-hoc and parametric polymorphism, but there are plenty of resources online if you are interested.

> In my editor, can I say something like myTileMap.iterateRect after doing this, or do I need to know that iterateRect exists and remember exactly what it's called?

I can only speak for Haskell here. It's a static language, so things like autocompletion, show type at cursor, jump to definition etc are not a problem. The tooling could be a whole lot better, no doubt, but it's not bad. The REPL helps a lot, too.

[0] https://guide.elm-lang.org/architecture/

[SomeCallMeTim]

> Haskell assumes an "open world" - i.e. everybody can add instances to a data type even after it has been defined already.

TypeScript, which is my current OO language, will use signatures to match to an interface, so it's even more open: You can create an object with the right members and pass it in to a function expecting an interface without even explicitly identifying it as "implementing" the interface.

> If anything, I've never seen a big OO program made out of truly reusable components.

Agreed. The point of using OO in a giant complex program isn't just the reuse, which you point out is exaggerated. The point of using OO in a giant complex program is the isolation you get, so that a team of 1000 people can develop the app in a reasonable way.

I think the cost of FP as the complexity of a program goes up is that the cognitive load to think about the structure of the program goes up exponentially faster than OO. Debugging is a huge issue when things get complicated, and the last I heard Haskell debugging is still in its infancy. A debugger where you just can step through the code is really, really important for some kinds of analysis.

It's all Turing Complete, so you can do anything in FP that you can do in OO. It just feels harder to decompose problems into FP units than OO units, at least at a larger architectural level. Not everything is easily isolated: Sometimes you need a control over here to poke into the state of a control over there, and you don't want that information in some "god object" at the top level; you want a direct connection and mutability.

I have heard good things about Elm, and will probably give it a try at some point. But my 30+ years of programming experience have given me a (possibly incorrect) strong intuition that FP just won't work well for some problems. Can they apply to them? Sure.

> [...] pure FP, is especially well suited for complex problems.

Which is why it's so popular for solving complex problems? Looking at a list of Haskell's uses in industry [1] and applications [2] I don't see a single example of Haskell used in what I would call a "complex problem". Lots of machine learning, parsing/compiling, and transformation tools. Some games written by amateur game developers -- getting a game working is about 10% of the problem. A very few more complex apps that I've never heard of, but nothing that hits the complexity of even a Microsoft Word or Adobe Photoshop, much less a 3d editor like Maya. There's an order of magnitude more complexity in an app like those.

Haskell is 27 years old. Over the last ten years it's been incredibly popular. Totally enough time for at least a few high profile applications to have been created. Where are they?

Maybe Haskell would be a better platform, but it's just harder for many programmers to think pure-FP. But even that's a real limitation: If you're putting more cognitive load on the developer, then you're just changing the problems, not preventing them.

[1] https://wiki.haskell.org/Haskell_in_industry

[2] https://wiki.haskell.org/Libraries_and_tools

[pka]

> You can create an object with the right members and pass it in to a function expecting an interface without even explicitly identifying it as "implementing" the interface.

Row polymorphism is indeed very useful. Purescript (a Haskell descendant compiling to js) has it and I wish Haskell did too.

> The point of using OO in a giant complex program is the isolation you get, so that a team of 1000 people can develop the app in a reasonable way.

> Not everything is easily isolated: Sometimes you need a control over here to poke into the state of a control over there, and you don't want that information in some "god object" at the top level; you want a direct connection and mutability.

The above two statements directly contradict each other. Yes, OOP preaches isolation and programming against abstract interfaces, in theory. In practice, more often than not one is tempted to do something the easy way and "poke into the state" of another object. This has disastrous consequences: you never know what will happen where when you call a method. Everything is fair game. It's like changing the lock of the basement door in a skyscraper somewhere only to have it fall because the steal beams depended on this exact lock to hold some state, since it was "faster that way". It's insane.

I've seen so many OOP clusterfucks that I seriously can't believe that you haven't in your much longer career.

Sometimes FP is not a good idea - mostly when performance, memory or deterministic runtime behaviour is a must. But even there languages like Rust show that it may be possible to have one's cake and eat it too.

Other than that, I'd be genuinely interested in hearing what kind of problems you think FP wouldn't work well for.

> Which is why it's so popular for solving complex problems?

It is, actually. I've worked on a very complex codebase in Haskell at my last job (a pathfinding and ticket price calculation backend with ridiculous specifications full of special cases and exceptions that changed almost every day) and I was able to be productive almost from day one. We could refactor with almost absolute confidence because the language is pure and type safe, and we had to because the specs changed so quickly.

Facebook's spam filter and Jane Street's OCaml stack come to mind as other examples.

There aren't as many applications written in FP languages simply because these languages aren't that popular. But popularity isn't a metric of quality.

> If you're putting more cognitive load on the developer, then you're just changing the problems, not preventing them.

I absolutely find the opposite to be the case. Haskell reduces the cognitive load on the programmer, because it is pure (i.e. no need to keeping track of dozens of interactions at once) and type safe (i.e. a function marked as pure can't call a function with IO).

Not to mention things like an actual working software transactional memory implementation that makes concurrent programming as easy as writing a single threaded program. No other language, with the notable exception of maybe Clojure, has a practical STM library. But anyway, STM is just a bonus.

In short, I would say that FP actually delivers what OOP set out to but couldn't. Many FP ideas that were almost unheard of just a couple years ago, like immutable data, pure functions, composition over inheritance, non-nullable types, algebraic data types and so on are slowly but surely taking hold in the mainstream. Pure FP languages just take it to the next level :)

[SomeCallMeTim]

Well, as I said above, I write games, where we need deterministic runtime behavior, memory, and high speed. Very few other domains get as complex, too.

When I said "poke into another object" above, I didn't mean literally mutate the data of another object. Private data is a good thing. I meant grab onto a handle to the object and changes its state through its public interface.

None of the "complex" problems you're talking about hit that level for me; they're mostly the kind of algorithm you can easily approach from multiple directions. Pathfinding, ticket price calculation with a million special cases -- these are broad-but-shallow problems for the most part. A spam filter is one or more algorithms applied to a data stream. I don't know Jane Street's OCaml stack, and a quick Google isn't explaining it to me, but it looks like some kind of parser?

A game might use pathfinding, but an A-star or one of the many newer algorithms is pretty straightforward. Not the kind of complexity I'm talking about. I'm talking about needing to deal with the state of a hundred or a thousand items that have various ways they can interact with each other and that are expected to have emergent behavior. Like you'd find in games, but as you may also find in stock analysis (speaking of a domain where speed can be critical).

I've avoided the worst of OOP I think because I've avoided enterprise work, except for one greenfield project where I got to create an app for the retail space -- and I ran into some pretty awful code that was wrapped in a giant black box that only ran on Windows and required about 160Mb of RAM per user...to run a cash register. No I'm not exaggerating. It was insane.

The problem with using concurrency in FP is that the entire point of concurrency is speed, and on the problems that most need speed you get more out of an imperative language.

There was an attempt to code an image convolution algorithm in Haskell that I read about. A PhD tried his hardest to parallelize the algorithm and beat the speed of C code handling the same problem. I turned out to be impossible; the asymptotic speed of the Haskell code as you added cores never ended up faster than the C code on one core. Amdahl's Law is a hard limit for a lot of problems. [1]

[1] https://en.wikipedia.org/wiki/Amdahl%27s_law

[pka]

I'd be interested in continuing this discussion via mail. You don't have a public mail in your profile, so here's mine if you are too: [e-mail]