The future by way of the past

There are a num­ber of recur­ring tropes and themes in my social net­work: indi­vid­u­al­ism, col­le­gial­ity, open-​​minded research, appre­ci­a­tion of auton­omy, geek­i­ness. Plus a few others.

For maybe nine months a num­ber of us have been micro­cowork­ing at Primo Cof­fee in Ann Arbor every Wednes­day, and meet­ing Fri­days as time per­mits in the lounge at Pure Vis­i­bil­ity. Micro­cowork­ing (or µcowork­ing) is not Cowork­ing in the tra­di­tional sense of cubi­cles and sen­si­ble desk space and a mail drop, the way the peo­ple on the Coasts and Europe would have it. We all sit and work in cafés any­way; now we sit every Wednes­day and work together in the same café. That’s all there is to it.

That and much more, of course. Because sit­ting together, we are one step closer than a mere Twit­ter net­work, an iChat. We’re in the same room, at the same table, and when I see some­thing I can tell my friends about it imme­di­ately; when some­body wants an opin­ion they can ask it imme­di­ately; when one of us has an Andy Hardy moment and says, “I know guys! Let’s start a com­pany!” we do it. Right there.

It works well. It’s low-​​impact social net­work­ing; no busi­ness cards required, no ele­va­tor speeches, no push to expand into The Next Google, no striv­ing for VC. We’ve escaped all that crap.

You can have our share. Really. No, please, go right ahead.

We were just going to throw it away.

For a few weeks now we’ve been start­ing “Work­ing Group” meet­ings as well. Maybe we don’t know what it’s for, and maybe we do, but innu­mer­able µcowork­ing con­ver­sa­tions on the theme of “We ought to do some­thing with that idea,” have led to a group of the same folks, plus some extras, who just want to make some stuff together. We all have these projects: I want to put books online; Dan wants to show peo­ple how their stuff came to be; Bob wants to make Zig­bee work for us (robots!); Laura wants to do laser graf­fiti. And so forth.

We have all these con­ver­sa­tions, and we all end them by say­ing, “But I can’t do that by myself. Some­day, when I have time.”

This when we’re all sit­ting on our col­lec­tive asses surf­ing in a café, mind you. “When I have time” is code for “not by myself”, at least in many cases.

We met once last year, and once so far this year, and now the reg­u­lar ses­sions begin for real. We’re work­ing out the details of how things get done as we proceed.

But as a meta–design spike, four of us have already started exper­i­ment­ing. We’re doing a sim­ple genetic pro­gram­ming project together. I get to pol­ish my GP class notes (I teach a class now and then, and want to start one up here in town in the com­ing months); some of the other folks get to explore the poten­tial and enhance their grasp of the Way Things Will Work; and we all get to try some kind of weird Agile Research thing out. We’re try­ing to do XP (1.0) as much as pos­si­ble; we’re slip­ping a bit on Whole Team, and some of us are learn­ing Python on the fly, and I con­fess we put the cart before the horse a bit by spik­ing before we com­pletely wrote out story cards… but I think we’re doing what we can to com­ply with stan­dard XP as she is spoke.

Now X“P” as a research method­ol­ogy is an inter­est­ing prospect, frankly. There are some unan­swered ques­tions about direc­tion and explo­ration vs. exploita­tion I’m itch­ing to address… but we need to prac­tice a bit first.

So what we’re doing is this: we’re re-​​implementing the Push3 lan­guage in pure Python. Push is Lee Spec­tor’s almost-​​unreadable sub­strate for strongly-​​typed genetic pro­gram­ming with recur­sion and iter­a­tion. It’s a neat academic-​​flavored lan­guage that makes sense if you squint at it.

Until you learn a bit about actu­ally doing GP. And then it becomes a tool you should absolutely have in your arma­men­tar­ium. Because Push is a lan­guage (or design pat­tern, or dessert top­ping) that gives you a lot of struc­ture in evolved pro­grams (auto­mat­i­cally gen­er­ated algo­rithms) that tra­di­tional S-​​expression based genetic pro­gram­ming fails to offer.

So Bob and Brian and JP and I are sit­ting down peri­od­i­cally and re-​​writing Maarten Kei­jzer’s descrip­tion of Push3 in python, so we can (1) expand the lan­guage to solve some inter­est­ing not-​​at-​​all-​​academic prob­lems by evolv­ing novel intel­lec­tual prop­erty, (2) set up a unit tested, read­able, expand­able, dis­trib­uted ver­sion of the infra­struc­ture, and (3, once again) estab­lish a kind of base­line rap­port and method­ol­ogy for doing pure research projects in an “agile” way.

(4) with­out touch­ing C++ with a ten-​​foot pole. Sorry, Maarten. Ick. Does not want.

Now Push3 is a sprawl­ing epic of a lan­guage. Full of coun­ter­in­tu­itive stuff that makes you squint and cock your head and scratch your beard and that kind of thing. So we’re cre­at­ing a sub­set of the lan­guage: one with no recur­sion, no iter­a­tion, no vari­able assign­ment. Those are all things that are “sim­ple” in Push any­way: they’re just addi­tional oper­a­tors in the stan­dard Push inter­preter, and they don’t even do much that’s dif­fer­ent from the base stuff.

And that min­i­mal lan­guage, which we’ll use to fit some sim­ple arith­metic func­tions and a wee bit of log­i­cal function-​​mining, will be called Nudge.

Watch for more on Nudge as it devel­ops. Maybe, if I’m very dili­gent, I can man­age to scrape together a bit of a copy of Ron and Chet’s accounts of their pair-​​programming essays. Maybe we can even draw them in with us. We’ll see in a bit.

And thus tonight I am reminded of some­thing from long ago, that has some­how fallen off the Googleweb. The future. By way of the past. Push is 2004 tech. And yet it sits there, unremarked.

Look upon it, and fathom the unfath­omable dynam­ics of your life, ten years on.

2 thoughts on “The future by way of the past

  1. The short ver­sion: this is awesome.

    The longer ver­sion follows.

    There is a spike between the ones who say there is a spike and the ones who say that there isn’t.”

    Part of the innate sus­pi­cion of processes with names (that falls out of maybe some of the stuff in your open­ing para­graph) means that, hey, maybe we’re work­ing on the same project, but some of us care more than oth­ers about whether some reg­u­la­tor look­ing in would call it xp. In other words, there are metaphors, there are processes, and there is just observon-​​open-​​fire class _​doing junk_​. Mak­ing tests fail, then pass.

    So we look at cowork­ing and micro­cowork­ing falls out, arb­camp was the thing that it was, push3 has to become Nudge.

    So maybe there’s a process thing in there, too.

    But the val­ues of “extreme pro­gram­ming” — such as they are — are crappy lit­tle mon­key patches on the basic hier­ar­chi­cal, eco­nomic con­straints of projects and teams and cus­tomers and employ­ees com­ing together. And those are the con­straints we’re pick­ing at, or at least that I’m pick­ing at. So what is that “Whole Team” thing actu­ally about? We know it’s acci­den­tally about a bunch of males in khakis and blue shirts (or, local fla­vor, jeans and warm coats), but what’s it really about? Espe­cially when the “cus­tomer” is more like a “dun­geon mas­ter” — a tem­po­rary bur­den rather than a gilded throne.

    This strongly cor­re­lates, in my mind, to the ques­tion of when we do this. Is this a day thing, or a thing for night? For the week, or the week­end? At the cafe or the office? So far, it doesn’t hap­pen at my office — and not just because the con­fer­ence room still has an echo.

    Where to? What next?

  2. Pingback: Brian Kerr | links for 2008-01-24

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>