Yeah my main language is C++... I don't really like GC. I know the patterns to not leak (ex: use reliable primitive containers and let their destructors do the work... slap anyone's fingers if they try to type malloc, free, new, or delete). I then have to go into C# and Java and its like... why... why did IDisposable turn out this way?

I digress.

Back to your point... I mean... everything should be a local variable. Everything should be owned by a stack frame that's somehow attached to main. Any heap allocations should be done by the container that's sitting at some level in the stack. Those containers have some API to access its contents. That's what OOP is good at.

Like... you don't say, "Hey table + 508 bytes, how are you?" You say, "Hey table -- what's in row 6 column 4?" and it gives you some view into it (reference, copy, whatever). That's OOP. It should be used as a parameter of a pure function that cannot affect any state (except logging) outside of itself, which is where the meaningful work will be done. That's Functional.

It's actually kind of simple.

Pure functional encapsulates state to a stack frame, accessed by the function's parameters. OOP encapsulates state to a container, encapsulated by the class's public API.

Containers can persist. A stack frame, on the other hand, is born when you push a question onto the stack and dies when the answer pops from the stack.

Ideally, you want to give the compiler as much information as possible to limit you... because if you're telling it inconsistent things, then you're in the progress of writing bugs. Encapsulation prevents you from accidentally reading from or writing to memory that you told the compiler isn't relevant (because it's not a parameter, you're not accessing it in a public way, etc.). A function can further protect you by allowing you to declare parameters as read-only (const in C++) or write only (return value in C++... a write-only equivalent to const would be nice).

For example: Let's say you want to see where two curves intersect. A bug-resistant way to program this would be to have a class for each curve, and a function that compares when they intersect.

Why classes for the curves?
Each curve would give you a set of methods / properties that ensure you're on the curve. It prevents the function from accidentally breaking the curve.

Why a function for the comparison?
This tends to be where OOP goes wrong. A function cannot affect state other than its writable parameters... and it cannot be messed with outside of its readable parameters. In fact, when given the same inputs, a function will always produce exactly the same output. If the containers provide a sufficient public API for the function to do its job, then there really isn't a whole lot of ways that the function can screw up. (And, once you have a spec, you can verify that it's being followed with unit tests... because of the "always produce exactly the same output" property above.)

As usual, the real way to look at "X or Y" arguments is to identify the things that X and Y are good at, and use the correct one for the right situation.

The first step to finding a solution is admitting you have a problem. That's where we start.

Correction: homeopathic thing + anything else = anything else + water

Actually, Gabe Newell at last year's CES (last January) was talking about NVIDIA Maxwell architecture. He claims NVIDIA will allow GPU virtualization for gaming applications. In other words, one PC could power multiple netbooks or Roku-style Steam boxes.

That said, split-screen (even multi-monitor "split-screen") is cool and occasionally occurs in PC games.

Fir..! Dangit : ( Guess not.