Fors Clavigera

I don't want gay marriage to be the only goal. It's a start at some kind of justice, but I also want justice and respect for the leather dykes, the transvestite hookers, the truly outrageous and transgressive. Not tolerance. We tolerate bad things because tolerance is the lesser of two evils. I want respect and admiration for those who are creating themselves anew, through all the pain and glory of rebirth.

Addison and Steele wrote The Spectator for, and helped create, the emerging coffeehouse culture of London in the 18th century. It is still read because it's damn good writing.

They wrote it daily for a couple of years, then went on to other pursuits. Broadsheet burnout.

It was a blog on paper, distributed via the emerging popular communications channel of the day.

See the Spectator Project

If you look at your lover and see yourself, your vision is obscured.

If you love your lover in how they are similar to you, your love lacks respect.

Nor is love for difference a good thing. If you love your lover for their strangeness, you are seeing them as an adjunct to your life, an accessory.

Love your lover for who they are, complex, complete, self-created, seeking, searching.

Sex is like dancing: creating art by merging body and mind. Kinæsthetic art.

A performed art; transient, ephemeral.

Sometimes more structured, sometimes more free-form. There is sex that follows known and agreed patterns; there is sex that surprises. Sometimes the best dance has surprises within the constraints of a structured form; sometimes the best sex is not spectacular or newsworthy.

Sometimes dance is bad; sometimes sex is bad.

When they're good, though, they knit together mind. body, and soul in a glorious way.

---

PS: Rather far from anything John Ruskin would approve, I'm afraid.

Only where love and need are one,
And the work is play for mortal stakes,
Is the deed ever really done
For Heaven and the future's sakes.
[from Robert Frost, "Two Tramps in Mud Time", 1934]

What's the difference between loving and being-in-love?

What does love have to do with need? There's this awful word, "needy"; I have an idea what it means, I own up to being needy at times. I think it's an awful word because it implies that to need is bad, and I don't think that that's the root of the problem described as "neediness". I think the root of the problem has more to do with power and control.

The behavior twist called "neediness" is, I think, better described as an attempt by one person to extract their salvation from another, in the absence of consent. It comes from fear and pain; it leads quickly to a downward spiral; it becomes a pattern of unuseful behavior because it does not solve the fear and pain -- it can easily get to be a stuck pattern, obstructing the clear thought necessary to find a solution.

I take this thought from Dworkin via Figleaf: not until no really means no, and maybe really means maybe, can yes be free. This applies equally in the emotional sphere as in the sexual one (a sexual sphere? how roly-poly!): emotional blackmail will not pay off.

The cure? Well, there's always a chance of finding interlocking neuroses by blind luck, or by a suitable application of the "Prince Charming" and "Sleeping Beauty" myths. We call it "falling in love" mostly in the magazines.

I think the fear and pain behind "needy" come from scarcity thinking -- the feeling that there is a limited and insufficient amount of love that exists. If we feel like that, then we tend towards grasping and clutching. The counter is to engage (wilfully) in abundance thinking -- there is an abundance of love, and ever-growing. One way to make that concrete in your life is to give, to yourself and to others, as if it were true.

Another idea is clear and explicit negotiation. The BDSM communities have learned to negotiate clearly about limits; consent freely given. It's more difficult to do this in the emotional sphere, for many reasons: it's harder to see emotions, it's harder to reach the common understanding. Also there's a lot of cultural message that tells us that our emotions are beyond our conscious control: we "fall in love", which is by definition involuntary. I think that's not right, I think that our emotions are no less a choice than is our vision. I'd rather say "leap into love" than "fall in love"; I'd rather take responsibility for my whole self, not imagine that my self is my ego, washed helplessly by the overwhelming tide of my id.

There should be no shame in making a conscious decision about a relationship, nor in using an emotional safeword to indicate a need to take extra care, to re-open negotiations. And consciously-chosen love is not less true than the involuntary, imaginary, kind.

Every human needs to love. Every human needs to be loved. Those needs can be met, without self-deception. You don't need to trick yourself, or anyone else.

Labels: consent, love

The art market has created a sad disrespect for old material. Me, coming from folk music & dance, I think the old material is the best; it's been honed and perfected to suit us people very well. But it doesn't create much in the way of record sales, or work for reviewers or culture pundits. For that, you must have the new improved exciting novelty thing.

Thinking about this helps me understand innovation in open source software. I was worried for a while that open source software is often just a re-implementation of commercial software. (Calm down, calm down, I know it's not universally true. But it is mostly true, yes? Linux is a re-implementation of Unix, right?)

But innovation is not the only criterium for goodness. Liberty and community are also good criteria; they may not fuel the stock market, but they might fuel your neighborhood. And it seems to me that only with open source and community-developed software can we achieve the kind of gradualism characteristic of the "folk process". I think at the root of the folk process is the belief that the material belongs to us all. There are some more skilled at changing and adapting it; and there will be people who have special affinity or skills for one part of the material ("Mary's song"), and others who will have the skill and desire to take the visible lead in the work for community. But the ownership rests not with the individual, but with the community.

Victorian art and social critic. Christian enough to give away his inherited wealth. Wrote lovely convoluted prose about the connections between art, economics, morality, and consumption.

Perhaps bugs are a necessary evil of the economics of software development; perhaps market forces will continue to drive feature change and improvement at a pace that overwhelms maturation. More mature areas of technology, while still offering opportunities for improvement, generally have learned to avoid the biggest pitfalls. And that, I think, is a useful way to think about bugs: as an opportunity for learning. A bug is feedback about your process. If you don't pay attention to that feedback, you've wasted an opportunity to learn; you can't afford to do that very much. In this analysis, "bug" means precisely a development process fault which leads to the implementation of unintended or undesired behavior. It is possible for developers to abdicate all responsibility for requirements analysis to some external agency, which would reduce the previous phrase to "unintended and undesired behavior"; however, our best current understanding is that we serve our customers better by integrating the intention with the implementation. The code is not separate from the specification, and we can best learn about the customer's needs by delivering code to them and listening to their reaction. In fact, much of what we do in software development is to learn. We learn new languages and libraries, we learn new customer's requirements, we learn new buzzwords. Also, in debugging and maintenance, we learn what mistakes we've made. We learn to avoid those bugs in the future. There are two benefits of catching bugs as early as possible: one is that it's a lot cheaper to fix a bug earlier rather than later. The other is that, by catching a bug earlier, we tighten the feedback loop and make the learning more effective. Much of modern software development, from developer-driven unit testing to IDE's with syntax and error highlighting, has the beneficial effect of providing earlier and better feedback to the developer, to help their learning. I don't know how to automate higher levels of feedback. A compiler can, with a statically-typed language, catch syntactic and "semantic" errors. We are, I think, feeling our way towards processes and cultural mechanisms that enhance feedback at the higher semantic levels. An engaged user community, able and willing to provide feedback on partial releases, can give feedback on misunderstood and evolving requirements (which is truly semantic). There may be a missing level in the middle. Most of the bugs I've committed over the last decade, and certainly the hard ones, have been due to design failures -- an unclear partition of the system that made it hard to implement some particular piece. The bugs showed up in the hard module, but that module was hard due to design problems. Refactoring helps with this, when used to re-shape the code according to an evolving understanding of the structure of the program. So does shared ownership of the code, so that problems that show up in one section of code are not isolated as one person's problem. Global improvement may have to be at the cost of added complexity of some local sections of code; shared responsibility makes it easier to make the right decisions in those cases. This is a cultural, not a technical, question. I don't think that automated tools or heavy formal defect-tracking processes have proved their worth in this arena; un-read and pro-forma meetings have little effect on behavior. We need a culture of continuing improvement, of dissatisfaction with "good enough". Formal methods can help foster this culture, and can be useful as a way of recording conversations so they need not be re-created from scratch; they can also disguise the real benefit and masquerade as improvements when they are really mechanisms. The best answer that I have is that talking about bugs helps. Let's not fix our bugs in silence and shame. Let's shoot the breeze about them; let's tell war stories; let's value our bugs as feedback and as chances to think and talk about what our program design should have been and can in the future be.

If Java had a well-designed exception hierarchy, with

• a well-understood fixed structure
• and well-defined and constrained extension points

the this need not be so. But as it is, any program that uses a combination of external libraries has to deal with several different exception hierarchies, and with nested and hidden exceptions, and so must be prepared to both handle and throw RuntimeExceptions. I wish it were not so. I wish that Exception were partitioned into RuntimeException and DeclaredException, so the idiom

 try {
  ... stuff
 } catch (Exception e) {
  if (e instanceof RuntimeException) {
   throw (RuntimeException)e;
  }
  ... deal with resource problem
 }

could simplify to

 try {
  ... stuff
 } catch (DeclaredException e) {
  ... deal with resource problem
 }

The trouble is that exception types, unlike other types, are global, because they cross boundaries. It is a good thing to invent new types (classes) to make concrete the kinds of things your new program can do; each Java package is a domain-specific language. But it is a bad thing to invent new exception types, because that structure affects the structure of every program that uses your package. Much better to have a common, well-designed exception hierarchy so that everyone knows, without new learning, which exceptions to expect. Here's one criteria for a well-designed exception hierarchy: when writing a program, it is obvious what kinds of exceptions should be thrown, and when the standard classes will serve, and how to extend them if more detail is needed. The present hierarchy does not come anywhere near that standard. It has very many too many classes, not enough nesting, too many ambiguous exceptions, and unclear rules on when system exceptions should be re-used, extended, or avoided. It obviously "just grew", which leaves all other Java programs to muddle through on the same wobbly foundation. Part of this muddle is the use of RuntimeException to pass information through a library or middle layer, or to wrap an exception that was unanticipated by the library designer. If there were a common exception hierarchy, the library designer would be much more likely be able to anticipate what exceptions would legitimately arise in the use of the library. Not universally, however; a general-purpose interface (like Runnable, to pick an extreme case) must cope with arbitrary exceptions. This forces any declaration up to the top of the hierarchy; in fact, either up to Exception, or (as proposed above) to a sensible partition of Exception into RuntimeException and DeclaredException. It's possible, but too hard, to set a handler for exceptions. The way to do it nowadays is to extend ThreadGroup, overriding the uncaughtException method; clearly not an everyday sort of thing to do.