OK, I'm just going to "throw this out there" and see what other people think - Could this idea from Claude Lévi-Strauss' The Savage Mind (The University of Chicago Press 1966 [1962]) have any bearing on the approach to our project or the approach of those who might most use Croquet? Well, I suspect it might. But I'm interested in hearing what others mights say...
"The 'bricoleur' is adept at performing a large number of diverse tasks; but, unlike the engineer, he does not subordinate each of them to the availability of raw materials and tools conceived and procured for the purpose of the project. His universe of instruments is closed and the rules of his game are always to make do with 'whatever is at hand', that is to say with a set of tools and materials which is always finite and is also heterogeneous because what it contains bears no relation to the current project, or indeed to any particular project, but is the contingent result of all the occasions there have been to renew or enrich the stock or to maintain it with the remains of previous constructions or destructions. The set of the 'bricoleur's' means cannot therefore be defined in terms of a project (which would presuppose besides, that, as in the case of the engineer, there were, at least in theory, as many sets of tools and materials or 'instrumental sets', as there are different kinds of projects). It is to be defined only by its potential use or, putting this another way and in the language of the 'bricoleur' himself, because the elements are collected or retained on the principle that 'they may always come in handy'. Such elements are specialized up to a point, sufficiently for the 'bricoleur' not to need the equipment and knowledge of all trades and professions, but not enough for each of them to have only one definite and determinate use. They each represent a set of actual and possible relations; they are 'operators' but they can be used for any operations of the same type."
As usual, comments to this post would be most welcome!
2 comments:
Difficult. I would say yes and no.
Aspect of yes: As I mentioned earlier, for me Croquet has the characteristic of an idea engine. You work with it and several ideas coming into mind what to do with it. That holds for user as for implementors. It is this creative side of Croquet which I remember by reading this text about Bricoleurs. Also, Croquet evolves with its usage, so that it can get a set of things which have greater domain than one certain project, because it reflects the history of many projects.
Aspect of no: Croquet is a result of an engineering effort. It is a technical thing. It's built in rules reflect this roots, as the (until today known) tools do. Therefore, the existing tools like portals, filters, anotations, object creation etc cannot be useful applied to any aribitrary purpose. They are flexible, but have there place in the overall engineered universe of croquet.
Conclusion: The text is a useful hint to make Croquet more creative: Use a small set of simple rules (for its universe), and create things which are only a consequence of rules and not an answer to "how can I do this" or "what is the solution for".
- Hans (hnbeck@t-online.de)
The photo at the head of this posting and the concept of a "Croquet Bricolage" introduce to me a difficulty which is not often addressed.
The same difficulty is also suggested by this Asian saying: “[Whole] cake in both hands… now what?” Too big to eat. Too greedy to put one down risking someone else taking it.
Or, in the case of the photo, can he use any of the tools on his person without setting down at least one of them (given that he doesn’t have an infinite number of arms)?
In the case of the “bricolage”, if giving and infinite number of tools, how long will the search take to find the right one? A content/code creator can only evaluate one search result at a time due to our physiological and cognitive constraint of one focal point of attention.
In the case of Smalltalk and class libraries, given a huge number of classes, many with various shades of similar effects, roles, and uses, how does one find the right line in the right statement in the right method in the right class in the right version in the right package in the right class library to edit? The simplicity of the language’s syntax places a greater burden on the construction and architecture of the class library for its logic and ease to configure. Simple mistakes made early on, then inherited, and then workarounds added at many different levels and many different layers, makes a more rigid structure and more difficult to change, than one would have imagined simple syntax with many tools would have allowed. “500 channels and nothing to watch.” 1000’s of classes and no class or method is “just right” so we always add “just one more” further complicating subsequent searches for “just the right one” in a continual spiral to ever larger collections of “not quite right” classes.
In Croquet, I suspect its Worldbase servers would suffer from the same difficulty. The “right content or code” is hard to find by a “keyword” search, so a “not quite right object” is taken instead and modified and resubmitted to the Worldbase. This continuing spiral could also add extra storage burdens, CPU burdens, and bandwidth burdens to the Worldbase servers as well.
The only solution that I can see is a “semantic search” instead of a “key word” search. One that matches intended effects, intended purposes, and intended architecture instead of hoping the original content/code creators use all the same words that you expect them to use. There are many synonyms and metaphors in current use in the real world systems that content/code creators would model in Croquet and that are not covered in any thesaurus. Refactoring content or code after the fact is difficult, thankless, and unprofitable work.
Post a Comment