50 minutes ago, Fulcrum.013 said:Now he researches next-gen Java Script improvement and be sure he on really true way.
I really look forward to someone replacing Javascript, because it was not designed appropriately to handle things that people are trying to make it do.
Programming language design benefits from a LOT of formal methods to design and analyze it, and a lot of published research. Many of the things I have to deal with in game development would benefit from formal methods as well, if they existed for the combinations of problems we face. At the moment we're limited to specialized tools for particular applications: Valgrind, TLA+, theorem provers, static analyzers, code coverage, unit testing, etc. If you know any good tools or methods applicable to games, I would love to know about them.
In my experience, the unfortunate truth is that 99% of the developers I've met don't even know these tools exist, nor how to use them. They're entirely unfamiliar with formal methods. Very little of the code we write in most games has very much math at all. We almost never deal with converting actual mathematical equations to code.
We have teams of hundreds of people where nobody knows every single detail of the project. Spending time to ensure the entire team all knows everything they need to is not only unnecessary, but incredibly difficult, costly, and frustrating. I frequently have to remind artists and designers to commit files to source control. Yet we still need such teams finish the product anyway.
Companies cannot simply fire everyone who can't remember everything, or misses a detail. You might only have 5% of your employees left, who will then quit due to the shock. You cannot hire only the incredibly skilled people because you cannot spend the time to properly find out whether someone is that good or not.
From my perspective, having seen both the formal methods way of doing things and the "fly by the seat of your pants" way, most of the management and team coordination approaches like scrum are meant to allow teams somewhere in the middle of these two extremes to split up and coordinate work according to skill sets, minimize schedule risk due to inability to estimate costs for unfamiliar tasks, adapt to unexpected problems, and eventually accomplish what they need to.
Agile, Scrum, etc. are not ways to do things correctly the first time. They're ways to mitigate problems due to imperfection in teams.