> Are you saying the biggest and probably most complex software (OS-es, browsers, etc.) out there is written in fp languages?
You know I didn't say that.
The imperative coding approach is cognitively more difficult. So at scale (size of code-base) you either have more bugs and therefore more overhead/cost of development; or you look for coping strategies to minimise the bugs and the cost of development.
Declarative, pure functional programming reduces the cognitive load, because you get to compose things reliably. And because it's declarative and pure you don't have to look under the hood to see what is going on, you know from the surface what large bodies of code do.
A simple example, two functions prototypes:
One in Java
int foo(string x);
One in Haskell:
foo :: String -> Int
I can tell you much more about the Haskell one than I can the Java one. The Java one could launch nuclear missiles for all I know, the Haskell one can't and therefore the returned Int has some relationship with the String argument, probably the length of the string. When you don't need to look inside you are more productive. When you can reliably compose code it is more robust and easier to build. When you declare your side-effects up-front, you can make better judgements about what the outcome of calling any function might be.
You are of course free to take whichever approach you like. The imperative one is however just going to get progressively more difficult as applications get more complex. I spent 27 years writing various combinations of assembly, procedural, and OO. I've spent the past 10 using the functional paradigm. If I ever had to go back to the imperative paradigm it would fill me with dread. I still need to use it occasionally for performance optimisations, but I would always wrap it with a declarative interface (where the contract always holds).
> As far as I know those "off the shelf engines" are not written in fp languages. And I would say they are complex.
When I talked about 'easy', what I meant was that games development has much less of the real world to deal with:
* You tend to know your user
* The user doesn't get to have a say
* You often know exactly what hardware you're going to be running on
* You don't have to integrate with 20 other systems by 3rd party providers
* To a certain extent you can put it in a box and move on (I know that's not strictly true, but you're unlikely to be maintaining a game for more than a decade)
* The feature-set of the game won't double every few years as the product competes with others
* Most games have a relatively similar management system
* There aren't massively complex compliance issues or laws that get in the way (yes there are some, but less than other industries)
* Although networking and game-state synchronisation is a hard problem, the scope of distributed computing problems are small
A game engine really isn't that complex. Of course it's hard to make it as optimal as possible, but the problem isn't at the real difficult end of the spectrum. Probably the hardest thing in games now is writing the tooling. I spent a number of years writing core tech and tools for a 3 studio games company and that was just at the beginning of the tooling journey. I assume that's quite a sizeable coding challenge now; one I would definitely us FP for if I was still in the industry.