robjsoftware.info

As this blog chronicles, I was in the Java world from 1996 to 2008. Near the end of the road, I got involved in the Seam and GWT communities, and I met Gavin King and Bob Lee. Gavin developed Hibernate and Seam (both wonderful), and Bob created Guice at Google (which I hear is wonderful, but haven’t looked at it much). (Sorry, can’t be arsed to link all these terms; search = your friend!)

Then we had to sell our house (housing bubble near-miss) and we decided to move to Seattle, and now I work for Microsoft and am very happy, and I lost touch with what was going on in the Java world. The last I heard, Gavin was working on the Web Beans JSR (JSR-299), collaborating closely with Bob, and Web Beans was going to be the best of Seam and the best of Guice standardized and pushing Java EE forwards. Ah, how lovely a picture!

However, I just opened my RSS feed on Gavin’s blog, and was shocked — SHOCKED — to see serious trouble in paradise. For example, quoth Gavin:

Bob, if you’re honestly trying to argue that Guice – which relies upon procedural Java code to specify dependency-related metadata – is as inherently toolable as a system that allows all dependency-related metadata to be specified using annotations (or XML for that matter), I’m just going to leave this discussion now, because that’s absurd.

And quoth Bob (replying to a different post, I’m cherry-picking not summarizing):

This is a little disingenuous. As you know, the lead of a JSR has absolute power. Most leads don’t abuse this power. They listen to their (highly representative) EG, achieve consensus, and very rarely make executive decisions. I think you’ll agree that you are more of a dictator. Yes, you took what you thought were the best ideas from Guice, but I found working with you as a lead and changing your mind on anything to be an exercise in frustration. I can’t count how many hours I wasted convincing you that Seam-style injection was fundamentally flawed only to have you switch to using proxies which have their own set of problems. I even brought Josh Bloch in one time to help settle a debate, but you cursed at and insulted him. I sincerely wish I had that part of my life back. By joining your JSR, Spring would not only validate it, but they’d have to give you absolute power over themselves. Based on my experience, I wouldn’t recommend they do that.

Zow! What’s also strange is that this comment shows up in my RSS feed for Gavin’s page, but I’m not seeing it on the comments web page itself. So if you want to see the fur fly, go straight to the feed.

This is the kind of thing I miss the least about the Java world. I theoretically admire the openness of the JCP/JSR process, and in theory it should lead to better results than a more closed process. But in practice, normal human perversity just gets in the way — the kinds of personalities that drive specs forwards tend to be very focused, and prone to conflict. So now it looks like there are going to be multiple JSRs describing dependency annotations, and the two people who could best work it out seem to be at each others’ throats (as far as their respective specs are concerned). Disappointing.

Neal Gafter recently left Google — and the entire Java world — and came to Microsoft, for similar reasons… he put man-years of work into the Java closures spec, and then it was killed due to backroom political pressure. The Microsoft model is more like, we own everything, and we will do what we think is best. Coming from the Java world, I used to think that made Microsoft the Evil Borg. But now, on the inside, I see there are a lot of benefits to having a single decision point. (Well, God knows there are huge political issues even inside Microsoft, but it’s still an order of magnitude less than the Java world!)

So I’ve been a member of the ACM for many years. For a long time it was the only way to get at their Digital Library, which was the motherlode for research paper junkies like me. That made it worth putting up with their magazine, Communications of the ACM (CACM for short), which was really remarkable for how it never had anything worth reading. Pretty much all the lead articles it published were turgid studies about the sociological makeup of MIS departments, or the nature of collaboration in enterprises, or other strange bureaucratic stuff that only had a tenuous connection to programming as I knew it.

Last spring I got my current (unbelievably excellent) job at Microsoft, which has free corporate access to the Digital Library. Hmm, I thought, maybe I should drop my ACM membership.

They must have been snooping on me, because almost exactly then, they announced a complete editorial revamp of CACM. Refereed articles! Hardcore software / hardware research papers! Suddenly they were talking my language. And even better, they actually did it.

The new CACM is frankly the best computing magazine I’ve ever seen. Wide ranges of articles, high technical bar, many diverse subjects of great interest… it’s really a winner. Puts the old Byte / Dr. Dobbs / etc. to shame. Of course, all those mags are dead, too… but the itch they used to scratch is scratched much better by CACM! Who would have thought?

And the new CACM web site is no slouch, either.

I guess sometimes miracles do happen. Thank you, ACM, for doing such a good job on this reboot!

(And yes, it’s been a while… I’ve been sick, the whole family had the flu, the dog ate my homework, it’s been awful dark outside, gimme a break here! At least I’m back! 🙂

Programming is an interesting job, because it goes in continual cycles. Each part of the cycle has its own emotion that goes with it, too.

When starting off a new project, there’s a learning curve that goes with it. You’re spinning up, reading code, reading technical papers, trying to figure out what the hell you’re going to do. The main emotion here is puzzlement — how is this thing going to work? What’s the interface? What’s the feature set? What the heck is going ON?

After that comes early implementation. In this phase, the main emotion is nervousness. You think you know how it’s going to work, but there’s nothing really there yet. So you’re hacking madly away, trying to get enough of a skeleton in place that you can start to make it dance. Forget about getting flesh on the bones, you’re just trying to come up with something that can stand up! Since you don’t really know what you’re doing yet, it could all still fall apart on you.

Once you’re out of those woods, you’re into late implementation. Here, the main emotion is adrenalin. You’re charging on all cylinders, driving at full throttle. The bones are rapidly becoming enfleshinated, and you’re in the zone. This is in some ways the most satisfying part of the whole cycle, because now you start to see some real results from what you’ve been working on.

The last phase is debugging. Here, the emotion swings wildly between frustration and relief. You’re almost done… except you’re not! There’s a bug! Fix it, fast! OK… and on to the next test… and WHAMO, another weird bug! Grrrr. OK, got that one done… YES! IT WORKS!!! Ship it!

And then the whole cycle starts over again.

So that’s my job: puzzlement, nervousness, adrenalin, frustration, and relief. Of course sometimes you take a few steps back. For example, right now I made it all the way to relief, but I’m about to backslide into nervousness. The best-case scenario, though, is when you make it to relief and then you can keep building on the code you just finished… then you have a kind of secure happy foundation under you, reassuring you that even if your current layer falls to bits in a welter of recrimination, at least you know the relief — that fantastic sense of accomplishment that comes with writing a software machine from thin air, that has real value and usefulness — is still out there, in the future, waiting for you.

That’s what software is, to me: the promise of progress, of building on what’s come before, making it better. And this emotional cycle is what it takes to make that happen. So I’ll close with a word that sums it all up for me:

Onwards!

I’ve ranted about grammarware here in the past, but now I’m actually using some, and it’s rocking. I’m talking about MGrammar, part of the impending Oslo.

MGrammar is a toolset for writing grammars and working with them. The MGrammar grammar description language lets you write what is basically an LALR(1) grammar, which means it’s about as powerful as YACC. Or it would be, if it wasn’t also a GLR parser, which means that when your language is ambiguous you get all the possible alternatives. This is a nice way of avoiding the NP-completeness issues around ambiguity detection.

MGrammar also separates syntax (LALR(1)) from tokenizing (regular). This is a win, since sometimes tokenizing is all you need.

The coolest thing about MGrammar is the grammar development tool. It’s a three-paned window, with sample text on the left, the grammar in the middle, and the parse tree on the right. You can change the sample or the grammar at will, and it reparses with every keystroke. When your grammar finds a parse error or ambiguity in the sample text, the sample text gets a red underline with Intellisense. When your grammar itself has an error in it, you also get a red underline with Intellisense, which is reasonable because there is in fact an MGrammar description of MGrammar itself, which drives the Intellisense.

It works very well in practice and makes grammar writing so much more productive it’s not even funny. Using a lot of negation can make it go nonlinear, but it’s manageable.

On a sad note, Gilad and his merry band have lost their funding. This really sucks, as Newspeak is one of the most interesting language efforts around. I very much hope a community takes root around it and drives it. (If it can happen to Factor, of all things, it can happen to Newspeak.)

And finally, yes, http://robjsoftware.org was broken for the last month or two. I had one email filtering rule for all of GoDaddy, and when we moved to Seattle this spring, the address change broke GoDaddy’s monthly charging, but I didn’t see the warning because it was in the same bucket with all of GoDaddy’s spam^H^H^H^Hinformative emails. Which I never read. Sigh. I clearly need a fully redundant alerting and monitoring system for my blog.

Well, except for Blogger eating my profile picture, and GoDaddy eating my redirect from robjsoftware.org to blog.robjsoftware.org — why can’t things just Keep On Working? Entropy, I hates it.

Shortly after I griped last month about a lack of working FLINQ samples in the latest F# CTP, Don Syme himself came through nicely with just what I asked for. So yay Don! And yay F#! And boo me, because I have not done thing one on the personal-hacking front in the last month. In fact, that aspect of this blog is going to go quite dark, if current evidence is anything to go by.

Not to say I’m not still deeply digging geeky things — I’m currently reading my way through the extremely excellent Parsing Techniques, The Second Edition. My upcoming task at work is to do a whole lot of parsing stuff, and this is exactly the book I need. It’s amazing. I’ve been reading scads of parsing papers (one-stop shop for me: Bryan Ford’s Parsing Expression Grammars page), but I lacked the basic background — what exactly is LALR? How do shift-reduce parsers work? How do you convert a left-recursive grammar to a non-left-recursive grammar, and what does it do to your attributes? Well, the Parsing Techniques book is absolutely the best imaginable text for me. It’s the second edition, just published this year; the first edition was from 1990. How beautifully synchronistic that it should come out just when I absolutely vitally need it! I LOVE it when that happens.

And honestly, there are two other reasons I’m not getting much solo hacking done. One is that I’m climbing about 20 learning curves at once in my day job, and it’s saturating my technical novelty bandwidth. There’s not a lot of extra juice right now for doing yet further explorations in the evening. The other reason, and this is something I have yet to blog about here, is that it’s the fall season, and that means GAMES.

Yes, the truth is out: I’m a fairly inveterate computer/video gamer. It’s been a hobby of mine ever since I first laid eyes on a computer — literally; the first computer I ever saw was a PLATO timesharing system at my best friend’s doctor father’s medical school in Connecticut. And what was it running? Spacewar. I still remember it vividly.

Ever since then I’ve been happily gaming away, and in many ways it’s the perfect hobby for a compulsive hacker — video games push technology in a lot of ways, and modern games use cutting-edge 3D graphics, physics simulation, distributed virtual space technology, and generally a whole lot of hardcore computer science in doing what they do. So not only do the games themselves get more immersive as games, but they also get more technically interesting and intriguing to learn about. Right now I’m playing Crysis, one of the most hardware-intensive games ever made (though people debate whether that’s because it’s not well optimized or just super ambitious). I finally got my self-built PC to run two graphics cards (through NVidia SLI), and man, this game is freaking stunning on my 1920×1200 26″ monitor. (Which cost only $600! Damn, wasn’t it just two years ago that this sort of thing was $2000+?)

So I’m giving myself permission to slack off, personal-hacking-wise, for the rest of the year. Unfortunately it looks like it will still be a good long time before I can post in depth about what I’m actually working on at Microsoft, but suffice to say that I really do look forward to that, and it will happen sooner or later, and the longer it takes the more I’ll have to say when the veil finally drops. But rest assured, it’s freaking cool and you will love it when you see it 🙂

Well, not a lot of F# hacking got done last month. I did download the then-current F# build, and tried out some of the FLinq samples, and they didn’t work. I posted about it on the F# mailing list (Microsoft, your mailing list server needs some serious kicks in the pants region), and there was no helpfulness forthcoming. So, onto the (cold, dark) back burner it went.

Which was fine, because ordinary life (summer vacation for the kids, my birthday, etc.) was plenty busy. And my work has exploded into a drinking-from-the-firehose geek frenzy — I wrote a monadic push parser the other day, and got paid for it. Not clear whether it’ll ever ship, but it was definitely relevant, which rocks. I can now say that I have lost my monadic virginity. Whether I should say it is another question. (My wife says not….)

However, on the bright side, the F# team did ship their CTP (Community Tech Preview, or something like that, for those outside the MAZ (Microsoft Acronym Zone)). So I’ll take another run at it later this month. One cool thing is they have support for dimensional quantities now, a la Fortress. Only F# is basically here now, and usable for production software, whereas Fortress is still N years away from having any kind of realistic compiler. So IN YOUR FACE, Guy Steele! (Seriously, Fortress looks great. It’s just that F# is here now, and is pretty great itself.)

OK, time to get back to watching a truly monster build crunch away. Work is creeping out of normal working hours — getting assigned a fairly major team-wide task tends to have that effect. It’s also cutting into my discretionary hacking and gaming time considerably. We’ll see what the next month holds….

Hello everyone. Ah me. We live in Washington now! (State, that is.) We’re happily ensconced in a nice rental home in Kirkland, and so far just about everything we hoped for from the move has happened — we have less commute, cooler weather, a better school for our daughter, and my wife no longer has to work. And my new job at Microsoft is going very well so far, though I’ve actually been there less than a month — I took May off to help our family settle in, and THANK GOODNESS, because moving is a LOT OF WORK even once you actually arrive!

But so far so good up here… I’m sitting in our living room looking out at the evening sky and the pine trees across the street, through the full-length windows and French door that front our house. It’s beautiful up here.

I can’t say too much in detail about what I’m working on, because Microsoft (like Google) is mighty touchy about confidential projects. But I can make some general observations after being back on the inside of the Borg for a few weeks. (I was amused to discover that they remembered me! I interned at Microsoft in 1988 and 1989, and I guess they gave me employee number 40775, because when I signed back up they gave me the same number back again. People were like, why are you 40775 rather than 263484? Microsoft’s gotten BIG over the years….)

It’s very curious how deep the not-invented-here goes at Microsoft. It seems to be partly historical — Microsoft was such a winner-take-all company for all of the eighties and nineties, it sank deep into the marrow of the company. And it is partly reactionary — the rest of the industry reacted so negatively to that aggressive attitude (antitrust suits, pitched legal battles with Apple and Sun, etc.) that it drove Microsoft even further into its own corner. I’ve got kids now, and I think a fair bit about sibling rivalry, and how kids (and adults, and nations) tend to define themselves in opposition to one another… sometimes your identity emerges through your interactions with your peers. That’s definitely happened to Microsoft, and as a more than thirty-year-old company, it’s going to change only slowly if at all.

Regardless, Microsoft really is its own technological world now. And this has its good points and bad points. Coming from the Java world, and from California where lots of my friends are vehemently anti-Microsoft, it’s a bit bemusing to see it all with an outsider’s eyes… plenty of my new colleagues have been here for decades, which is almost unimaginable to me. It’s certainly part of my value here, that I’ve got recent experience with how things are on the Outside.

I can’t be too specific, but there are quite a few areas where I feel like Microsoft’s internal technical isolation is hindering them… particular tools that seem like a step backwards, or particular design problems where it seems like there just aren’t quite enough people providing fresh ideas. The relative isolation of the Microsoft software stack can seem a bit… I don’t know… lonely? The “us vs. them” thinking is hard to escape in the blogosphere, and it’s such a polar choice — either you’re on Windows / .NET, or you’re not. And if you are, you’ve got to pay to play — at my last startup, we were a Linux and Java shop, partly because it got the job done and partly because it was free. (Though as one of my new cronies says, the people who won’t pay aren’t customers anyway, because how can you make a business out of non-paying customers? That’s a very deep-seated belief in Microsoft-land, and you know, there’s some truth to it.)

But on the flip side, there are some real advantages to owning all the code you could possibly need to run an entire industry of PCs. I’ve spent the last two months spinning up on LINQ, one of the coolest new features in C# 3.0. It stands for Language Integrated Query, and on the face of it it seems like syntactic sugar to let you write SQL-like code in C#. But it turns out that under the hood there’s a lot more to it — it’s implemented via compiling language statements into expression data structures, that can then be rewritten, reparsed, and used to generate entirely different kinds of language output. It is very cool technology, very useful for creating domain-specific languages — in fact, it’s rather along the lines of my extensible language rant from a few months ago.

And it would not have been possible if Microsoft didn’t completely own the C# and Visual Basic languages, and have the resources to come out with a new iteration of the language spec, and all the compilers and tools to support it, simply because they thought it was a good idea. Compared to the slowness of Java’s evolution (how long has the closure spec been rattling around?), Microsoft’s ownership is yielding real benefits to .NET programmers. (OK, so the closure spec is deeper and wider-reaching than C#’s lambda expressions, but nonetheless there are several intersecting features in C# 3.0 that are all needed to make LINQ work, and I don’t see Java catching up very quickly.)

It’s also pretty amazing to see the breadth of the expertise here — my team happens to be pretty closely connected to Microsoft Research, which is teeming with world-class experts. If you look at the roster (Simon Peyton Jones, Don Syme, Erik Meijer, Galen Hunt, Nick Benton, Martin Abadi, Luca Cardelli… heck, search ’em yourself!), you’ll see a whole lot of people who’ve driven the world of software forwards. Microsoft has a deep commitment to that goal, even if their not-invented-here, no-open-source mentality gets in the way sometimes. So it’s exhilarating to be part of that mission.

Microsoft is a colossal company, and I’m fortunate that I’ve landed in a very ambitious and solidly supported team — in fact, I can’t think of any job I’d rather have in the industry. I’m feeling very lucky indeed, and I’m doing my best to get productive quickly — this opportunity isn’t going to come along again anytime soon!

And, that said, I’m obviously not doing very well on keeping to my blog schedule. Realistically this blog is going to slow down a bit, probably to more like once per month. Eventually — once our team’s incubation project goes public (knock on wood!) — I’ll hopefully have another blog on msdn.com where I’ll blog semi-officially about our technology. But this blog will be my personal property into the indefinite future. Stay tuned!

Well, this post has been a long time in coming. Finally all the stars have aligned, and I can announce to the world (i.e. you!) that I have accepted a job at Microsoft. My family and I are moving up there in just a few more weeks — we sold our house (in one week flat! amazing what price reductions can do), and are in escrow. Which also explains the loooong delay since last post.

What exactly will I be doing? I’ll be working for a technical strategy incubation team, which kind of sits in between research and line development. We’re working on a new operating system stack from boot loader all the way to applications. I can’t really say much more, except that what we’re doing is not entirely unrelated to the Singularity operating system.

Having spent the last twenty years in the bay area, hotbed of anti-Microsoft sentiment, I am pretty sure that I have quite a few readers (and friends!) who will be wondering why exactly I’m joining the Evil Empire. Especially when I interviewed with quite a few other places, including Amazon and Google. What’s up with that?

There are a few answers to that question:

• I don’t like how Microsoft has abused their monopoly power, but I also have been a Windows user for the last sixteen years, with quite reasonable satisfaction. So I personally have never quite swallowed the “Microsoft is Satan” kool-aid.
• The more blogs I read by Microsofties (especially the anonymous ones), the more I see that Microsoft’s internal self-assessment is by no means all rosy. Microsoft engineers seem quite aware of when their stuff sucks. The existence of the team I’m joining is arguably proof of that exact fact.
• It’s possible that working for Microsoft will circumscribe what I can blog about without making lawyers mad. However, that’s just as true of Google, which is also notoriously secretive. Google also has had quite a few criticisms directed at its business practices. Basically, size, confidentiality, and ethical qualms seem unavoidably linked. (It’s true that Google does more open source stuff than Microsoft, but that may be changing as well.)
• If our stuff is great and makes it into Microsoft products, it could potentially make life better for a whole lot of people. Operating system work at Microsoft can have a broad impact in a short time, if it’s successful.

I’ll also be working with some old friends from my Xanadu days, along with some relatively well-known other folks, including Pavel Curtis and Chris Brumme. I got to meet a good cross-section of the team and I’m very jazzed. My research paper addiction paid off handsomely, it turns out!

I spent the entire last week of February interviewing. I did get offers from other places, each of which I greatly appreciated.

I got a great offer from the Prime team at Amazon, also, which seems like an extremely sharp group; I will definitely be keeping a close eye on Amazon as they grow their distributed infrastructure business.

I also interviewed with a startup, which I expect to do very well (keep an eye on Apptio — though they’ll be rebranding themselves soon!). If I hadn’t spent the last ten years in startups, none of which has (yet) had life-changing success, I would have probably jumped on them just for the raw upside potential; as it is, though, I’m ready to try a megacorp.

(To my Google friends: Google was very interested but ultimately turned me down. Might have partly been timing issues on my end. So, looks like it’ll be a while (at least) before I’m working with you all. I’ll also need to pull back from the GWT project. It’s been a great few years in Java-land but it’s time for a change, and I’m looking forward to C# generics 🙂

All in all it was a very difficult choice across the board!

In general the whole week was the most fun I’ve ever had interviewing, despite the fact that I had a big bandage on my head for most of the week (beware of low pine branches after dark!!!). I sincerely thank everyone who took time to meet with me in person or by phone over the last few months.

Now to start walking the fine line between saying too little and too much. I don’t plan to go dark on this blog, though I also won’t (yet) be able to say much about my day job here. But that won’t stop me from the general research paper talk to which you’re already accustomed!

Late. Again. I assure you there are perfectly good reasons for this that, I further assure you, you do not want to know. Good news is things have radically improved in the last few days and the future is extremely bright. I’m squinting right now, in fact.

There are some architectural patterns that just Feel Right. That feeling of rightness isn’t always reliable — it can lead you pretty badly astray — but still, it’s there. And sometimes, what do you know, it even is right.

For years now I’ve been following research into microkernels, starting back in the early nineties when I was reading about Amoeba, an old-school distributed system structured as a set of small components. The idea of structuring an operating system as a set of isolated pieces, protected from each other and passing data only by well-defined messages, seems conceptually clean. It’s started to gain traction lately with projects such as the L4 kernel, the Coyotos project, and Microsoft’s Singularity, and IBM’s K32.

Interestingly, one of the biggest obstacles to the wider use of microkernels is Linus Torvalds. In late 2006 he had an online spat with Alex Tanenbaum, developer of Amoeba (back in the day) and Minix3 (new hotness). Linus has been saying for years that microkernels are a crock, and that operating systems are best built with extensive use of shared memory, because — in his view — what operating systems do is provide coherent views of shared state to multiple processes, and without a single shared state available to the whole kernel, providing a coherent view becomes much, much harder. Linus draws a parallel between microkernels and distributed systems, pointing out that distributed protocols are really hard to implement, precisely because you don’t have common state.

Personally, I agree strongly with Tanenbaum’s (and Shapiro’s) rebuttals. Tanenbaum points out that distributed protocols also have to deal with partial failure and reordering, which are not problems that microkernels have. Inter-component communication within a single machine’s operating system can be radically simpler than communication over a network (even though multicore machines do start introducing some timing variability). Also, of course, shared state in a monolithic kernel still requires concurrency management, and the complexity of managing concurrent access to shared kernel state is by far the biggest single source of Linux kernel bugs. Just look at all the work on massaging the locking patterns in the Linux kernel (getting rid of the Big Kernel Lock, etc., etc.). For Linus to claim that micro-component kernel development is more complex than monolithic concurrent state management is… well… not as obvious as he seems to think.

Shapiro points out that all robust engineering practice has shown that high reliability requires high isolation between small, robust components. He claims, and I agree, that there are no large-scale highly reliable systems that are not built from small, modular, isolated pieces. Certainly Erlang provides another data point that high reliability comes from many small interacting components, rather than from large-scale shared state.

Small, modular components get you other benefits, such as upgradeability (if your microkernel tracks references between components and manages inter-component message passing, you can upgrade individual pieces of your system without shutting things down — Erlang applications also work this way). Security is also enhanced if the compromise of a single component doesn’t expose the entire state of your kernel.

There are also interesting parallels between building single-machine operating systems as sets of modular services, and building large-scale Internet systems as sets of modular services. In both cases, you want to build something big and reliable from individual pieces that communicate over explicit interfaces, and that can be individually quickly restarted when they fail. In an operating system, your drivers are the flakiest piece, and when they die you want to be able to reload them without the rest of the system batting an eye. In an Internet service, your individual servers are the flakiest piece, and when they die you want to be able to fail over to other (mostly identical) servers without batting an eye. Isolation between components is critical in both cases, and you want to build your whole system in a layered way with redundancy and restartability at all levels.

Linus is correct that distributed transactions (for example) are hard to build out of individual components. But it’s also true that as you scale, distributed transactions are one of the biggest architectural system-breakers. Amazon, for instance, doesn’t use them (see also here), instead relying on careful ordering of service updates to preserve consistency in the face of intermediate failures. And many microkernel operating systems are also structured to avoid multi-component consistency interactions wherever possible.

So I think this is a rare example of where Linus is squarely on the wrong side of history, and where Linux will likely fall behind other systems that push towards greater modularity and greater internal componentization. It’s an interesting question whether large-scale Internet services will, over time, make individual-server operating systems less important — in other words, whether most applications will migrate to a highly-managed cloud, in which case most computers will wind up being more like thin clients, with all the action happening on a virtualized pool of services. But even in that case, the companies building those services will still want to leverage multi-core technology to the max, which essentially means building their individual service instances using highly isolated component architectures. Having such an architecture at the base of the operating system can only help achieve that goal, and it’s sad to think that Linus (on current evidence) will get in the way of that for Linux.

Yikes, just missed my two-week window. Too much happening, too busy… get used to it, folks, it’s here for the duration, e.g. until this summer, after we’ve sold our house. Enough of that! Onwards!

Research papers are one of my biggest Internet weaknesses. Another one is post-mortems. If we learn from others’ mistakes, then post-mortems are solid education… they’re experience reports in their most tangible form.

For some reason, it seems there have been a whole slew of interesting ones on the net recently. Here they are:

• Lambda the Ultimate cited this analysis of why Symbolics failed, as footnoted by Daniel Weinreb. Short story: too much technology, too little business focus. Still, interesting to get the inside view.
• Even better are Daniel Weinreb’s posts about the history and impact of Object Design and Objectstore. Orthogonal persistence once seemed like a Really Good Idea to me, until we tried it at Electric Communities in the mid-nineties and couldn’t make it work. Even so, it looks like there are some valid use cases that Objectstore exploited about as well as possible. Did you know Amazon evidently relies on Objectstore caching for their entire inventory database?
• Switching gears almost completely, from civilized discussion to rabid flaming, Zed’s infamous rant on leaving the Ruby community deserves mention. (WARNING: SOME NOT-SAFE-FOR-STRAITLACED-WORKPLACES CONTENT!) I have to admit I have a weakness for, shall we say, colorful language. The BileBlog (WARNING: DITTO!) was entertaining for a long time, though recently it’s gone dark… maybe Hani decided the career impact wasn’t worth the flameful fun. I’ve been tempted to go balls out and get explicit here, but the more I consider it, the less necessary it seems. Wait, that was all a huge digression away from the facts, which are that Zed’s rant is entertaining but I have no idea how accurate it is, and his comic self-promotion makes it hard to tell when he’s being serious and when he’s not, which hinders his message. He kind of wants to have his cake (“I’m so awesome, truly”) and eat it too (“Can’t you tell I’m mostly joking?”), which doesn’t do him any favors.
• Meanwhile, the poor beleaguered Open Source Applications Foundation recently announced that Mitch Kapor is washing his hands of it all. No more funding on his nickel, almost two-thirds of staff laid off, and Katie Parlante left to try to turn it all into real revenue somehow. After six and a half years of Python hacking, they still barely have a usable application. Scott Rosenberg already told the whole epic story, but this seems like almost the last gasp. Open source projects can perish without clear architectural and requirements leadership, and OSAF will forever be the paradigmatic example. (I largely agree with, again, Dan Weinreb’s take on it all. I wonder if a good dose of RPython would help out Chandler at all?)
• Finally, this isn’t new news (totally the opposite!), but I’ve got my own personal post-mortem skeleton in the closet, namely my involvement with the legendary Xanadu project. I’m quoted in the Wired post-mortem article. Some of what I said there was classic “this kid is young and bitter” uncensored vitriol. I’m glad that the brilliant people I worked with there understood that, because I want to work with some of them again some day! But overall, there is a lot of truth in that article, and it’s just a great read regardless. (Warning: that link is to the printer-friendly version, and Wired, under their new Conde Nast overlords, has lost their web-fu and has broken image links everywhere. Doesn’t matter; the text is all that counts in this instance.)

I’ve made some whopper mistakes in my career — some quite recently — and it’s too bad it will be a long time, if ever, before I get to tell the tales. (The downsides of modern tight-lipped corpocracy….) Still, we (hopefully) live and we (hopefully) learn. The more post-mortems, the better!