Tracy R Reed wrote:
For most things I am not so concerned about the performance of my apps. Just about everything I use is fast enough. But not everything is bug-free enough. These days I am much more concerned with correct than fast (top currently showing 98.6% idle cpu). I wouldn't mind trading some of my computing power for correctness (which I believe implies more security as well).
The problem is that you have to trade O(n^2) computing power for a lot of functional data structures. I really recommend you go read Okasaki. It's a tough read, but it rearranges your thinking.
Garbage collection became useful because it is O(n) in computing power (number of objects a human can program rather than size of said objects) and Moore's law goes as O(n^2).
Moore's law is not gaining in the same way on an O(n^2) problem. In fact, it is standing still. As you gain the O(n^2) power, you also gain O(n^2) in memory--so you stand still.
In addition, I'm not convinced that the bugs are mostly caused by "state" in and unto itself. If that were the case, you can isolate the state behind a wall that always checks its preconditions/postconditions/etc.
The big problem is that time is a variable in our systems, *and we don't account for it*. In spite of its best efforts, asynchronous logic *still* hasn't made significant penetration into VLSI design because it suffers from all the same problems that software does. Consequently, everybody in VLSI still pretty much relies on a global clock to lock everything together.
Yet, for some reason, programmers all seem to think that they're smarter than the VLSI guys and don't need to think about time. *shrug*
The interesting question would be to ask the game engine programmers how adding time as an explicit variable has changed their programming techniques. IIRC, Carmack had some articles a couple years ago talking about how your thinking changes when you actually have a global clock you can watch (block A may only put something in when tick T % 8 == 0 while block B may only take out when tick T % 8 == 1--IIRC, this was in the context of computing bullet-object collisions--the bullet moves on tick T%8 == 0 and checks for collisons and the object moves on tick T%8 == 1 and checks for collisions--problems of the bullet and object moving simultaneously are now resolved).
Effectively, you trade performance (each block can only move at 1/8 normal speed if it has to wait) for correctness (you never have to worry about races).
-a -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
