Primitive tool-based systems

Many of the problems - with programs if not with data - that have been discussed here can be avoided by designing a system around primitive tools that provide no more facility than what is necessary for a user to put the things together to produce the computations needed. Such a system provides adequate facilities for the right user, tends to be very extensible, and can typically be kept very small in spite of being integrated and powerful. Most important, such systems are conceptually very simple. However, they do tend to be disastrous for unsophisticated users and even sophisticated users spend too much time fussing around with the tools themselves. In a rich environment, that fussing often has more to do with the process of moving objects back and forth - looking for tools to make square pegs fit round holes than with anything substantively interesting. Further, all other things being equal, systems of primitives tend to be slower in operation than higher-level integrated systems, and are sometimes so slow as to result in poor response rather than merely poor resource consumption. None the less, such an architecture may be a reasonable choice for some audiences.