The Notetaker, a portable personal computer

From "Inside the PARC"...

The Notetaker, a portable personal computer built at PARC in 1978, is rumored to have been the inspiration for the Osborne 1.

The Notetaker ended up as an 8086-based computer that could fit under an airplane seat. It was battery-powered, ran Smalltalk, and had a touch-sensitive screen designed by Thornburg. "We had a custom monitor, we had error-corrected memory, a lot of custom engineering that we would normally only do for a real product," said Fairbairn, the Notetaker's chief hardware designer. "The last year before l left PARC," Tesler said, "I spent flying around the country talking to Xerox executives, carrying Notetaker with me. It was the first portable computer run in an airport. Xerox executives made all sorts of promises: we'll buy 20 000, just talk to this executive in Virginia, then talk to this executive in Connecticut. The company was so pread out, they never got the meeting together. After a year I WaS ready to give up. " While Xerox may not have been ready to run Witll a portable computer, others were. The Osborne I was introduced in 1981 about nine months after Adam Osborne reportedly toured PARC, where pictures of the Notetaker were prominently displayed .

Where am I?

According to the World's Smallest Political Quiz, I am a left-leaning libertarian.

Your Personal Self-Government Score is 90%.
Your Economic Self-Government Score is 60%.

The problem is, many of my responses were "maybe". In government, as in almost every social situation, the results are much more dependent on the specific individuals than general ideologies.

Do objects have too much freedom?

Isaac Gouy quotes, in a comment on Jim's blog...

"But Smalltalk's mechanism suffers from a serious drawback: Initialization is not enforced. new creates objects but does not initialize them... A second drawback with both Smalltalk and Ruby is that initialize, being an ordinary method, does not chain: You must remember to begin your initialize methods with a call to the superclass's initialize method."

Hey, but this just plain, old message sending, as with any object. It just happens that that "object" is a class. That's the advantage, and the tradeoff.

So, in general, inheritance is not as good as composition. But why is *this* message sequence worse than any other?

Do objects have too much freedom?

Social Spreadsheets

Interestingly, Phil Windley blogs sequentially about Tom Malone, Ray Ozzie, and Social Spreadsheets.

What's the interesting connection? See "Object Lens: a Spreadsheet for Cooperative Work" by Tom Malone, whose work (from Information Lens to Object Lens, to OVAL) influenced and was influenced by Ray Ozzie's Lotus Notes.

(Non-ACM link to the OVAL paper. [Manuel Simoni])

MIT's DSpace has all of Malone's working papers as well.

We're *all* clueless about *something*

Don Box reponds...

Indigo (one of the three "pillars of Longhorn") does in fact install on XP and Windows Server 2003. The experience on all three platforms should be comparable.

Yes, I've written before that I think Indigo is one of the gems of MSFT's new work. That accounts for just a small portion of the work though. I can't help but wonder whether the rest of the teams just did not try hard enough, or whether their decisions are more valid from a technical or business perspective.

...I know its fun to paint MSFT as clueless dolts who don't care about developer or customer investments, but the reality isn't quite that black and white.

That's not my intent, but unfortunately can come across in part through my writing style. And that's something I regret. I need an automatic "tone" critic.

FWIW, I don't think MSFT as clueless. They're too good at what they do. I just wish I could be a fly on the wall in Redmond to understand their thinking. (Of course it "their thinking" is itself non-uniform. Certainly the company is full of all kinds of agendas and thought processes.)

BTW, every large system development team I've been a part of has made proportionately bad decisions, including those I've led. There are simply so many variables, so many decisions, and so many pressures from all aspects of the effort, technical, business, and political. If this helps, I am as critical of my own past efforts as I am of those taking place around Longhorn. Moreso, since I know the details and where the skeletons are buried! (Ask me about Late-dot-Slow someday.)

Microsoft has chosen their own inflection point

Wes responds to my inflection point item. But I'm not calling a winner, and I don't think Spolsky was either.

Let me clarify my point. Clearly we are *at* an inflection point for Windows OS, API's, and development. Microsoft chose to create this inflection point rather than a more graduated approach.

I am not predicting which way the market will go. I am definitely not that smart. If I had to make a call, the best I could say is that there will be some middle way, that a Longhorn victory will be hard fought path that extends well beyond 2007. But who knows? An accurate prediction is not the point.

I do think Wes, et al. have missed some key aspects of Joel's message though, reducing the discussion to a binary one of who will win, the old or the new.

One of the key aspects of Longhorn is that, Joel suspects and I've wondered on my blog earlier, *why* everything is rolled into an all or nothing set of dependent technologies. Clearly many parts of Longhorn could be made more independent and portable to older Windows platforms (even Linux, but that's another topic altogether).

The interesting aspect of this issue is exactly that Microsoft has avoided inflection points of this magnitude so far, but with Longhorn they are *creating* their own inflection point. Let's just watch how they play this out; Longhorn is probably more interesting from a business sense than from a technical sense.

Tuple Spaces: Queues or Databases?

Dan Creswell asks: Are tuple spaces more like queues or more like databases? They fit a broad set of niches between message queues and relational or object databases.

Queues can implement variations of one shared data structure: namely, queues.

Spaces can implement variations of shared queues, but also variations of shared arrays, shared dictionaries, and other "shared memory" (i.e. "random access") structures.

A space is typically centralized, where a queue product typically supports distributing the queue's end points around a network.

A space is typically better at heterogenous random access, where a more traditional database (e.g. a relational database) is typically better at homogenous sequential (and relational) access.