You really do have to start over and write code very differently. That's unavoidable. Procedural languages are good at sequencing things for a von-Neumann architecture. Parallel systems are not von Neumann Architectures. Procedural code encourages bad thinking habits which create runtime problems. To do massive parallelism you want all your code to not not specify order of operations (so the runtime engine can decide) and not involve state changes till the end (since these require synchronizing between computing nodes). If you think about the first thing you learned when you learned to program it was: " a program is a sequence of steps" (order of operations). The second think you learned was print (state change).

You have to reorganize your code in a way consistent with a new paradigm. No library is going to solve that.

The classic example is church number subtraction. (I should mention Haskell solves this now via. rank 2 types, but very few languages have this).

So just to define terms church numbers take two arbitrary values: think f = (+1), z = 0 for the trivial case
zero f z = z
one f z = (f z)
two f z = f ( f z)
three f z = f (f (f z))
etc..

given two church numbers
minus n m should be the church number for their difference
ie, for all f, z
(minus three one) f z = two f z

generally this is done by using the predecessor function
pred n f z = snd $ n f' z' where
    f' (a,b) = (succ a, a)
    z' = (zero, zero)

and then
(minus m n) f z = (n pred m) f z

minus is not expressible as a rank-1 type in any language. Since most languages don't have rank-2 types...

Mixed paradigm languages (like LISP) can be tough to have style guidelines. The purer functional languages enforce a functional style because bad code is a syntax error. You simply don't have syntax to break many of the rules. Haskell programmers often comment that getting a program with rich type definitions to compile is close to getting that program debugged.

Also standardizing form is less important when the number of lines reduces drastically. Functional programming encourages a paradigm that if a program is long there is an abstraction missing and fix the problem that way.

That's just bad functional code. What you are describing (though the notation is hard to follow) sounds like a fold. https://wiki.haskell.org/Fold
That has final and initial values.

The other thing is you don't want to be "doing stuff" and iterating. You want to be computing stuff and then "doing stuff" on the entire set of output. The system as it pulls output will drive the iteration on the computation. What you have above is sequenced. Getting rid of explicit sequencing is part of writing functional code.

Yes. I think it counters the "functional programming is too hard to learn for most people" argument fairly well. It shows an example of a functional programming language that lots of low skill developers (i.e. general office workers) use quite comfortably. There are of course more interesting functional languages but because they are more interesting they require more learning.

FP is already more popular than OOP. The world's most popular programming language (Excel) is functional. Think of a spreadsheet as just a bunch of out of order function definitions...

I'm not sure what you mean having to keep track of an iterator. Can you provide an example?

Functional reactive programming came out of the functional community. Assume you had an array of all the inputs the end user entered for a game that already happened. Then the engine can create an array of all the corresponding outputs. That's your engine. Now wrap the construction of those two arrays in a stateful monad (IO).

This book ( https://www.amazon.com/Haskell... ) is out of date but it will teach the ideas well. You'll create a video game and a music player.

In general though, no video games don't generally get written in functional languages they are too messy and stateful. Video game engines though can easily be written in functional languages.

The results are usually either trivial or dangerous.

To pick two examples. Perl has had a map for many years which is just syntactic sugar for the foreach construct. On the dangerous side we have the new optional monad (Java's name for the Maybe Monad). You can use it trivially like this

Optional person = personMap.get("Name");
if (person.isPresent()) {
    Optional address = person.getAddress();
    if (address.isPresent()) {
        Optiona city = address.getCity();
        if (city.isPresent()) {
            process(city)
        }
    }
}

On the other hand if you try and use it the way Maybe/Optional is really intended things blow up badly. The API aren't retrofitted to lift into the monad the way they should. So code will execute in sequence unless you catch exception in which case you are back to explicit exception catching. The primitives don't lift (there isn't optional int, optional char...), so methods don't lift smoothly ...

Essentially the less purity the less you can pull across non trivially. You can mix in some impurities (LISP) if you assume developers are very aware of theory.

So what ends up coming across are some nifty syntax from functional languages and a few minor features.

Haskell has a for loop. The thing is that there are really 2 types of for:

1) Go through an array and do something to each element (map)
2) Do a sequence of actions. for :: (Traversable t, Applicative f) => t a -> (a -> f b) -> f (t b) is just traverse with arguments flipped

The functional languages are often about 2 decades ahead of the imperative languages in terms of features and ideas. Truly powerful type systems, purity, laziness, infinite data structures. They really do change the way you think about design. Engines (controllers for MVC) are excellent in those languages. They are also very good for protyping non-vonNeumann architectures (like Hadoop code) unlike the Algol based languages.

They have their own problems like a tendency for slightly less than optimal algorithms to be quadratic in memory.

What is going on with redundant ratings on every post. This has been happening for months.

For almost 30 years we have had chess computers competitive with the best human players in the world. None of them understands they are playing chess. None of them understands why they are doing what they are doing.

Many of the systems that large number of human lives already depend on require machines to make correct choices. Including your car which at this point has dozens of systems none of which "understands what is doing and why" that are making adjustments to the instructions you are sending via. the wheel and the pedal based on information you aren't getting like road traction.

We aren't talking size of the total database, we are talking size of the dataset that needs to be manipulated for the query. You can't tune Oracle for Hadoop levels of parallelism.

I'd say its really this.

You have a business problem which is completely unrealistic to solve via. vertical scaling on SQL Things in the range of 50-200k CPU hours Hadoop is good for. SQL solutions are pretty dreadful at 1000 CPU hours type workloads. BTW petabytes and exabytes. SQL is pretty good for terabytes.