Content below has been taken from tef's work.
Create separate page on the history of thought that has led to the below. Of particular note:
two types of software
Consider a bug tracker which has a field for every way one could think of categorizing bugs. It's like a tax form, with boxes and categories for everything. Many boxes are left blank, but finding the ones to fill can be a chore.
Now consider a bug tracker which is very simple. Only a few fields are available, and most deserve to be filled. Getting started is very easy. Unfortunately, it stays that way
— the training wheels never come off. One is soon awash in masses of bugs that refuse to be categorized in a useful to the software being tracked.
The two types of software mentioned are immutable
— they're either simple or complicated. There is no transition story, no way of shaping the software to your own needs. Either take something off the shelf or build it yourself from scratch. The experience is stifling.
Consider a hypothetical piece of software which is so data-focused that it shapes itself to the data instead of vice versa. This software should be able to discover, analyze, and utilize all of the different patterns inherent to the data. Everything will not
be known up-front; instead, the software will have to be changeable, easily mutated to serve people (often it seems the other way around).
Instead of enforcing a rigid taxonomy on our data, we want to describe it to some extent, but also allow structure to be applied based on specific views
. Different people will apply different priorities to a given set of attributes; catering to this is crucial.
queries/transformations as filters
Unix has long allowed skilled users to transform input into output in a variety of powerful ways. There are many small commands which can be combined to get a plethora of outputs. There is no monolothic search functionality which restricts one's options into a narrowly defined set that worked for some person at some point in time.