Question is: as much as gameplay coding in C++ is well known to be more costly - and therefore slower -, were those 3 yeas (2 already and eventually 1 more) invested in... err, gameplay coding in C++, wouldn't it be better? Or in other words, the development time that whatever new solution gives will be worth 3 years of cost? It seems to me that it won't, but Josh got into that situation in which the more late he gets with trying to solve such dillema between performance and development cost, the more he feels the need of lowering future time-costs of development to compensate for lateness - in a rather vicious circle.
He wrote about another substantial problem: "mental RAM".
As the code size increases, it gets exponentially more difficult to keep an overview about the inter-workings of the code.
Plus: when compilation times increase from seconds to maybe tens of minutes, it blocks any quick iteration on solving a problem.
I understand the need and wish to delegate a large part of the game logic to a (much more compact) and quick-to-compile-an-test(TM) scripting solution.
So writing everything in C++ might be manageable, but at one point in complexity, any developer will hit an unproductive wall.
Thats why I usually develop a separate module for a specific problem, (be it like that economy simulation, be it a path finding solution,
a networking engine, an entity sprite animation system, an inventory system, etc).
Its taken out of the "big" project, and developed separately. Important is to early define an interface to the other modules, and have
a simple mockup-engine t execute it.
Once the module is working, it can replace another placeholder-module.
Is more work that writing everything in the context of the full project, but keeps each module small enough to keep an oversight.
In the worst case I dump all the prototype code, and rewrite it. But now knowing how the logic has to be implemented.
For the presentation: Lets say he has a market simulation, that is in the current state just a long log-file with events and
trade-data. That probably would not make much of a presentable item, even if its very sophisticated at the inside.
Although for "marketing reasons" it might be nice to just showcase some random (even older) scene renderings, if they are available anyhow.