I would understand “randomness” here as the lack of a definite first time derivative for every aspect of the matters we care. Such derivatives mathematically manifest the “causal relationships” as time drives the world to proceed. Randomness is intuitively “change(potential)-with-no-cause”, do we still have reasoning power after causal semantics banned?
Such a “choice” is about picking/fitting an approximating time derivative function against the observed randomness? Yes the candidates can be infinitely large in number then. Some definite derivative functions would predicate the lines never meet, others not necessarily.
I can assure you that in the software industry, FP usually imposes way stronger and finer-grained limitations / structural-constraints, by leveraging stronger type systems, toward mathematically soundness; on the contrary OOP languages usually limit the expressiveness of its type system (C++/Java/C#), if not go rather loose (see duck typing) in typing (Python/Lua/Smalltalk).
That’s FP’s secret sauce for easier complexity management in large software projects: force participants to speak more clear and explicit about the premises and assumptions of a piece of software, as it’s handed out or get deployed. That’s to say, you usually get much less “choices” with a typical FP language (Haskell/OCaml/Scala) than OOP.
The reality is but LISPs (Scheme/Clojure) have a different story, stripping off semantics from S-expressions. OOP has no way to do this, and non-LISP FP don’t do this either.
And the reason is not very hard to guess, such limitations are need for principled software engineering, as a profession. Because a Von Neumann computer (even a universal Turing machine), has fixed semantics, all the software industry can do is mapping human daily business processes onto the fixed ISAs (which is essentially the lowest level programming language) of computers set to run. You don’t have any more interpretation power than the ISAs can do. Unlimitations can only exist in a programmer’s dreams.
But my pessimism like said above only covers programming qua “computer programming”, I’m in active search for the paradigm shift to “business programming”, and are faithful by far. I think the key is to maintain an adaptive “meta execution system” at runtime, never see exact literatures on this topic, but once execution/interpretation of one piece of surface code can lead to different interpretations of the same code at later runs, we can open new doors for such “choices” as you said. Currently as with designing a “computer programming language”, unstable interpretation of the same code, semantics-wise, is a BIG taboo.
Yes, “totally restructure on the fly” is the idea in my mind. Though I’m set to solve existing business problems atm, reaching novel problems is dreamful though.