half/half - run-on train of thought + full sentences:
inspiration from E:
To be specifically wrong is important, rather than being generally right.
The problem with capital-T Theory is that, when compellingly crafted, it is doomed to being right all the time; that you carry with you your own framework that you apply onto the world, loosely, and that it also fits successfully, loosely. As an interpretive framework this may be interesting, charming, 'poetic', but this loose-fit approach stops or kills any sort of action, instead choosing to exculpate itself from impact by embodying incoherence or a lack of control.
A general theory of marionettes could go along the lines of: "Marionettes operate with strings that attach to a puppet's limbs, that are then attached to a controller, moved by a hand. Moving the controller thus moves the marionette. As such, the manipulator/puppeteer is able to create and control the puppet with a wide variety of motions."
This theory is accurate, but too general, doomed always to be right, and thus never mobilizeable, never a learning moment. A more specific theory that is in danger of being specifically wrong could be:
"Marionettes are often human forms with articulated limbs and joints that are controlled with strings, attached to a controller. Due to the number of varied limbs, joints, and movable parts that exist on a marionette, often times the controller serves as a simplification/consolidation mechanism that links different strings together into a single operation. When the controller is rolled (as in yaw, pitch, roll) to one side, two strings on one end of the controller may be lifted, while two other strings may be dropped, simultaneously affecting four strings at the same time. When the controller undergoes yaw rotation, those four strings may be stationary, while other strings are moved. Yaw and roll are thus ways to isolate different categories of movement -- for example, left and right sides of the body, or hand and leg movement. Other operations, such as eye movement, can happen via an additional mechanism or controller that operates independently from the main controller. And since strings operate only in tension, movement that has to happen rapidly with low latency and high speed may be controlled via metal wires or wood dowels. The question of lifelike movement and intricate, detailed operation is thus a question of the design of the controller and how it can reduce a number of specific movements by linking them with a specific controller. As a whole, the complexity of an anthropomorphic body, coupled with the number of characters necessary to create an engaging narrative, often means that puppet shows or marionette shows rely on engaging dialogue, imagery, and decoration, rather than having a high degree of articulation and detailed movement, since the latter approach could require one or more operators per character -- making anything but a two-character play a cumbersome ordeal, or at least, a more complex production."
The latter statement becomes more detailed. More exceptions to the statement. Not all marionettes are humanoid. Some puppet shows involve dozens of operators per puppet. Etc. Etc. If I become wrong, I am at least specifically wrong. Delving deep into the details thus allows me to self-correct, to modify, to be specifically critical, and to be experimental.
It's not that god (or the devil) is in the details; it's that everything is constituted out of details, in the same way that all software is constituted out of lines of code. There may be shorthands, black-boxes, encapsulation that occurs; the formation of classes, methods, etc. that "take care" and abstract some specific function is akin to a taxi that "takes care" of the process of transportation. But everything is made out of lines of code. Everything is made out of actions and objects that interact and affect each other. A theory of movement within a city is related to desire, gas prices, road conditions, weather, city planning, population density, and more specifically, the tread of the tire, the degree of salt on the road, the pitch of the road that drains rainwater off into gutters, the timing of traffic lights that enable right turns, the distribution of subway stations that make buildings within a certain radius of a subway stop more desirable and more populated, the impact of both OPEC regulations and New Jersey gasoline supplies onto gas prices at a pump next to a taxi company in Astoria, the circulation of historical imagery and cultural capital (there's a giant black-box of a term if I ever saw one) that mythologizes New York in the first place, the restaurant in the East Village lauded in Yelp that draws you to curiosity in the first place, and so on and so forth.
A necessary theory of inter-relatedness is one that uses specific statements that may fail; one that uses a discerning eye for connections and are able to compare which connections are more influential (astrology as an explanation for an event is a bad connection), yet understands the influential ability of different objects (gun availability induces suicides), and also understands the influential abilities of narratives (astrology as an explanation for why a relationship ended is a bad connection; understanding how a person's use of "astrology as an explanation" could itself have aggravated a relationship to the point of a breakup is a good connection). And most importantly, this theory would be specific to an event; no grand unifying theories, just micro-explanations highly relevant and highly specific to a time and place.
If there are any grand unifying theories, perhaps it would be wise to examine programming and software development for their approach to models of the world; are there any singular models of programming, or how software is structured? Structures are always being modified in action; exception always arise; black boxes always torn apart, rebuilt, re-created. The practice of programming, to a certain extent, is a practice of amassing, building, exploding one's own black-boxes, whether that means understanding which Python libraries to use, how to structure one's own code, or how to efficiently collaborate within a team so that person A takes care of a task while person B takes care of another one. Libraries, methods, classes are never sacrosact, nor are they temporary and unhelpful shorthands; they're tangible, real, modifiable "theories" of operation that help a programmer structure how a piece of code works. I may import the 'urllib2' library in Python that helps me download a file from the internet. I may swap it out and import Beautiful Soup in order to scrape some data from the internet. Ontologically speaking, urllib2 and Beautiful Soup are both valid. Neither is wrong. Both may share a lot of overlap. They may even use each other's code, or rely on each other. But both offer different ways to approach the internet; one as singular files to be downloaded; the other as unstable information to be scraped/filtered/processed. And depending on our use-case, we may swap between either of the two. We might even fork a branch of either code and write our own modified version of one.
A grand unifying theory of "getting data from the internet" would say - "well, it depends." There are design patterns for a reason; only patterns that we choose to apply in action, and no truths of an internal structure that a problem carries with it to the table. The question of 'solving a problem' is not of understanding its innate internal structure and engaging in an definition-oriented exercise to do so("is it an animal, vegetable, or mineral?"), but by choosing one of an infinite number of patterns, always arbitrary, always constructed, in order to further do things with it.
In other mental terms, I might have phrased this as "slicing through the problem in different ways" -- given different kinds of knife, every problem is sliceable in different ways. Or in architectural terms; there are an infinite number of section cuts possible through a building.
For example: an group apartment always has dirty dishes in the sink.
the "character" knife: Who is lazy and who is not lazy in the apartment?
the "role" knife: Whose job is it to make sure that the sink is clean?
the "repercussion" knife: Why is it bad that the dishes are in the sink?
the "difference in judgement" knife: Are the dishes in the sink dirty and do they really have to be washed?
the "time" knife: How long does a dish have to be in the sink in order to be a "dirty dish" as opposed to a "soaking dish"?
the "space" knife: Where should the dishes be?
the "efficiency" knife: Is it possible to make the dishwashing more efficient, leading to fewer dirty dishes?
the "technology" knife: Is it possible to automate the dishwashing by getting a dishwasher?
the "systems thinking" knife: What factors influence whether or not a dish gets washed?
the "spatial thinking" knife: If you had a deeper sink, or a shelf inside the sink, would it even matter if you had dirty dishes?
the "desire" knife: Why do people not want to do the dishes - can we offer a reward for doing the dishes?
the "psychoanalytic" knife: Can we read a psychological narrative in the fact that the dishes are left undone - for example, people refusing to engage in, or rebelling against domestic activity?
the "identity history" knife: Are certain people not used to doing the dishes because they were brought up in environments where servants did the dishes, or where their mother did the dishes?
the "information" knife: Is it possible that people forget that they haven't done their dishes?
the "community" knife: What about the environment makes individuals feel less accountable about their actions?
Depending on which knife you use, a different pattern could be applied, resulting in different solutions:
the "character" knife: Find out who the lazy person is, and tell them to do their dishes.
the "role" knife: Create a dish-washing role, and rotate it every week.
the "repercussion" knife: Figure out how long dishes can stay dirty in the sink, and let them.
the "difference in judgement" knife: Dishes are barely washed/rinsed, since small flecks of food won't kill.
the "time" knife: All dishes are soaked for 24 hours to make cleaning easier, so we should be okay with always having dishes in the sink.
the "space" knife: Dirty dishes should be piled up in a separate area, and not the sink.
the "efficiency" knife: Store all the dirty dishes and do them at once on the weekend.
the "technology" knife: Get a dishwasher.
the "systems thinking" knife: Ask these questions about the factors that influence the dish-washing.
the "spatial thinking" knife: Make a deeper sink.
the "desire" knife: For each dish done, reward the person.
the "psychoanalytic" knife: Talk about the importance of dishes and how cooking/eating devices are a large part of a hunter-gatherer's identity, this placing dishes on a different axis than on one of domestic vs. professional activity
the "identity history" knife: Create narratives that highlight the importance of doing dishes regardless of identity
the "information" knife: Create dishes with each person's name on it that can clearly identify who should be washing each dish.
the "community" knife: Have more group meetings / parties / paint a community mural that makes people feel like the space is collaboratively used by the community.
--
All specific examples, all helpful. To go back to my initial point; being specifically wrong is important. Only when being wrong is on the line can any movement / action happen; I.E. it's not about being right; it's about being in motion, transition, operation, flight.