Continuing my answer to David McCusker's response to the Feyerabend Project...

Dave wants to reduce the pile of abstractions necessary to build software to a cleaner, better factored, and better explained pile of abstractions. Doing that is analogous to formulating a new scientific theory that replaces a predecessor that explained the same problem domain. Feyerabend's main example is Galileo's theory of planetary motion, and how it replaced Copernicus. For more on this, here's an excellent summary of Against Method. Plenty of good detail on how Galileo used rhetoric and semantic sleight of hand to make his case. The only rule is "anything goes", indeed ! If only Feyerabend were still with us, and able to comment on the use of FUD by major vendors to win acceptance of their platforms. As Feyerabend points out, the use of unreason is quite legitimate, and often necessary, to get one's case accepted. Something the Open Source movement could do well to learn from. After all the greatest scientists weren't averse to a bit of FUD: "God doesn't play dice".

Like Dave, I'm working on my own new pile of abstractions. Partly because I do derive a great deal of gratification from crafting a neat abstraction. And for other reasons. The sources I'm drawing on for inspiration are rather different than Dave's though...

• Brad Cox: Planning the Software Industrial Revolution & Superdistribution
  • Binding mechanisms, and their levels
  • Gauges
  • Component marketplaces
  • The problem is not technical. It's organisational. Useright, not copyright
• Richard Gabriel: Mob Software
  • Levittown
  • We can only achieve the productivity we need with swarm effects. The same effects that built the WWW
• Jeff Vroom: AVS/Express
  • Encapsulation of procedure as well as data and behaviour
  • Visual programming. Port export mechanism to expose sub component interface
• Forth
  • Stack based

AVS/Express, in particular, exemplified the pyramid structure Dave's talking about. It's something I'm aiming for too, though I tend to call it 'white box components'. Unlike black box components, white box components can be opened up, and their subcomponents replaced. Getting the right binding and parameter passing mechanisms to enable this is the tricky part, though. That's where I'm drawing on ideas from Forth, AVS/Express and Brad Cox.

Dave also commented: "Unfortunately, explanation doesn't have a methodology as such". There is a large body of work in the philosophy of science on the nature of explanation. See Hempel in particular. Feyerabend has a lot to say on the matter in "Farewell to Reason", as well as "Against Method".

Like Richard Gabriel, Dave seems to be keen on using literary forms: "The right way to bridle complexity lies along another dimension ...a dimension of story. When code sucks, more often that not it's because there's an absence of story." It has been said that there are only seven or eight types of story. Which could give one the basis for a nice, clean literary framework, with every instanced story derived from one of the seven or eight base classes. Just kidding....