My first reaction was, "ugly!" Imagine having to include a time estimate with every function body or every expression. How can entangling time with correctness ever be a good idea?

But we do entangle time in this manner in certain kinds of programs. A good chess program alters its search strategy depending on how much time it has left. Other realtime programs probably have similar structures. So it doesn't seem quite as weird.

I've been thinking for some time now about the right way to manage performance considerations in software development. I've seen several projects now that start out ignoring performance until latency goes through the roof, then establish a 'process' to ensure latency regressions are immediately rolled back, then add some wiggle room to allow <x% latency regressions through, and finally end up in a slope of x% poorer latency every few commits. What I want is a system that allows these latency tests to be run before committing. Don't gate commits on performance, but allow commits to be audited. "Where did our latency increases come from? X% is new work, which is reasonable, the rest is poor design, let's teach those responsible to do it right." The key is a simple deterministic metric that can be quickly measured when you run your tests. Perhaps a suite of idealized simulators. This article seems to be related if I squint a little.

I'm also reminded of an old AI program called copycat (http://en.wikipedia.org/wiki/Copycat_%28software%29) which had a physics-like simulation for concepts like next/previous and first/last. Concepts could acquire inertia and volume, and problems would apply pressure on concepts causing the boundaries between them to grow fuzzy. What's common between the two? We're marrying symbols with numbers, so that one class of operations causes non-linear changes to the marriage, while other classes of operations cause changes that are more analytic.

(I'm still unsure what the term 'animated' means in this context. Rocketnia?)