The proof of learning is knowing.
The proof of knowing is teaching.
The proof of teaching is another’s learning.
The proof of learning is knowing.
The proof of knowing is teaching.
The proof of teaching is another’s learning.
There has been an interesting little tempest in a teapot in the Free Software community, which has resulted in some blog responses:
I have a slightly different perspective on this. I do not stand up for Stallman, because he has no need of my support in this regard. Stallman is perfectly capable of standing up for himself, but seems to consider it beneath him to spend time on it. Instead, he spends his efforts standing up for Free Software.
He’s not some kid to feel sorry for, he’s a fucking MacArthur genius. He invented Emacs. He wrote the GPL. He founded the Free Software movement. He’s taken on huge corporations and tyrants and all other manner of adversaries (and friends) with their slings and arrows affecting him like water affects a duck’s ass. He dines with presidents and prime ministers.
The origin of all this kerfluffle is some email that’s going around which makes Richard sound particular about his accommodations when he comes to town to give a FREE SPEECH. Well, let me say this: Richard stayed at my place in DC during some such speeches, and he never once complained about anything. At the time I lived in a bachelor shit-hole in a neighborhood in DC that was basically an open-air drug market. Not. One. Complaint.
A fucking MacArthur genius, sleeping on my couch, in my shit-hole apartment, and the only thing he ever asked for was fucking wifi.
I don’t stand up for Stallman, I look up to Stallman.
Way up.
If you don’t, it means one of two things: either you don’t know about Stallman, or you’re a tool. I don’t stand up for Stallman, but I look up to him. And I run GNU/Linux, and I use Free Software.
Because Stallman said so, that’s why.
Indefinite pronouns got me thinking about concurrency patterns a bit more:
That’s not all of them, but it’s a good start. Indefinite pronouns, roughly speaking, are what allows us in English to signify operations on a list somewhat less… definitely… than otherwise.
These are the parallel equivalents of the Boolean operators we all know and love. And, or, not, so, xor, nand, nor, etc. Of course many of the Boolean operators operate most naturally on a list of two items, and the indefinite operators work well on lists of indeterminate length (in some cases, literally indeterminate, in that they could work on a list that hasn’t been counted at all).
Now, the difficulty here is that with software, indefinite logic requires us to do a bit more bookkeeping than straight Boolean logic. For instance, when I do something like “a and b” with Boolean logic, I just evaluate a. If a returns true, I evaluate b. If b returns true, the whole statement is true. Everything can be done sequentially, and programmers know to rely on the short-circuiting nature of the operation.
On the other hand, if I say “all a, b” I kick off concurrent evaluations of both at the same time (even if under the covers the machinery that takes care of this runs sequentially, or optimizes to run the faster one first or the more likely to fail one earlier). If b immediately returns false, I need some way to tell a to stop evaluating, which might save considerable time and effort.
The Go programming language has some nice primitives built in for both operations (e.g. kicking off parallel computations, and for communicating between the various sub-processes). The “go” term indicates parallel execution, and the <- operator on a channel indicates communications back.
Of course with a thousand nested parallel calls, interspersed with plain old Boolean logic, there may be quite a bit of this going on, but it also may happen that most the calls get shut down before doing much.
The code might look something like this:
and(a, b, c, all(c, d, any(e, f, g)), some(h, i))
Here, the term and indicates sequential execution, the term all can be thought of as a parallel short-circuiting and, the any can be thought of as a parallel short-circuiting or, and the term some can be thought of as another variety of parallel or, which maybe doesn’t short-circuit as quickly.
I think programmers would grok this if it were presented in a reasonable fashion.
Programming languages have long-since learned to short-circuit sequential operations. In damn near any language, if I do the following:
thing one && thing two
I only get to thing two if thing one evaluates true. Even if you’re not a programmer, you probably do this in practice. Consider:
If it’s dry and warm, we’ll play outside.
Which means, if I get to the first part of the sentence, and see that it’s raining, I can just kind of disregard the rest. I don’t have to even read to see what we were going to do if it were dry and warm, because it’s not dry. We do the same sort of thing with “or.” Consider:
We’ll play outside if it’s wet or if it’s dry.
If it’s wet outside, we don’t even need to read the last part of that sentence. We short-circuit the final operation, because it’s not necessary for evaluating the truth of the whole construct. The short-circuiting pattern is important for computers, because in the best-case scenario, it can save a some of computation.
In fact, if you imagine a sentence that includes a list to be evaluated in short-circuit mode, it can save a whole lot of computation:
We’ll play outside if it’s wet or if it’s dry or if it’s cold or if it’s hot or if there’s a hurricane.
Chances are, we’re going to play outside, and if it’s wet, we save the trouble of evaluating all the subsequent possibilities.
Now, for computers, there are some downsides to doing this. For instance, it’s expected that in order to save time and in order to keep everything consistent, these operations need to happen sequentially. A && B && C is different than B && C && A, even if the operations don’t have any side effects. If there are side effects of the computations, the situation is even worse, since in one case maybe you get the side effects of A and B, and in the other you get the side effects of B and C.
If you’re not a programmer, you can skip the part about side effects without any side effects, I think.
What we’re missing is a systematic way of thinking about short-circuit operations that can happen in any order, and can happen either sequentially or out of sequence or concurrently. It’s not that there isn’t special built-in machinery to do this in particular languages, but for a polyglot like me, there’s very little overlap between one way of thinking about it and another.
The funny thing is, English has a great many ways of designating a list as a short-circuit concurrency operation:
If you’re going to the store and I give you a list, I can gesture at the list with any of these words to let you know when you can quit. ”Any” of the items means you can stop when you find the first one. ”All” means you can get them in any order, but you need to get all of them.
We should be able to do the same thing, specifying a kind of concurrency and a kind of short-circuiting in programs with the same kind of shorthand. Imagine I have a list of operations to perform, but I only care that at least six of them happen. Or I know that if any of them fail, I can stop all of them. Or if any of them succeed I can stop all of them.
I think that’s a level at which a programmer (at least the kind of programmer I am, which is to say one with more hubris and laziness than usual) should interact with a language’s underlying concurrency model.
Larry Wall put this idea into Perl 6, though I’m not convinced the semantics are exactly right. For instance, I’m not sure if I should generally be saying:
someMethod(any(1,2,3))
or
any(someMethod(1), someMethod(2), someMethod(3))
The former looks terse at first glance, but requires a lot of bookkeeping inside of someMethod that might be avoided, particularly in languages that don’t have the notion of a Junction (that’s what he calls this kind of construct) baked in. The latter looks verbose at first glance, but one can imagine cases where it would be useful to evaluate several different methods and/or put some syntactic sugar around the actual call.
I can also imagine a kind of chaining of these terms together in a way that creates a massively concurrent operation that can return quite quickly in the best-case scenario:
if any(all(none(1,0,0), all(1,1,1), one(1,1,1)), any(1,0,1))
then someMethod()
This could use the same truth-logic as usual boolean algebra, but could also short-circuit efficiently in a way that would be more difficult (or require more sophisticated machinery) if those same calls were the usual ands and ors that we would use in such code.
I don’t think the machinery for this is too complicated. It would, of course, matter how the underlying concurrency was managed. In something like Go or Erlang, it would probably be quite fast, and in something that required a heavier process for each unit of concurrency, it would probably only be worthwhile in the case of heavy computations that could benefit from the short-circuiting.
Last, but not least, I can imagine mixing this together with a bit of map-reduce. So, if I do something like:
all(someMethod(“foo”), someMethod(“bar”))
I can write these methods to also stash a result somewhere (nasty side-effect, that) but only use it if the computations complete successfully according to the all operator (e.g. none of them return false and all of them return).
[one wee little edit: if you're reading this on the front page, read the version with comments, which are worth a couple posts by themselves]
When I started college, there were a series of peer counselling sessions, structured to gently introduce the (possibly sheltered) 17- and 18-year-olds to some of the more jarring differences between a (possibly sheltered) high school classroom, and life at college. The session I remember most vividly was run by what is now called the Queer Students and Allies (QSA).
It was next door too our suite, in the RA’s living room, and twelve or fifteen of us sat around in a circle on the floor with a couple older students leading a discussion group on a pretty wide range of topics. Each of the topics seemed tailored to gently prod some of the more heteronormative ideals of the first-years. Perhaps the most thought-provoking point in the discussion was when the peer counselors asked us to go around in a circle and say, “Hi I’m so-and-so, and I’m gay.”
I think the idea was to provide a safe environment where two things could happen: people who wanted to say it in the worst way could say so in a context that felt pretty safe (after all, everyone’s doing it…); and people who didn’t want to say it could see what it felt like anyway. We duly went around the room, until one kid just wouldn’t say it. Instead he said, “Hi, I’m David, and I’m not going to say that.”
He was the only one.
He was me.
I’ve thought about that day a lot of times since then. That summer I went home and smugly told the story to a friend at church, reveling in my steadfastness and righteousness. Like a Pharisee.
Hi, I’m David, and I’m gay.
I’m sorry I didn’t say it that day. I’m sorry I subsequently bragged about it. And I’m especially sorry to have made it harder to say for the people who really needed to. I’m older now, and I suppose the stakes are lower: I’m not worried that some of the people reading this will only read that one sentence:
Hi, I’m David, and I’m gay.
After going around in a circle, the peer counselors asked, “What did that feel like?” Almost twenty years later, I’m proud to say, I felt like an ass. I felt like an ass when I didn’t say it, and I felt like an ass when I bragged about it, and I feel like an ass admitting that I thought it made me a good Christian. So, in addition to saying
Hi I’m David and I’m gay.
I have one more thing to say: if you believe in God, and you’re gay, well, God loves your gay self, too. And we’re not talking about a love-the-sinner-hate-the-sin kind of love, we’re talking about loving part and parcel. And you know what, everyone (gay or straight or neither or both) who believes in God finds that last part hard to take sometimes, so just get over yourself.
Yeah, I said it, God loves you. And I’m sorry it’s so controversial.
I think I know most of the people who read this blog. Sure, there’s the occasional drive-by-clicking from reddit or google, but for the most part, you’re my family, friends, and coworkers. It’s a comforting and sometimes surprising realization that there are more than two of you.
At a family vacation some years back, I dubbed the lot of you the Outer Banks Cosmological Society. This all happened inside my head, and in a conversation with Maggie, so don’t feel bad if you didn’t already know you were a member. It’s a loose association anyhow.
Those conversations, which I’ve had with pretty much all of you a time or two, I have come to think of as Ad Hoc Meetings. This blog, for the most part, is the Proceedings of those Meetings.
You get my drift. I’m the Editor of a Prestigious Journal, not just a Schlub With a Blog.
For most my life, and most the ten or so years I’ve had a website, this is the sort of thing I wouldn’t mention to people without winking, because, let’s face it, it’s a funny way to look at the world. But I think most of us do it a little bit, and I think we should all do it more.
So, welcome to the Outer Banks Cosmological Society.
That is all.
Emergence is a way to understand,
When hierarchy fails to lend a hand.
It’s not to the exclusion of the rest,
A complement’ry use of it is best.
A single data point cannot be used,
Emergence is when two or more are fused.
Imagine that a line’s emerged from points,
Imagine that an elbow comes from joints.
A forest can emerge from stands of trees,
A hive emerges from a swarm of bees.
Meter comes from syllabaries said,
With emphasis on tail or on head.
Rhyming also cannot be incurred,
Without the use of more than just one word.
Emergence is a way to help address,
That order can arise from such a mess,
That cosmos from the chaos can arise,
And this should not be such a great surprise.
I have learned a lot about living in a Faerie in the past two years (hard to believe it’s been two years since we came to Right Field Farm). Three or four weeks back, we lost nine chickens to the Kitsune, who just happen to number nine among the Fae. I’m unclear if there were too many chickens, or if the Kitsune were just feeling mischievous, or if this is simply their tithe, which we can expect each year. They were surprisingly brash about it.
An Unkindness of Ravens came earlier in the year, and took umbrage to my confusing them with a Murder of Crows, which is too bad, because they took one bite out of all the ripe tomatoes, just to piss me off. It worked.
Not all the Fae are emergent, or at least not all of them are emergent from a group of them. A raven by itself is not so fay, nor is a fox, it’s when they gang up and form some kind of emergence that they start being noticeably conscious in that way so strikingly different from humans. It becomes apparent they are fay, or of the Fae, however one says it correctly (which of course depends upon what one means).
The Faerie King is, unsurprisingly, a monarch, who is, of course, an emergence, and who is, of course, beautiful beyond all imagining. We planted an offering of milkweed to the monarch, and the offering was accepted.
But the Piebald Stag, Finnbel the Frog, Elizabeth Not a Chicken, and of course my four lovely children are all self-contained enough that when Other People see them, even Themselves Not Fay, they can at least be seen, if not recognized. The Kitsune, on the other hand, are only seen if believed, which proves that seeing is, in fact, believing.
The Fire Flies and the Dragon Flies and the Ant Lions and the Flight of Swallows can be seen along with all the aforementioned, but like their counterparts, may not be seen to be Fay depending upon the circumstances.
I haven’t even gotten into the Plants That Are Fay, which is probably a topic for a whole nother day, given that there are more of them then there are of the other sort, and given that it’s basically fine with me that way. I will, however, leave you with the thought that if you look at a plant, and think or say, “That’s Bananas!” and it’s not (a banana, that is; there are singularly few bananas in Maryland), then you may presume instead that it is one of the Fay Plants parading temporarily as a banana, and that you could See It.
I do not like the phrase, “eating your own dog food.”
This metaphor, colloquially shortened to “dogfooding” is one that some software developers use to describe becoming a user of one’s own software.
I don’t like it, because I don’t like eating dog food. It’s not made for me, it’s made for dogs. If I eat it, I’ll inevitably do one of two things: I’ll make it taste good for me instead of for the dog, or I’ll barf.
I don’t like it implies we should endure something odious by using something we made.
If I’m going to make software for which I am one of the users, it should surprise and delight both me, and everyone else who uses it. If I’m going to make software that isn’t for me, I should focus on making sure it will surprise and delight someone else. If I can find someone whom I genuinely like and trust, and make it surprise and delight that person, it can be a wonderful start to things.
The metaphor I like for this is family meal. At a restaurant when a chef cooks up a meal for the line cooks and the wait staff and the dishwashers, it’s called a family meal. It might not be exactly what’s on the menu that night, but it’s something close, and it’s damned fine food.
When programmers do work for other programmers, it should be like a family meal. Not like eating dog food.