Hardware manufacturers have been doing an incredible job of providing growth in processor speed, video technology, memory, and disk. So a good philosophical question for every programmer to consider is:
How would you change your practices if computers were infinitely fast and had infinite memory?
This would finally solve that pesky Halting Problem. :-) Yet software wouldn't write itself, so programming would still be a necessary and challenging field! Yet it seems ludicrous to suggest that the same choices of tools and methodologies would be sensible.
If you were writing a word processor for this infinitely fast computer, would you bother designing algorithms which would perform "incremental" word-wrap...adjusting only those lines which needed to be wrapped when a letter was inserted or deleted? In a spreadsheet, would you compromise the cleanliness of a design to accelerate an incremental algorithm which updates only those cells which should be affected by a change? No and no.
We already see the trend away from programmer-expressed incremental algorithms in today's 3D video cards, where it is actually faster to re-render an entire scene than to figure out which individual parts need to change. Yet strangely, some programming systems in the 2D space still burden developers with correctly painting bits and pieces of a display--rather than just drawing the screen from scratch. This code yields a fair amount of complexity in the name of performance, and can be a source of bugs and crashes.
Clearly, we will never have computers that are truly infinitely fast, or that have infinite memory. But understanding the pattern of how you would change your methodologies can help you see the future...and it's clear that incremental algorithms would be given the boot. Programmers are reasonably good at designing functions, but terrible at making inverse-functions (and even worse at keeping inverse functions up to date with respect to changes in the original function!)
For those who have spent some time in computer science academia, they'll recognize this belief as relating to functional programming. For those who aren't aware of the tenets of this style of development, it is a mathematical purity imposed on a conventional computer...in which side-effects are limited to a very small portion of the system (e.g. the initial input from the keyboard and the final output to the screen). Because the underlying runtime is aware of the data dependencies, you trust it to recompute what is necessary when any of the inputs changes.
The Functional Programming community has many adherents, but few are bringing the beliefs to bear practically upon user interface. Some work has been done in this area, but mostly at the research stage--such as functional reactive programming in Haskell. Yet this is very fledgling work, and it suffers from not interfacing very well with the large bodies of legacy code which are not written in this style.
I am working on bringing these techniques to bear upon mainstream object-oriented programming, thus making them accessible to a wider array of developers. So stay tuned, and hopefully I'll have it to share with the world someday. :-) In the meantime I'll be publishing more articles like Tying Undo/Redo Actions to a Single User Event and One User Event, One (or Zero) Error Messages, which will lay out the rules that I don't think programmers should be able to break in a system. Not having explicitly expressed invalidation is yet another one of these rules.
