Software Design Philosophy
A year ago, I wrote that I would soon describe my software design philosophy in developing commercial desktop applications. I never actually did write directly on my philosophy. I still had unresolved design issues, which I have since resolved through making document and view objects immutable. I also felt that it was perhaps too early to disclose some information, especially after recalling Joel Spolsky's article "Mouth Wide Shut."
On the other hand, I did offer glimpses of my approach through various seemingly random posts like Silver Bullet and Software Reliability. I also did mention a preliminary wordprocessor I was working on, which, in reality, is a universal document-processing framework that can simply and efficiently store, manipulate, and display all kinds of documents. Despite Avalon architect Chris Anderson's wishes, don't count on Microsoft delivering full-featured application frameworks that could potentially make it easier for competing products to be developed; the MFC framework included a special restriction against developing wordprocessors and spreadsheet software.
My philosophy includes programming in a more declarative and functional programming style. My software is built on the unifying concept of immutable expressions (rather than objects) for representing data, be it mathematical, linguistic, or document. The term-rewriting system for manipulating expressions was inspired by a similar system in Mathematica. The system, which is rooted on the simple, powerful, and well-understood theory of lambda calculus, leads to surprising possibilities by removing the distinction between code and data. (More on that shortly.)
I noticed this article "Out of the Tar Pit," which makes similar points to the ones I raised in my Silver Bullet post. A Turing Tar Pit is an overly-simplified, Turing-Complete language in "which everything is possible but nothing interesting is easy." The classic example is the taped-based Turing Machine, but the authors of the article also implicate imperative programming languages, which are still modeled on a Random Access Turing Machine, which introduces accidental complexity due to state. The authors instead advocate functional relational programming.
I left as a software developer in the applications group at Microsoft in 2000, but I never actually stopped developing desktop applications. I did go through a period of unlearning development approaches used at Microsoft and much of the rest of the computer industry. Imperative programming as well as the evolutionary programming development are fundamentally flawed ways of developing document-processing applications; their continued use hinders the development of intelligent applications.
Programmers in 60's discovered maintainability issues with "goto," and came up with structured programming with decorated gotos with names like "while" and "switch;" this made programming more readable but not any more expressive. We still also live with the word-by-word "assignment bottleneck." As a result, most of the operations in today's applications can be summed up as fundamentally property assignments and vector operations (insert, delete, map) rather than more complex tree transformations.
I noticed that some thinkers at Microsoft are contemplating some of the same issues that I am addressing. Tony Williams, co-inventor of COM, in a recent Channel 9 interview mentioned his interest in the declarative construction of applications. He also referred to Charles Simonyi's obsession with tree transforms, which mirrors my use of "expressions" and transformation rules as unifying concepts in my application. The data access team also refers to a "conceptual layer" made possible by the LINQ technology. (Tony mentioned he was currently working on a new component application framework, debuting in Office 2007. Googling reveals that the framework is probably built on top of COM and going by the name "Octarine." If so, I am pessimistic of any real improvements outside of some reuse. )