OOP is here to stay because it is the default model of how we see the world. You actually do not have to teach people to use this, just how to map it to the OOP Software Systems like Java/ C#.
It was great while Moors law still lasted, and to write efficient software was becoming some strange quest for some formula one fields of software like games or other massive workload fields like OS-Wizzardry.
Today, the massive workload is still growing, due to sloppy architectural habits and user demands, but the saviors of parallelization and new chip technologies have not come to rescue the sloppy-devs from the laws of leaky abstraction.
Your code runs on a hardware system.
And currently your code is running out of hardware.
And with that OOP is running out of excuses.
So you would write this.
Then it would three months before the shipping be handed to some adult- and this adult will delete it.
All of it.
Its full of references, full of class-bloat which will push one another out of the cache.
Even though the compiler will try to yank the worst out this mental crutch out of the code. Some references can not be dismissed deterministically, so they will be kept.
Which makes it incredible slow.
What replaces it will be a efficient structure, keeping all the chunks necessary for collision detection, in one very array like field.
Over this a Algo traverses, acting with a function, which does not reference non-local stuff, detecting collisions and damage. Allowing not only for a few players- but a workload of players.
It will look very ugly, like C, with inline assembler- ugly, and it will be ready to ship.
> OOP is here to stay because it is the default model of how we see the world
A common but false statement. Firstly, there is no standard definition of OOP, only loose sets of features that define various overlapping but disjoint paradigms that some subset of people call OO. So your statement is meaningless as there is no single OOP that we identify as how "people see the world".
Secondly, even given any specific definition of OOP, it's also false. There are many programs that simply aren't suited to OO modelling, because you want to express things as the problem being solved actually requires, and this is often not OO. Sometimes pattern matching is best (compilers), sometimes reactive/event paradigm is best (servers, UIs), and neither of these are OO, as but two examples.
And don't take my word for it, there are a few studies on novice programmers showing quite clearly that event-based temporal reactive primitives are what people find most intuitively natural, ie. when account balance <= O then do some action, which is a declarative reactive action that will execute when that condition becomes true. This is not an OO program in any sense.
It was great while Moors law still lasted, and to write efficient software was becoming some strange quest for some formula one fields of software like games or other massive workload fields like OS-Wizzardry.
Today, the massive workload is still growing, due to sloppy architectural habits and user demands, but the saviors of parallelization and new chip technologies have not come to rescue the sloppy-devs from the laws of leaky abstraction.
Your code runs on a hardware system.
And currently your code is running out of hardware.
And with that OOP is running out of excuses.
So you would write this. Then it would three months before the shipping be handed to some adult- and this adult will delete it. All of it.
Its full of references, full of class-bloat which will push one another out of the cache. Even though the compiler will try to yank the worst out this mental crutch out of the code. Some references can not be dismissed deterministically, so they will be kept. Which makes it incredible slow.
What replaces it will be a efficient structure, keeping all the chunks necessary for collision detection, in one very array like field.
Over this a Algo traverses, acting with a function, which does not reference non-local stuff, detecting collisions and damage. Allowing not only for a few players- but a workload of players.
It will look very ugly, like C, with inline assembler- ugly, and it will be ready to ship.