This rant, Why Should I Ever Use C Again, is a funny, irreverent, spot-on critique of a certain strain of micro-optimized thinking about software performance. Samples:

Okay, C is fast. But C is not the only fast language. It’s not even the fastest. If speed was everything, we would be (1) on a race track (2) using assembly. The C-is-fast-so-use-C crowd doesn’t know there is a clan that says the same for assembly. But, in 1980, it was clear that _slower_ C made more sense than _faster_ assembly.

Computers are really good at automating repetitive work. Every decade or so it becomes clear that it has come time to delegate to the computers some entire category of task which programmers have spent years sweating over. When this happens, it’s not because the computer can suddenly do a better job than a clever human being could, on a one-by-one comparison – it’s because the computer can do an adequate job a billion times a day without breaking a sweat. Computers keep getting faster, and for any problem there comes a point where the run-time cost of an automatic solution disappears against the development-time cost of human brainpower.

Programming language compilers themselves are an early example of this process in action. People take the notion of a high-level language for granted now, enough so that nobody uses the term “high-level language” anymore, but writing entire applications in assembly language was once routine. When I was beginning my programming career the need to think in terms of machine instructions was still common enough that every serious development tool offered some way to embed “raw” assembly instructions in your C or Pascal or Basic code. Nobody does that anymore, at all; you could still probably beat the compiler if you worked very hard at it, but it simply is not worth your time to bother.

A similar change occurred with the rise of Java, which pushed the idea of automatic memory management into the mainstream. You youngsters may not believe this, but paying careful attention to the lifetime of every last scrap of data was once a normal part of programming practice. Nobody would design such a language now: memory management is complex, error-prone, and amenable to automatic analysis – therefore it makes no sense to waste any more human brainpower on the problem. We delegate that task to the computers, which will do it in a simple-minded but utterly reliable way, and move on to more interesting things.

We’re about to see another of these shifts. As always, it’s going to start out looking like a nerf toy. How can you get any real work done with something like that, people will wonder? Where’s the go-faster button? Where are the sharp edges? The answer, as always, is that when you have a button, you have to decide whether, and when, to press it. We will choose to give up another layer of fine-grained control in exchange for the opportunity to spend our brainpower solving more interesting problems.

This generational shift is being driven by the ubiquity of multi-processor computing. Everyone has a dual-core machine now, and in two years everyone will have a quad-core machine. Meanwhile, the really big problems are being solved on server farms with thousands of networked processors. The tools we use today leave control of concurrency largely in the hands of the programmer: so programmers have to solve the same set of concurrency design problems over and over. This situation is just begging for automation. In the next few years we will see a new level of abstraction come to prominence: we will choose to give up a few old familiar tools, and in exchange we will be able to delegate the concurrency problem to our new tools.

I think I know what the recipe for this new style will be, and I’m convinced enough to spend a lot of my free time building a working example, but the details are less important than the process. A new generation of candy-coated, dumbed-down, kid-stuff programming tools are about to come down the pike. They will look limited and faintly embarrassing, but get ready to jump on board anyway: those limitations are the key to the future.

I love discovering a band I really like that’s been around for a while, then slowly eating up their back catalog. I’m listening to Psycraft’s “New Moves” at the moment, and it’s making me very happy.

New gloves arrived today, from Fox Creek Leather. The roads have been clear lately but the air is still very cold, and my hands have been getting pretty chilly in my summer gloves (I lost one of the winter pair). These are very nice, with long cuffs that pull back over the ends of my jacket sleeves.

Whistler ski trip is only two weeks away. I’m looking forward to it: I hope to go up after work on Friday, ski as many of the next nine days as I can, and come back late Sunday the 15th. This winter has been pretty much a bust as far as local snow is concerned, so I’m planning to ski hard and get all my runs in at one go.

I rode my bike to work today, for the first time since the blizzard in December. It was cold, of course, and I’d be more comfortable with heavier gloves, but with a sweater under my jacket it really wasn’t bad. I had a new chain and rear tire installed last week, and the whole machine feels smooth and happy.

This PDF slideshow introduces a concept the author calls “gradual typing” for Python. I’ve been pursuing a similar notion of typing in Radian. You can think of the notion of “type” as the information we have about a value. “Static type” is the information the compiler has about a value, and “dynamic type” is the information the running program has about the value.

From this perspective, one can see the ubiquitous ‘assert’ statement as a supplementary typing system, evaluated at run time. I frequently assert that various parameters are non-null, or that the objects in those parameters are related in some standard way; the C++ language may not include this information in its notion of a type system, but those attributes are very much part of my concept of the types I expect the method to receive. When you look at a type system in these broader terms, little islands of dynamic typing start to show up even in the most “static” languages like C++ and Java.

Wouldn’t it be nice if those ad-hoc assertions I place in my code by habit could be as much a part of the language, and have as much of an effect on the compiler’s knowledge about the values I am working with, as the built-in parameter and variable type annotations?

The Radian type system approaches something much like the linked presentation’s “gradual typing” from the opposite direction. It starts with a completely wide-open type system, where any value could have any type, then allows the programmer to limit the range of options by making assertions about values. Each assertion functions as a guard, or checkpoint; in order to continue, the given conditions must hold.

We then rely on dataflow analysis, constant propagation, and constant folding to resolve as many of these assertions as possible at compile time. The compiler can use the resulting knowledge about the content of each value to produce more efficient code specialized for that type. Each assertion condition can be resolved as either known true, in which case the assertion has been satisfied at compile time and can be omitted from the output, known false, in which case the compiler knows that the assertion cannot succeed and can report an error, or unknown, in which case the assertion will be compiled into the output and checked at run time.

Let’s make the compiler do all the tedious bookkeeping work! That’s what it’s there for. The result, I hope, will be a language which allows programs to start small, simple, and generic, then specialize over time for safety and efficiency – thus gaining the advantages of both “dynamic” and “static” typing.

My creative energy is all going into Radian lately. I’m having a ball, working deep in the plumbing – thinking about tuples, monads, type inference, garbage collection, dataflow analysis, and concurrency – but the tool itself is a long way from doing anything useful, and there’s not much to talk about here.

In the meantime, here’s a neat article which shows how to set up a makefile that automates most of the annoying dependency management. Those of you building executables on unix systems will appreciate this.

I want a portable computer and I am thinking about getting one of those cute little “netbooks”. I had to send my Macbook back when I left Real, and got a Blackberry phone as a substitute. It works fine for email and light web browsing, but I’m still stuck in my bedroom whenever I want to write code, which has become a significant fraction of my free time. I want something sleek, light, quiet, and cheap, running Linux (preferably not nerfed), with a comfortable keyboard, a solid-state drive, and reliable wireless networking. I don’t need to play videos or even music; I just need to check email, do some casual web browsing, and edit lots of source code. Anyone out there tried one of these little portables? I’d love a recommendation.

Syntax for map/dictionary/hash literals in various languages:

JavaScript: { "foo" : 1, "bar": 2, "baz": 3}
Ruby: { "foo" => 1, "bar" => 2, "baz" => 3 }
Python: {"foo":1, "bar":2, "baz":3}
Clojure: {"foo" 1 "bar" 2 "baz" 3}
Perl: ("foo" => 1, "bar" => 2, "baz" => 3)


The latest Mars-mobile is a cute little BMW 325. It’s the two-door model, red with black interior, inline-six engine. It’s automatic, not 5-speed, but it hit all my other points, and I was running out of time – so I decided it was good enough to make me happy, and bought it.

It’s in pretty decent shape for an ’86 model; it’ll need new brake pads soonish, but it runs well and all the electrical systems work.

Time to let someone else take a turn as the Guy With The Truck.

A brief but interesting post about storage allocation strategies in multiprocessing environments. I’ve been thinking about this sort of thing a lot lately with respect to Radian.

I heard back from Geico; the Mars Rover is a total loss. If it weren’t wintertime and thus ski season, I would ignore the matter for a while and just ride my motorcycle. I will most likely buy another Rover, but I’m thinking about getting an actual car instead. It would have to be something small, snobbish, and fast – though I could swap “fast” for “runs on biodiesel”.

Tonight I’ll be playing a couple of live-PA sets at a fundraiser for Jerboa Dance, supporting their upcoming show “Back from the Brink“. It should be similar to the “accelerant” event I played last year: downtempo grooves with a little bit of glitch. The event is at Hengst Studio (1506 Franklin), starts at 7, and costs $25. Silent auction, preview of the performance, wine & mingling – come on by and check it out.

I’m back. Christmas visit with my family was busy and satisfying: there was something going on every day, and I had a chance to spend time talking to each person. We had a big family dinner on Christmas Eve, with presents and songs and dancing after, and a laid-back buffet-style Christmas Day; Christmas evening we all went over to Olivia’s apartment, played on Carolyn’s dance pole, and watched a “Christmas Carol” movie.

Friday I spent a few hours trying to upgrade Mom’s computer, with no success. Looks like she needs a new disc drive. In the evening we went down to Midtown for a night out swing-dancing, to celebrate Carolyn’s birthday. I was feeling pretty tired but everyone danced and we had a good time.

Saturday, Ava and I went to San Francisco with MJ and spent the day wandering around being tourists. We had chowder bread bowls at Fisherman’s Wharf, taxied over to the Castro and browsed the shops, then hiked up to Haight and nosed around the hippie strip. Eventually we headed for a restaurant where MJ’s friend Debbie works and killed an hour sipping scotch. I like SF; I haven’t been there in a few years but it still feels familiar and comfortable. I could happily live there someday.

Sunday I worked with Joel on his new robot kit. We started by practicing some splices with his new soldering iron, then got going on the kit itself. We had a mishap right at the beginning, when we soldered the IR-detector eyes in on the wrong side of the board, and ruined one of them trying to tease it back out again, but after that things went smoothly. Joel has never soldered anything before, but he has been interested in electronics for a long time, and I hope he’ll be able to finish the kit and build other projects.

After that I met up with my dad for a couple hours of volleyball at the gym near his house. It’s a regular thing; thirty or forty people show up and play all evening. We cut out early and headed for a brewpub downtown to spend a couple hours catching up.

Monday, Andrew picked me, Ava, and MJ up and we headed for the hills. I’ve gone skiing / boarding with Andrew and Mike every year for the last several; we decided for some variety this time and went to Sugarbowl instead of Sierra-at-Tahoe. The snow wasn’t great, but the weather was nice, and we got a decent few runs in. I still love my new skis. MJ and Ava signed up for lessons – MJ had a great time but Ava unfortunately injured her foot and had to bail out after half an hour. Not such a good day for her.

I spent today driving home, in one straight shot: we left at 8:45 this morning, and arrived in Seattle – 750 miles, half a dozen fuel/water breaks, and one dinner stop later – at 10:15. I was feeling pretty stiff by the end but still alert. I think yesterday’s ski trip actually tired me out more. Last time I tried to drive the whole distance in one go I was in an ’86 Suzuki Samurai – the nice little Pontiac rental I drove this time was vastly more comfortable.

Tomorrow I’ll go back to work. In the evening, I’ll be playing an hour-long set – improv downtempo electronica, live-PA style – at the Offspring New Year’s Ball. I’m doing the 10 PM shift so I will have plenty of time to enjoy the party afterward. I’m not sure I’ll make it all the way to the 11 AM brunch at the other end, but there should be plenty of music and dancing and catching up with friends, and I’m sure it’ll be great.

Seattle has been buried under unusually heavy snowfall for the past week. The fact that there is snow at all is noteworthy; a series of snowstorms like this, piling up inches of snow, is something nobody has seen since the 1950s.

I crashed my Rover last Thursday, sliding out of control down a back street on Capitol Hill. Four-wheel drive and fancy electronic traction control do absolutely nothing when you’re driving on packed snow too slick to walk on, and it’s hard to completely avoid routes involving snowy hills when you live on the side of one. We weren’t going very fast, so nobody was hurt, but I did some damage to a parked car and rendered my own vehicle basically undrivable. It’s in the shop, but with Christmas and New Year’s approaching I don’t expect to see it again for a couple of weeks.

In about an hour, then, I’m getting into a rental car, swinging by downtown to pick up Ava, and leaving for California. Highway cameras and DOT reports suggest that I-5 is clear all the way to California, so I think we’ll make it in time for Christmas with my family. I have a shovel, some planks, and a bag of kitty litter in the trunk, just in case, and spare blankets and a sleeping bag in the car.

I’m looking forward to the visit. We’ll be back for New Year’s.

I don’t have a particularly good explanation for the slow pace of my journal updates lately. I’m more stressed and less satisfied than I used to be, but on balance life is still pretty good. I just don’t have the time, anymore, to sustain the kind of steady creative burn and extroverted social life I had when I was working from home at a job I had long since mastered. I just haven’t felt like much of a rockstar lately, and a lot of my inspiration to write here comes from thoughts about or progress made on creative projects.

Radian has become my primary creative outlet; working on it in my free time seems to provide enough programming-related stimulation to keep me from grinding to a halt at work. It is a big project, though, and I’m sure it will be at least another year before I have anything ready to call “finished”. The core design has been coming together well, so I am starting to feel more comfortable talking about it. Perhaps I will start digging into that project in more depth here.

The weekend started badly – getting home from work I spent an hour in backed-up traffic, on my motorcycle, in the rain – but after I got dried off and warmed up I ran a few errands and then met up with Ava, Adam, Doug, Michael, and eventually Jacqueline, and had fun banging around downtown. We talked and relaxed and unwound and drank a lot. It was good.

Next morning I started plowing through my to-do list. It felt good and I got a lot done. I eventually met up with Ava and we wrapped some Christmas presents. My family started doing a gift-exchange a couple of years ago – there are so many of us that all buying presents for each other is sort of ridiculous. Joel is still young enough to appreciate a heap of presents, though, so we’re each getting him something. It’s so much fun to shop for him; he’s interested in all the same things I was excited about when I was his age.

Saturday afternoon Cat organized a last-minute “let’s hang out in the basement and light a fire and drink wine” thing that turned into a really nice, happy, warm little party. Eventually she decided to call it an early birthday party, so we stuck candles into a plate of cookies and sang a round of “Happy Birthday.” Snow started falling around nine and continued for hours. We opened up all the curtains and watched the world turn white. Barry had plans to go skiing the next day, and planned to leave early – he ended up staying up til three with the rest of us, but along the way he talked me into joining him. So, a couple hours after going to bed, I bounced back out again, threw on all my gear, and headed for Crystal.

It was a terrific day: still early season, of course, with rocks and twigs peeking through here and there, but almost no ice, and after last night there was plenty of powder. Barry, Michael, and I showed up at the lift not long after they’d opened it, headed for the top, and started skiing. High winds made the peak unbearable – cold enough that Michael and Barry both developed some frostbite – so we spent the day on the mid slopes; stretching ourselves out and letting our muscles remember how it all works. We crossed paths with Chris and Colleen all afternoon, and eventually ran into Kevin, Elan, and Brady at the lodge, but mostly it was the three of us.

I am happy to report that I am no longer limited by my equipment. The new skis will go as fast and hard as I can push them, and they clearly have more to offer than I have skill to use. They go fast on the groomed runs, don’t bog down in the powder, carve easily, and don’t flop around on the rough stuff. This season it will be time to focus on proper technique. Maybe I should look into taking some lessons.

The air is painfully cold and the roads are icy, so I’ve been driving my Rover to work. I wonder how much of the winter will offer weather conducive to motorcycling?

PDF slideshow presentation by John Osterhout of Sun Microsystems: Why Threads Are Bad. It’s thirteen years old, but its information is current as ever.

People gave us a lot of hassle for not providing a simple, built-in preemptive threading class in REALbasic, but I remain convinced that we made the right decision. RB’s event-loop-driven architecture meant that very few operations actually needed to use threads – they are necessary only when some event needs to kick off a long-running process, while leaving the UI available for further interaction. The simple, non-preemptive thread class we offered was carefully constrained in ways which eliminated many of the tough problems usually encountered in threaded code. Threads would only yield to each other on loop boundaries: during the body of the loop, or in code which did not contain loops, you could ignore concurrency issues altogether.

It is hard to reason about your program’s state when you cannot predict when or in what order state changes will occur; since threads share memory, and preemptive threads can interrupt each other at any time, you have to be ready for anything to change at any time. This is complicated even with a single controller and a single worker; add in more threads and it rapidly becomes what a computer programmer might call a “hard problem”.

If we model threading as a network of independent, non-memory-sharing systems, instead of a group of mutually interrupting, state-munging threads, we can handle concurrency much more easily. The best model for multiprocessing is almost always a group of processes, not a group of threads. Each process has its own memory and manages its own state; the processes communicate with each other, and usually with some controller, over serialized, asynchronous communication channels. They may share read-only access to a common data set, but all modifications must be sent back asynchronously.

This allows each process to manage its interactions on its own terms. It updates its state when it is ready to update its state, and does not have to worry that some other process will step in and make its own changes.

There is more overhead this way, so in theory it’s not as fast as an equivalent multithreaded solution. If a host app has to break a problem down, parcel out bits of the task, and collate the results, that’s work which a threaded solution would not have to do – not to mention all the overhead involved in serializing objects to send over the pipe. But the programmer who starts with threads is in for a lot of slow, painful debugging, where the programmer who starts with processes will have time to optimize if necessary and get on with the next thing.

I had a plan for multiprocessor support in REALbasic. If I had stayed on with REAL Software, my solution would not have been to add a “PreemptiveThread” class in parallel to the existing “Thread” class, but to implement something completely different. A new project-item type, which we might call “Subprocess”, would have allowed you to effectively embed a little console app into your larger project. Creating and invoking a new instance of this class would spawn off a subprocess, which the OS kernel would then schedule on any available processor.

The limitation, of course, is that this would genuinely be a separate process. It could use the same classes as the host app, but none of the same object instances, and none of the same static/shared variables. Instead, you’d send data back and forth, as though on a socket: each subprocess would be automatically wired up with a pipe-style communications channel back to the host app. Some basic serialization primitives would let you send the contents of arrays, dictionaries, and structures back and forth, triggering an event in the receiver. This, I think, would have directed people straight toward the best solution for multiprocessing, instead of giving them primitive, low-level tools they’d have to use to build their way up from scratch.

While that would have been the right solution for REALbasic, I’m taking a very different approach with Radian, where all objects are immutable: threads can freely share object references, but once you have a reference to an object, nothing that any other thread ever does can change it. This allows threads to share data, eliminates the need for serialization and asynchronous pipes, and eliminates the overhead involved in starting up a process, while retaining most of the benefits of the process-based architecture. When it is time to merge the results back together, Radian allows sharing via transactions: an architectural style that should be familiar to anyone who has ever worked with a multiuser database. The transaction, from the point of view of the rest of the program, will happen atomically. Data will always stay in a consistent state, it is easy to see where external state may change, and it is thus possible to write code that composes nicely around those points.

Brady and Serena came back from their trip to east Asia today. Ava and I spent a few hours this morning cleaning, then I took off to run some errands while she waited to give them back the keys.

My first errand was a trip to REI, where I picked up my new skis and boots. I’m excited. None of the local resorts are open yet, but the season ought to kick off pretty soon now.

Back at home, I spent a couple of hours working on my motorcycles. The FJ600 came with a cut-down front fender that looks sassy but kicks up a lot of spray when riding on wet pavement. The water splashes back against the fairing and then spills out along my legs. Even wearing leather pants, this is a bit much. I found a new fender on eBay a couple of weeks ago, so today I installed it. Turns out you’re supposed to take off the front wheel before replacing the fender. I neglected to do this, but after a lot of twisting and heaving, and after deflating the tire, I did eventually manage to get the new fender installed.

I also put a new left-hand control unit on the Maxim, to replace the one I broke when attempting to replace its choke cable. The new control cluster came with a choke cable, but it turned out to be as worn-out as the one I was replacing, so I’ll have to keep looking.

The evening is winding along. There are a couple of events on tonight, but I think I’ll stay in, catch up on laundry, and work on Radian.

I spent the afternoon working on the hoodie. I haven’t completely settled on the cuff design, since I want to hide some wrist pockets behind the fur, but I finished everything else. It fits well, the sleeves are nice and long, and the hood is heavy and comfortable. It’s just a basic sweatshirt, really, but the fur trim catches the eye, and I feel good wearing it. I shortened the zipper so that the top couple inches of the center seam hang open, which helps keep the hood from feeling too much like a tunnel. The hood is nice and deep so you can pull it clear over your face if you want. When I put the lights in, this will make for a bit of a Jawa effect.

The current sleeves are still a bit too narrow around the cuffs to fit lights comfortably. I am going to bell them out a bit when I add the fur trim, but I don’t think it will be enough. I should actually build the slimmer light-pack design one of these days so I can try it out – the legging-style light packs, based on 9V batteries, are too bulky to use in the hood, much less the sleeves.

Winter approaches and it is time for new skis. I took my first lesson fourteen years ago, and have been skiing avidly since I moved to Seattle, but I have always made do with older, second-hand equipment. It’s better than nothing, but as my skills have developed over the last couple of years I have definitely felt like my gear is holding me back. After last season I decided enough was enough; I demoed six or eight models, figured out what I liked, and decided that before I started skiing this winter I would go buy a solid pair of brand-new skis.

Today was the day. Ava and I went down to REI first thing this morning and I headed straight for the ski department. I considered a pair of Völkls but ultimately stuck with my original choice, the Salomon x-wing hurricane, 180cm. It’s a solid, versatile all-mountain ski, and while it might be a little challenging right now, I expect to grow into it by the end of the season.

Can’t wait to try them out.

Adam and I met up at the Rocket Factory after work. He had intended to pick his bike up and get ready to work on the valves, but the shop had closed early. Instead he mixed up some cement and continued patching up the hole in the concrete pad under the sewing table.

I started in on the latest prototype for the Martianwear hoodie, using a basic front-zip design with raglan sleeves. I generally use set-in sleeves, to emphasize the shoulders, but this piece will already have enough going on up top with its oversized, fur-trimmed, parka-style hood.

Adam had plans to tend bar at Sahni’s absinthe-themed birthday party, so we downed tools a little after nine and made our way to Capitol Hill. I was tired and didn’t stay long, but it looked like the birthday girl was having a good time. It was an intriguingly bohemian bunch and I would like to have been more social.

The Mars Reconnaissance Orbiter has discovered sizable deposits of buried water ice.

How to be a Programmer: a solid, comprehensive article on useful strategies of thought and behavior for computer programmers.

This is a very nice picture of Mars, taken by the ESA’s Mars Express spacecraft.

I’ve been playing with a DJ program called Mixxx which mimics a pair of CDJs and a mixer. I have a mixer, and have been thinking of getting a D2 Director in place of decks; Mixxx is basically the same thing but all done in software. I’ve always tried to avoid being one of those laptop jockeys, as a stylistic principle; but times change and I’ve been letting some of those stylistic principles go.

The FJ600’s speedometer has been unreliable since I bought it. The whole gauge cluster is in pretty bad shape, plastic cracked in several places. I bought a replacement gauge cluster last weekend and spent a few minutes installing it this afternoon. Everything seems to work, so that will be a nice improvement. I tried to replace the Maxim’s choke cable, too, but the replacement cable was a few inches too short, and I broke part of the choke lever trying to put it back together. Oh, well… that bike has been nothing but a lot of work ever since I got it.

I’ve been thinking for months now about another item for the “martianwear” line: a fur-trimmed hooded sweatshirt with LEDs. I made a prototype out of wide-wale corduroy and some really nice red fur, which effectively illustrated a couple of major problems in the design. Adam and I bought an assortment of sweatshirts at Value Village last week and spent an evening figuring out how they worked, and I have a new idea which I hope to prototype next week. I bought some fur and cotton fleece today; it’ll be solid black with red lights, like the leggings, but other color combinations will be easy once the design is settled.

Job satisfaction remains elusive.

The legendary Seattle wet season has arrived in earnest, but I am finding that even in the rain, riding a motorcycle to work beats driving a car. I’m safely covered in neck-to-toe leather, so my clothes stay dry and I stay warm (though my gloves could use some improvement, and the over-pants could be a couple inches longer – I’m thinking about adding neoprene cuffs).

The rain definitely adds to the inherent risk, but it’s dangerous in ways that you can feel immediately and make allowances for. In the Rover, with its magical computerized brakes, powerful auxiliary lights, all-around air bags, and battle-tested bumpers, I just plow on through the crud and don’t really change my driving style at all. On the bike, though, I’m always keenly aware of the weather, and cannot help but ride accordingly. I can feel, immediately, how the traction changes when the roads are wet, and I take corners much more slowly and carefully. I know how general visibility changes, and leave a lot more space for other drivers who can’t see me. I can feel how the stopping distance changes, and brake earlier and more gently. But I don’t have to think consciously about any of this; you can feel it directly in your body balance, in the way the machine responds, in the way the other drivers react.

I actually like having to deal with the risk. Driving a car is not usually hard enough to demand my full attention, so my mind frequently wanders. Motorcycle riding, though, always pulls me down into the immediate experience: I have no choice but to be present, aware, focused. It forces all my background threads to spin down; I stop planning and worrying, and relax into the flow of the road and the cars and the ride. When I step off the bike, my mind is clean and quiet and positive, ready for the next thing.

Why are all the programming language geeks suddenly obsessed with “DSLs”? What’s the point? Seems to me like a massively over-engineered way to design a plain old library API.

I don’t clearly understand the details of the case, but this appeals ruling creates a new test which significantly reduces the patentability of business methods and software architectures, and that can only be a good thing.

Dawn, Ava, and I went over to the shop last night to work on costumes. I spent a while fixing up the serger, then proceeded to rip through a bunch of seams with it. That thing is *fast*. I had hoped to get the top of my outfit done, but ended up spending most of my time helping Dawn with her muppet garb. Dawn’s friend Naurry came by with beer and hung out for a while.

I rode the Maxim to work today. It ran fine and felt good, but when I pulled to a stop, there was hot oil all over the left side of the engine and down my pants leg. The valve cover gasket leak is not only not fixed, but actually worse! I’ll take it back to the shop after work. Oh, well. It’s getting there, eventually.