[CPPCON 2014] Data-oriented Design - Mike Acton

video:
https://www.youtube.com/watch?v=rX0ItVEVjHc

• No Exception
• No Template
• No IOSTREAM
• No Multiple Inheritance
• Seldom Operator overloading
• No RTTI (turn off) i.e no virtual function
• No STL
• Custom allocators
• Custom debugging tools (into the code)

The purpose of all programs, and all parts of those programs, is to transform data from one form to another.

If you don't understand the data you don't understand the problem.

Conversely, understand the problem by understanding the data.

Different problems require different solutions.

If you don't understand the cost of solving the problem, you don't understand the problem.

If you don't understand the hardware, you can't reason about the cost of solving the problem.

Everything is a data problem. Including usability, maintenance, debug-ability etc.
It's not code problem.

Avoid adding problem into the problem while solving the problem.

Latency and throughput are only the same in sequential systems.

Rule of thumb: Where there is one, there are many. Try looking on the time axis.

Code is NEVER more important then data.

Software is NOT platform. Hardware is.

There's no ideal abstract solution.

Help the compiler reasoning.

Don't put evaluation inside a loop. Put it outside.

Good programming is HARD.
Bad programming is EASY.

Design pattersn are spoonfeed material for brainless programmers incapable of independent thought, who will be resolved to producing code as mediocre as the design patterns they use to create it.