9 Oct 2002 (updated 9 Oct 2002 at 10:02 UTC)
»
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
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....