Misguided: The Road Not To Be Travelled

Update:This is turning into a lot of work. Why did I start this?

Oh, I remember. Because this is a really bad feature that could screw up a lot of software for years to come.

Quote of the Day

...from Phil Dawes...

Blimey, that’s gonna cause a bit of a ruckus.

Wrong Programming Model

Not much love over at LtU. So LtU readers -- here's the gist of my diatribe -- the programming model is simply not needed and will lead to shared memory code at least as complex as the stuff we're writing today. Should everyone switch to Erlang? Well that is the general direction general purpose languages should go. Switching from today's monitors to transactional memory is not going to be a baby step either! It's a huge step. In the wrong direction. So, yeah, as long as we have to step this way or that way to get into a multiprocessor, multinode, concurrent world -- let's do step in a direction that is a good bit simpler than the one we're in today *and* far simpler than the one proposed by the transactional memory folks.

Meanwhile back at the comments...

Guillaume Germain, the author of Termite, a really nice Scheme-like, pretty much shared-nothing, concurrent programming system, comments...

I think STM has some very attractive aspects, most notably efficiency and composability. I see it as a better replacement for other low-level concurrency constructs, but not for large scale systems.

The efficiency of a mechanism may not translate into efficient *use* of the mechanism. As for composability, I think that could very well turn out to be an academic attribute. Is this something most programmers should be composing concurrent threads with? No. Absolutely not. Most programmers should not be using shared memory threads at all.

Then Guillaume comes to his senses, 8^)...

I have a few concerns about it...

The first concern is that I'm not sure how much the composability of STM will scale. If layers upon layers of transactions are built, I fear some dependencies between layers might start surfacing at upper levels, causing surprising conflicts. It could become hard to get it right. I can see misguided programmers starting to sprinkle their code with 'atomic' statements ("just in case"), a bit like one would do with 'yield' statements in a non-preemptive concurrent system. Also, 'atomic' statements could be forgotten, causing nasty bugs...

But my main concern with it is that after all, STM is still shared-state concurrency. It mixes together the control flows of programs in ways that can be hard to visualize and comprehend. Erlang doesn't have that problem, because every "connection point" of a process with the exterior is obvious and well-defined...

in the end, it seems to only solve a small part of the problem, and it doesn't really help with the actual design of concurrent systems.

rektide then comments...

the one thing i really like about STM is that good implementations are exactly like ZFS, copy on update

And hey, if you want to build a persistent file system, by all means the mechanisms in ZFS are neat. But does this automatically transfer over to main memory shared everything concurrent programming as a desired programming model for most applications? No way. I can't make that leap so easily. At all really.

And he writes...

currently, any place where data over time is relevant requires user implementation to store history, which usually means debugging tools and printf(). to me, history is just a series of transactional states, and being able to lookup old states seems like second nature. i would really like to see more Saga like transactions available in the mainstream.

And I am all for making the history of state available and first-class. Yet there are many ways to do this within a sequential process, not requiring main memory shared everything concurrent programming.

if you've got magic bullets for [distributed shared state], the world is always buying.

No. Avoid distributed shared state. That doesn't mean all concurrent, distributed problems go away. It just means they are that much more manageable. This shared everything transaction thingy makes the problem much worse than it has to be. I think the starry-eyed admirers see how hard shared memory monitor-based programming is. But that programming model should *never* have been admitted into the Java language to begin with. There are already better solutions than this proposed garble.

End

From the ACM Queue, "Multicore Programming With Transactional Memory"...

Transactional memory brings to mainstream... programming proven concurrency-control concepts used for decades by the database community... Under the hood, a combination of software and hardware must guarantee that concurrent transactions from multiple threads execute atomically and in isolation. The key mechanisms for a transactional memory system are data versioning and conflict detection.

By the way there are a few folks at Gemstone Systems who've done this far better than anyone else. They've been doing it for over two decades and it's in production in heavy use at financial institutions, factories, shipping, and so on. They've got it working in distributed shared, multi-user transactions with efficient distributed garbage collection. I pointed some researches that way. Not the ones in this paper.

That said, this would be the most tragic turn imaginable for programming in the 21st century. There is no way I would want to do this in the small on one machine or in the large in a Gemstone-like system. That is the wrong way to program concurrency for most systems.

Very wrong. And it is scaring me how shiny this thingy looks in so many people's eyes right now. I don't think it will be so long before this shows up in Java and C#.

Wrong, Wrong, Misguided, and So Wrong

We need to be headed primarily toward shared *nothing*. Sharing at the level prescribed in this paper, whether with locks or transactions, is simply uncalled for 99% of the time. Sequential processes with shared-nothing message passing should be the direction.

Get better isolation mechanisms for conceptually multiple JVMs and dotnet runtimes in a single OS process. Better yet, turn these systems into legacies and just move onto something better for future work.

You can hold me to this: transactional memory if turned out into the wild will turn out to be a *mess*.

Damien Katz writes in the comments (and since he agrees with me so well, I promote it here)...

I *completely* agree. Shared state threading is a hack built on to existing languages. A useful and fairly efficient one, but a hack nonetheless. And like raw pointers and unprotected memory, it's hard to justify it's use for most programming tasks. Compared to languages like Erlang, it's nearly impossible to justify it on efficiency or performance concerns.

Transaction memory is another hack bolted on to all the previous concurrency hacks, and somehow it's going to make all the other concurrency hacks to work reliably. Yeah right.

In another comment worth displaying up front, Dan Creswell expresses, well, let's have Dan's quote. It even deserves its own subtitles...

It's Deadly Shine'y

You're looking at premium car-wax, retina burning shine'y

I read the same article and it just frightened me. All that magic hidden under the covers, bleuch.

It's deadly shine'y because at the surface it appears like it just makes all the concurrency stuff such as locks "go away" in line with many a programmers desire to ignore such details. Couple that with the familiarity most have with transactions and you're looking at premium car-wax, retina burning shine'y.

I don't even want to imagine debugging one of these systems. You're going to be confronted with some strange behaviors due to transaction conflict or whatever and because it's all supposed to be done by magic under the covers wading in there to understand what's broken will be a nightmare. It'll make debugging from Java thread-dumps look like a holiday.

8^)

More comments. This is great.

Here's part of one from Nat Pryce...

Does software transactional memory support coordination? Or must that be supported by other primitives, such as semaphores or monitor condition variables?

From what I can tell you still have to build up from the basic transaction mechanism and the shared variables. But it is worse than that.

Most systems today should be ignorant of the "inside my OS process", "on my same node", and "on some other node". The benefits of that can be seen in Erlang, which Damien pointed out. This mechanism is still an "inside my OS process" mechanism.

Well, at the lowest level of runtime implementation of an OS process, you need some mechanisms like this. I would argue all the machinery, hard and soft, for transactions, is way overkill for that level of systems programming.

But to continue to have application programmers deal with this mess for the next umpteen years is nothing but ludicrous. As Damien also wrote, it's like continuing to have today's programmers deal with raw points and memory. No way -- very few programmers should be dealing with that level of complexity.

Nat also writes...

The interaction between distributed (and therefore concurrent) activities involves two things: data transfer and coordination. Synchronisation to avoid race conditions is just one form of coordination. Systems also need to coordinate activities that don't share data.

Yes, absolutely. Let's focus on the real problem for software development. Transactional memory is *not* it.

And now sigfpe (Dan Piponi?) writes...

it's nice to know that there are other people in the world having issues with STM.

Yes, now's the time to raise a ruckus.

And Cale Gibbard comes to the defense of the dang thing...

The major advantage of STM as a system is that it gives you certain guarantees about composability of already working systems. It's not magical, it doesn't always ensure that things will play nicely together, but it does give you far more guarantees about the correctness of compositions than previous systems have.

But Cale, there's not that much Haskell code out there yet anyway. Don't lets have the Haskell people start in with transactional memory just because there still trying to demonstrate they can do imperative programming better than the rest of us.

The world is getting ready for shared nothing, semi-functional programming. Get out of the backwater and catch up to your audience.

And if some group is going to retrofit transactional memory into some significant Java or C# system, well, they would be far better off investing that time into a simpler, shared-nothing rewrite into a language like Erlang, a simpler language like Smalltalk, or even a better shared-nothing coordination mechanism like Javaspaces.

All that low-level monitor-based garble? Just leave it will it is now. Walk away from it slowly. Turn your back, and run.

Cale again...

That being said, if you understand the additional compositionality guarantees, what exactly is it that you find lacking?

Em, simplicity? Em, elimination of totally unnecessary mechanisms too far removed from the domain problem?

And on...

Limiting shared state is obviously good -- there's nothing in this system which prevents that. However, it's a system for cleanly sharing any state which should be shared.

Yeah, right. People would abuse that mechanism all to bloody hell. If a relatively small group of programmers can develop the various soft real time Erlang systems we've seen over the last several years, there is no indication in my mind the effort required to implement and teach this transactional memory thingy would benefit anywhere near 90 some percent of programmers on this earth. No evidence whatsoever.

Other forms of communication, including those in Erlang still have this problem to deal with.

Yes, complex problems remain with implementing concurrent systems. But mechanisms like Erlang's raises them to a higher level, closer to the problem domain. This transactional memory is a false hope covering a bottomless pit that could have easily been walked around in the first place. Stay on the path.

Suppose you have a bank server with clients happily communicating deposits and withdrawals to it, and everything is working. How do clients implement a transfer between accounts safely?

First let's not turn every little data structure into a bank account transfer problem. That's just not the case. Second, these cases that really do exist should be well isolated and the mechanisms not put in every programmers' hands. Third, account transfers have been occurring quite a bit over the years without this new transactional main memory thingy. Why complicate everything for everybody, even if this were the best way to transfer funds???

Sorry, that is just a *really* unconvincing example.

Anyway, this is getting long and I probably can't do as good of a job of it as the paper can, so everyone please check it out before writing more gibberish about transactional memory.

Yep, read 'em. This is not the first time I've commented on it. Just now it seems like it is gaining momentum. The people writing the gibberish are those inventing these things without comprehending the damage it will do.

WS-DCOM

Tim Bray writes...

WS-*? In the real world, it’s about being able to interoperate with WCF, and while that’s a worthwhile thing, that’s all it’s about. It’s not like HTTP or TCP/IP, truly interoperable frameworks, it’s like DCOM; the piece of Windows’ network-facing surface that Microsoft would like you to code to. For now, anyhow; it’ll be at least as easy as DCOM to walk away from when the embarrassment gets too great.

Which is the way it should be, since SOAP essentially exists because DCOM was even worse.

TSS: Using Javaspaces

There is a so-so article on Javaspaces over at TSS but it has spawned a long, interesting thread of multiple topics. After undergoing a substantial signup process and clicking on the url in their email, TSS still refuses to allow me to participate. That sucks, but I'll just put my various responses here. Sites that create barriers to participate irk me.

Going down the comments, pulling out what catches my eye. Some of my responses are clarifications, some are educated guesses. Too bad these are not able to be in-line for others to correct.

"public fields"

The top level object written to a space implements Entry. Only the public fields are marshalled to/from the space. This strikes people as funny at first. Ken Arnold has a rationale. This is another of those things that should be in the core documentation.

First of all, the objects those public fields refer to have all their data serialized. (They implement Serializable.) This is only the top-level Entry that considers just public fields.

The analogy Ken gives is that an Entry's public fields are like the parameters to an asynchronous procedure call. Read his explanation. It works for me. This choice also ties into keeping things simple for the application developer and the space implementor. More elaborate choices bring more complexity.

"[spaces] works best when the problem is... 'data-centric'... as opposed to 'process-centric'"

I am not sure what this means. Spaces are good for distributed processes as well as data. An Entry and its referenced data is marshalled along with their codebase so that systems reading and taking them can use their code without it being on that system's classpath a priori. That is very powerful.

"Javaspaces is a poor model for building large-scale... non-holistic data-intensive compute work-loads"

Maybe. I don't know. What the heck does this even mean?

"I'm assuming that when you are altering something in a space, there's some sort of locking on it"

Nothing can be altered while in a space. Those things are not in a JVM per se. (Although a JVM may be used in the implementation.) Each public field is marshalled independently on a write, and then marshalled back into a JVM on a read or take. Object identity is not preserved. So if JVM #1 does a write and then a take of some Entry and its data, there is now the original Entry and data, plus a new deep copy of the Entry and data.

And so you can see clearly that a Javaspace is *not* a cache, and it is *not* an OODB for Java objects. It is something else altogether that can serve many purposes. The way to exclusively modify something is to take it, update it, and write (a copy of it) back to the space.

"what, if any, value JavaSpaces has vs. messaging"

I think if you want widespread, anonymous publish/subscribe of data across many disperate business processes, then something like JMS or AMQP is a good choice.

JavaSpaces can be used to implement pub/sub-like behavior but that is not its only, or even core, strength. Likewise a space can be used to implement queue-like structures with topics (i.e. the public fields of an Entry acting like topic information as well as payloads).

The big message is JavaSpaces can be used to more quickly create a wider variety of coordination conventions like sparse, distributed arrays of objects, hierarchies of objects, and so on. Moreover, those objects are marshalled with their *codebase* urls for other participants to load. JMS has no such capability to my knowledge.

There is less setup, and more options, e.g. a JavaSpace can look more like a simple database with a JVM doing the writing and taking of its own Entry instances.

"[JavaSpaces] guarantees persistent storage"

More accurately, I hope, a JavaSpace *leases* storage. Leases can expire, not be renewed, etc. So there is no guarantee of persistent storage forever, although in some cases this could be provided.

"How does Coherence relate to this"

I don't know that much about it, but it seems to me Coherence implements various forms of distributed, shared java.util.Map implementations. Based on the choice, more or less of the Map exists in the application JVM, and locks, etc. are used to updated entries more or less atomically.

A JavaSpace exists outside of any of the participating JVMs. Locks are used to get an Entry to/from a space, but there is no update in place at all. Neither are there key/value pairs. Just Entry instances with public fields.

"a Java only solution"

Yes, unless you go with Gigaspaces which has support for C/C++ and dotnet.

Or if you can take a "Java in the middle" position then the Jini parts of Jini/Javaspaces allow integration with other languages and protocols. But Java does have to show up in the middle of everything, and everything else is essentially second-class.

"why are relational databases so dominant?"

Query languages and long-lived support for static data that survives multiple generations of programming languages, etc. Not great, but they've been around for the better part of 30 years.

"no booleans, ints, or doubles"

True, the public fields of an Entry have to be Objects. An Entry is used to "query by example" in a very simple way, and null means "don't care" for that field.

This is not such a big deal, especially with Java 5 which has better support for mixing primitive types and their Object equivalents.

"What Gelernter envisioned..."

I think it is only fair to say that Tuple Spaces was an *influence* on JavaSpaces. I do not believe that the intention was to implement the strict definition of Linda.

"Croquet"

My understanding of Croquet and TeaTime is the intention is to keep shared objects in sync while allowing concurrent modifications among all the participants. A space is different in that participants may come and go, only one participant can update an object, and moreover the update only occurs on the *copy* that was read or taken from the space. When the update is written back, it will be a new thing, not an update.

"why is open source risk free"

I don't think it is risk free. It reduces some risks. e.g. it reduces the risk of having to update on a vendor's schedule. It also reduces the risk not deploying as many instances as desired, when desired, i.e. potential negative results of a combination of licensing structures (e.g. per CPU) and IT budgest (e.g. not wanting to license a lot of development and test environments, or more than a minimum number of production machines).

It is not just about source code. I've worked for vendors and have been a customer of vendors, where source code was part of escrow agreements... if something goes wrong, the code is in escrow and should become available to the customer.

Many commercial vendors such as Confluence (wiki) and Cincom Smalltalk, provide access to, even modification of, their source code within limits.

Rabbit, Run: RabbitMQ

In the too cool category, those LShift wizards come up with a doozy...

We’re proud to announce that the project we’ve been working on for the past few months, RabbitMQ, has been released. RabbitMQ is an AMQP server written using Erlang/OTP. Check it out at http://www.rabbitmq.com/ - or you can go straight to the downloads page for sources and binaries.

What a great combination: Erlang is perfect for scaling out, reliability, persistence, and so on. Plus with AMQP's binary message format and Erlang's bit pattern matching, another, em, match made in heaven.

This could end up kicking some enterprise ass. What's Iona going to use? C++? Java?

Here is the RabbitMQ Java API documentation. Erlang itself has good support for integration with Java and C.

Validating Dynamic Systems

Let's pull our heads out of our enterprisey IDEs, code generators, and J2EE containers. Consider this from Gregor Hohpe...

During our talk we mention an "advanced" technique that would not just render an image of the system model, but also examines the model and alerts the user about potential problems. It does so by applying known rules for "do's" and "don'ts" to the model. These rules could be as simple as "circles in your dependency graph are bad" or one of those sophisticated self-learning AI algorithms that we never quite understand...

One of the key messages we are trying to highlight during our talk is the importance of mapping the captured data to a model that is suited to answering the questions you are interested in. This model can be a graph, a process or any other abstract representation of your system. Making a model is important for a number of reasons...

Which reminds me I forgot to mention a few weeks ago, the second edition of Concurrency: State Models and Java Programs is available. This is a really nice book whether you are a Java programmer or not. Chances are you are using concurrency if not distribution, or will soon.

The second edition has more support for dynamic events and systems.

Not So Bad

Jim Washington compares Python implementations of JSON, including my now-quite-old json.py. It's slow relative to the fastest implementation, but the intent always was to have a fairly clear implementation without trickery or dependence on other modules.

Bugwise it holds up pretty well to Jim's tests. I've not worked on it since JSON adopted scientific notation, and so all those exceptions about finding an "e" when parsing a number.

There are a few other problems, but it holds up pretty well.

Discouraging Words

There are many things I like about Jini/Javaspaces, but as I wrote over on Dan Creswell's blog recently, the documentation...

...needs some work...

Hopefully the long time participants understand just how bad it is. It is discouragingly bad.

Especially for software that's been around for the better part of a decade. Do you want more Jini adoption? Get better documentation for it.

I hope to help. I currently need to build software for enterprise Java programmers, and this is some of the best stuff going.

Jabber and SOAP

I was just finding my way around the "new" blogger tools. Until now blogger could not upgrade my blog given all the old cruft I guess. That's been fixed and so I hope to find interesting features. I think it handles uploading better.

Aaaaaaaanyway.

I was poking around a big long list of drafts the new tool made easier to find. Then I went to my oldest posts and browsed around.

Here is one that is short and sweet from April 15, 2003...

A question: if you have Jabber, do you need SOAP?

That SOAP thing has really taken off since then, hasn't it.

Cruft

Steve Loughran notices there's some cruft in there...

On a related note, the JRE is full of unwanted legacy cruft like an inadequate CORBA runtime, AWT, etc. While something like an XML parser is ubiquitous and stable, choosing SOAP is itself a decision, and choosing Sun's SOAP stack over more popular alternatives is a serious decision. Hard coding Sun's client may seem like a good thing, but in fact just makes it that much harder to upgrade to JAX-WS 2.1

Whole Value

This piece on getters and setters by Allen Holub...

...is a reminder to use the Whole Value pattern if you have an object-oriented language.

Ward Cunningham observes...

I see people refuse to use the abstracting capability of their language and then say that objects don't really work that well. Grrrr.

PL/I

I saw this in the Programming Language News blog...

PL/I for GCC 0.0.14 has been released. It is a PL/I front-end for the GNU Compiler Collection.

I wonder who's using it for what. Which computers ran PL/I in the past? IBM had an implementation for mainframes. Maybe for other mid-range systems as well?

PL/I was the systems programming language for Data General's mini and supermini computers. That's where I used it. I understand this was not quite *all* of IBM's PL/I specification. The language is fairly large.

It is somewhat more attractive than COBOL from my limited experience with both languages. It was straightforwardly procedural and recursive, with a reasonable exception handling mechanism. I'm not sure why PL/I did not win out over COBOL, unless it was the shear momentum of COBOL before PL/I was ready.

Update

Doug Landauer adds some interesting history in the comments. I forgot about Gary Kildall and PL/M.

End

One More Thing

Dan Creswell writes...

the last thing to do is to extend the language

He's speaking about Java in particular but it could apply to all kinds of languages that were never intended for much extension.

Do you want extension? Use Lisp, or Ruby, or Smalltalk. They've proven themselves very well for extensions to one degree or another. Certainly Lisp.

Otherwise choose a reasonable language(s) and use them. Don't pile more stuff on them than they can bear.

Squeeze Box

Another piece on the squeezing of everything into a language and/or a runtime, neither of which were designed well enough to take them on. Keep trying, but this quickly is becoming such a very wrong path.

There's got to be a better way. In fact I know there is.

Just Because You Can

In a subsequent post to the one I mentioned below, Steve Loughran writes...

The only place SOAP survives is in the enterprise, because if you can control both ends of the conversation, you can use the same toolkit and eliminate interop. The key selling point of most SOAP stacks -reverse generation of WSDL from your classes- is actually viable in this context...

He goes on to provide his own hypothetical position statement if he were to attend the aforementioned "Oh Really?" conference...

1. How to provide a client programming model that accesses REST endpoints with the same ease of use as same-stack-SOAP-development?

2. How to integrate Atom feeds and APP into the enterprise as an alternate communications pattern; polling over posting?

3. What is the best programming paradigm for this. Ruby on Rails shows how a dynamic language with continuations and the ActiveRecord database binding makes server-side web development easy. What can we do with clients?

4. How to keep Web 2.0 style applications providing a back end 'service' architecture that meets the needs and business models of providers and consumers.

5. How best to transition legacy middleware -including SOAP systems- to the new world

So what is so great about #1 even within the enterprise? (I've not seen much evidence in a small number of data centers I've seen). There is always a community of IT people fascinated by shiny code generators. IDE support for SOAP is just that. There is no more "architecture" built around these code generators than the CASE tools of the past.

Still on #1, from what I've seen of the SOAP/WSDL approach to using HTTP is total ruin. HTTP is a dynamic, duck-typed approach to "messaging" (ok, "resource transfer" -- HTTP says some things about what's been transferred but that's independent of this point).

Figuring out how to place a code generator for a static language in between the HTTP client and server will likely just gum up the whole works. Better to figure out how to develop HTTP applications in various languages and libraries as simply and *dynamically* as possible.

Which leads to #2. There is a lot of room for HTTP and XMPP to develop in the enterprise. Meanwhile there are open source tools for using these and more API/language-centric tools for coordination/messaging in the enterprise. The real big key is to allow various parts of the enterprise to evolve independently. If the data center can generally be updated incrementally without unduly updating too many parts at once (unlikely from what I've seen), then incrementally moving HTTP and XMPP into the data center should not be such a big deal.

On the other hand if the data center is typical then there are all kinds of unnecessary dependencies preventing *anything* from evolving efficiently. This is the bigger problem that should be addressed first.

Number 3 is a doozy -- the browser has to come around to reality -- it is a *platform* for applications. Multiple, concurrent, independent, and secure applications. Unfortunately even under the best of conditions, the most modern browser is a half-assed piece of work. Coming to terms with that is crucial. Nothing proprietary though.

Dynamic coordination protocols still require contracts. They just aren't used for code generation. So #4 implies the need for contracts that support understanding and change, but clearly not WSDL that only pretends to be a contract.

Finally #5, the transition. See my response to #2. Ease of transition is the key any sort of data center sanity, which explains why the data center is so insane, nine times out of ten. Isolating crap like SOAP and ultimately removing it are steps toward sanity and successful transition.

The Oh Really? Conference: Or, I know a dead parrot when I see one

Steve Loughran lists some of the presentations at an upcoming "Web Services: Not Really. Oh Really?" conference. Look at the list.

The big SOAP boys are now admitting they f'd up big time.

Let's see how they try to make a dime off of HTTP and other really open and already proven and relatively simple technologies. Good luck with that.

That Sinking Feeling

Bill de hÓra writes about the umpteen billion dollars sunk into Vista...

more backseat driving - does anyone outside MSFT understand what it takes to get the OS done at all?

I don't think it is a matter of comprehending how difficult the work is. It is a matter of comprehending the value of doing that work. They are on the wrong track. There is little value in what they've done. The real losers will be those who will have no choice but to fork over big bucks to MSFT.

Far and away MSFT will recover its costs through "update-by-force" rather than "update-by-choice".

I would hate to have *that* as my customer base.

(Update: fixed broken link to Bill's post. Thanks James.)

None Too Soon

Don Box closely reflects my stance on JSON, Lisp, and XML...

JSON has actually eclipsed S-expressions for me as the most obvious way to structure data. JSON effectively gives into the lure of alists and commits to them in a pretty obvious way.

Also, in both JSON and S expressions, the concrete syntax is so trivial (and orthogonal to the model) that it doesn't really get in my way.

I can't say the same for XML.

Although he thinks more favorably about XML than I do. XML could not go away soon enough for me.

Surprisingly I do prefer JSON as an exchange format that Lisp (sexprs). For the reason Don gives above... it is very easy to see the alists and the arrays (true lists) in JSON than it is in Lisp.

So while I would dearly prefer to program in Lisp (Scheme) than any other language, I would want to exchange data via JSON.

Not a problem... in Common Lisp, Gambit Scheme, and several others, the neat thing to do is create the read-table syntax for JSON.

Late To The Table Again

Update:

The evidence this time has caused Microsoft to withdraw the patent over the last few days. The BlueJ Java people, who already credited Smalltalk, had been in recent contact with Microsoft prior to the application and were very upset about the patent application. Bad press was visibly having a negative affect.

Would that it were this way with the less direct instances of prior art. No kudos to Microsoft here -- this is a case of one's back to the wall and the spotlight shining down from the police helicopter -- you're about to be on a reality show.

End

James Robertson writes about another Microsoft patent application in the 21st century that consists of prior art from the 1990s if not earlier.

Here are some other candidates for prior art from what I can tell. (I can only read so much about Visual Studio and then I begin to lose my lunch.)

• The Smalltalk "diagramming debugger" is from the 1980s. Ironically the author, Ward Cunningham, worked for Microsoft for a few years.
• The Smalltalk "Object Explorer" is currently included as a goodie with VisualWorks Smalltalk I think. This is by Kent Beck and goes back to the same time frame when Ward and Kent were at Tektronix.

Maybe someone more at peace with Visual Studio can say whether these diagrams resemble what has been patented. (I am sure the newer tools have much more suckage.)

Diagramming Debugger

Object Explorer

Semantic Agnostics?

There's a comment over on James' blog stating a key part of the Microsoft patent may be it's "language semantics agnostic". Get over it. All the languages that can participate in this diagrammer have to share the dotnet object model and enough of the dotnet runtime to get the bits to the display. If that's not "semantics" then what is it? Well, it's actually pretty *bad* semantics to make all these languages use the same (pretty awful) object model.

Fighting The Good Fight

Fuzzy has a good idea: a site for bad software patents with the details, prior art, etc.

Cadence and Smalltalk, Sun and Cincom

So, what the heck is going on over at Cadence? They've hired the Smalltalk/StrongTalk/Java-HotSpot wizard from Sun (Gilad Bracha) and a couple of key Smalltalk folks from Cincom. One of whom (Eliot Miranda, at least) is like Bracha, a very knowledgeable person at the compiler/hotspot optimization level.

Visual Works has a pretty mature compiler/runtime, but that has to be a loss.

Sun is just getting started with dynamic languages on the JVM... that seems like more of a loss.

And Cadence is hiring more Smalltalkers.

Interesting. Cadence has been one of the leaders in computer-aided electronics design for 15+ years. Way back when they were one of the first to incorporate a dialect of Scheme into their design tools. That led to or was closely associated with EDIF, the Electronic Design Interchange Format, based on Scheme/Lisp syntax. (Way better than today's XML, but... another day.)

Monothickic

The Pragmatic Dan Creswell (Dictator?) writes...

Java is getting heavyweight...

Java is designed to be dynamically extensible not monolithic and static as is the prevailing pattern pursued by Sun’s JDK development team and the world of J2EE. Remember, Java in it’s early days was all about code-downloading and dynamic extension...

To Schwarz, Sun and the Java masses, stop leading Java down the path of static, ever-larger, monolithic bloatware.

It's Mainframey!

Jobs Is Gravity

I wish the iPhone had a different name and was a more open software environment right from the top. I think it will get there eventually. Michael Lucas-Smith hopes for the same, but then writes...

Screw you Jobs, you're an idiot. Stop taking credit for the brilliant work your engineers do to make Macs so great. Hey, have we all forgotten how jobs wanted to limit Mac memory and while he was out of town his engineers pumped the Mac memory up to 2mb? Let us not forget how he managed to split the Apple company in two with his Apple vs Mac wars. What a moron. Get a life.

This is going *way* overboard.

From what I understand, Jobs has been responsible for a number of bad ideas, some of which made it into product and some didn't. But Apple is a unique company. There are several reasons for that, and they all revolve around Steve Jobs in various orbits.

Woz designed the Apple I and II which were far beyond everything else and set the course for Apple's uniqueness. But Woz was content building neat things for his friends to admire while working at HP forever, HP ignoring his genius forever. Jobs went out and made the sales that launched Apple.

From that point on there appears to have been two Apples. One of the Apples was continually pulled into the gravity that weighs down every sizable organization.

The other Apple was continually pulled into the gravity of Steve Jobs. (That gravity left Apple and became NeXT for quite a while, but even then some of the planets were still at Apple.)

Without Steve Jobs then:

• The Apple II probably would not have become a business success, funding everything to come.
• Even if it had, the Macintosh probably would not have existed.
• Even if it had, it probably would not have been delivered in its pleasing vertical case.
• Even if it had, it probably would not have emphasized rounded rectangles in its user interface.
• Even if it had, it probably would not have been supplanted by the NeXT OS and NeXTStep to rescue it from oblivion.

Jobs did not create all these things himself, but he pushed for them and demanded them, and they made all the difference. Without Jobs the result is something much more like Windows, and that would suck.

I am pretty sure Jobs is the force that moved all these things together in the right direction. He demanded more than what any of the contributors would have done on their own. Bill Atkinson was pleased with his algorithm for drawing ovals. Jobs pointed out that rounded rectangles are everywhere. Atkinson initially objected, but quickly figured out how to draw them efficiently.

We would be in a world that is much more square without Steve Jobs.

Even the Windows API has a RoundRect procedure.

Coincidentally the Toronto Globe and Mail refers to Jobs like this...

"Microsoft has a certain cult of personality. Gates is thought of as a special guru, and people sit at his feet trying to understand what he's thinking," says Roger Kay, president of Endpoint Technologies Associates Inc., a research firm in Wayland, Mass. "That's totally different from Steve Jobs. He's an autocrat. He's a sun king. He's very capricious, autocratic, and creative and charismatic. He's all kinds of good things, mixed with some pretty strange things. It's a totally unique formula."

The personalities of both men have been imprinted on their companies for years.

He's a sun king. I love it.

Killing the Buddha

I am getting nostalgic for programming in the supermini era. We *really* had "no rules" then. I was writing "CAD tools" for designing electronics. We had a home-grown programming language called "MPL" (by another group in Boston, most likely just "some guy", for some reason the name John Barstow sounds familiar). I recall it officially stood for "Macro Programming Language" because it was a Modula/Pascal-like pre-compiler for PL/1. (Data General's flavor of PL/1 was its systems programming language. There was no "C" compiler for DG for a number of years yet.)

Our unofficial name for MPL was "Mud PuddLe". In fact we had no other name for it. I take that back, now I am recalling a more offical name was "MaPLe". I think only the CAD tools group called it Mud Puddle. Now I think either Harry Newell or I invented the name Mud Puddle, but I could be way wrong on that.

Our graphics/UI system (I don't think we had the term "framework" then) was called "Reddog". This was a 2D, retained graphics system and it was also home grown (by a DG group in Austin, again just "some guys", I think Kerry Kimbrough was one. There were just a few women programmers that I knew of at DG. My manager's wife was in the OS group. Three(?) women were in the CAD tools group.) The Macintosh would come out a year or so later. I had seen the Lisa at school, and did some programming on Lisp machines. At that time DG had no official "window system" and no document for "user interface guidelines".

(I thought it was cool later when I got my Mac512k, the Manx C compiler, and the "phone book" edition of the Mac API guide. I think that was the first time you didn't need a $10,000 Lisa to program a Mac128k.)

We stored our "domain" data in files. The schematic editor for example just used the Reddog graphics file itself to store all its electronics data. Heck, it was a tree and had lookups. Otherwise we'd just have to write our own indexing, etc.

Not too long after I got to DG another group there told us about this thing they developed, a "relational database". (Apparently Oracle was a fairly new vendor of these things for the VAX or something but none of us in CAD tools knew about them.) We looked at how to use it for electronics data. There was no such thing as a "DBA" to tell us what we could or could not do. SQL seemed pretty cool, these "queries" for getting data out of the database.

The bottom line is we had an operating system and a compiler. There were no rules.

"If you meet the buddha on the road, kill him."

Superminicomputers

I got out of school at the apex of the "superminicomputer". Minicomputers had been 16-bits for a number of years, going back to the Data General Nova and DEC's counter with the PDP-11. (Interestingly DEC had 12-bit and 24-bit systems before the PDP-11.) I went to work for Data General as their new 32-bit system rolled out in competition with the DEC VAX. These were called "superminicomputers".

If the J2EE server is the modern mainframe, what is the modern minicomputer? (Please don't say it is the Enterprise Service Bus! 8^)

The PDP-11 is probably my favorite computer to program of all time, even though all I ever used was the assembler. Maybe time makes the heart grow fonder. We had a network of six or so all in a room at school. As I recall the boxes were just a bit larger than a dorm room refrigerator. The instruction set was simple, and we just had fun running and enhancing a very simple custom OS with networking.

DEC PDP-11/23 16-bit Minicomputer

Data General 32-bit Eclipse "Eagle" Superminicomputer

The Modern Mainframe

I forget where I saw someone refer to J2EE servers as "mainframes". The brief mention struck me with some humor and some accuracy. I've not thought about it since, and one could argue I'm not thinking at this moment.

Still needing an update on what these things do, and reading through a few topics in some detail, that analogy came back in a flash. There is a deeper truth, while there has been great progress: they support one or more "modern" languages, they include garbage collection, they run on really inexpensive hardware (often clustered rather than a single ginormous piece of iron on a raise floor -- but the power issue is back with a vengance for some), and take a good bit less configuration.

On the other hand, their configuration (typically in XML) is not unlike JCL, they load a lot of various pieces into conceptually a monolith, include various "isolation" mechanisms alongside various clustering/sharing mechanisms. I don't want to take this analogy too far -- it just struck me recently -- and systems like JBoss have interesting designs with its JMX/MBean microkernel.

Not that all of these are necessarily "bad" things. But I do get the sense of a monolith that doesn't necessarily fit the idea of "small pieces loosely joined" even when the ugliest parts (e.g. EJB) are ignored and the better parts (e.g. JMS) are emphasized. Today I would think an organizations evolutionary intentions should be to move away from mainframes.

Should the same be said for J2EE *today*? If not today, then *eventually*? If so then, toward what? I have a lot of ideas about the "eventually* part, and a few about the "today" part.

No Rules

"Hell, there are no rules here - we're trying to accomplish something."
— Thomas Alva Edison

Class Loading Issues in Java™ RMI and Jini™ Network Technology

This really belongs in the details of the Jini documentation. I found it very helpful. Confused why this is a Sun *research* paper rather than just good exposition for understanding the mechanics (and touching on what should be in the "design rules") of Jini.

Class Loading Issues in Java™ RMI and Jini™ Network Technology

On the one hand it makes a dynamic language programmer suggest this is more evidence against compile-time type checking, and it makes a Smalltalk programmer suggest this is more evidence against not treating classes as truly first class objects, and it makes a Scheme programmer suggest this is more evidence against treating objects as anything more than closures...

On the other hand it does give one hope that Java can be used effectively in a distributed environment.

Wrong Answer

From MacRumors.com...

A New York Times article reveals some information about Apple's iPhone and the possibility of 3rd party applications.

The article quotes Steve Jobs about why Apple does not want to allow any 3rd party developer make applications for the iPhone:

“We define everything that is on the phone. You don’t want your phone to be like a PC. The last thing you want is to have loaded three apps on your phone and then you go to make a call and it doesn’t work anymore. These are more like iPods than they are like computers.”

Well, the iPhone (and why doesn't Apple Incorporated take this opportunity to move *away* from the now-worn-out iThingy naming convention?)... restart... well, the iPhone, believe it or not, *is* a computereven though the corporation took "computer" out of its name. What an opportunity to provide a reliable runtime environment, where applications are sufficiently isolated to avoid each other and robust enough to recover, etc.

When our computers all move out of their general-purpose boxes and into special-purpose embedded environments, we'll still want open access to them without signing up as a priveleged software vendor. That's where most of the new ideas will come from.

A Bigger Dork Than Me?

Update:

Uh, yeah. So I did read the press release. Maybe I missed something but it does appear to require Vista and it does not appear to support anyone else's system (MacOSX, Linux, etc.) So if you *like* the bundled mess that is the Microsoft product line, and your OS is running in the future (the same future that will run this server), then this product *might* be for you. If your hardware is old and your OS is older than the future, or from a non-Microsoft OS vendor, then you appear to be out of luck. Unless you wish to upgrade every thing you own. Then by all means.

So here is what you do... go down to Best Buy. Tell them you want a network storage device and a print server, all in one. Tell them you want a redundant disk. They probably have several brands. If you have another reasonably good electronics store in town, they probably have another one or two brands to choose from. Buy one today, and it will continue to work with everything you have today. Just don't upgrade to Microsoft's Digital Decade OS of the Future. That one will almost *certainly* not work with anything else you already have in your house.

Bill sucks. Microsoft has no clue. This "Digital Decade" (how catchy!) we are in happens to run on the *internets*. They are a series of *tubes*. They are *independent* of your specific operating system. Especially if they are of the future of which Microsoft wishes to bind you to.

End Update

And that's saying something. A part of Bill Gates' so called "Digital Decade" is to someday release a "Windows Home Server" for "less than $500"...

If you have multiple PCs, then you want files that are available all the time no matter which PCs are turned on or off, and you'd also like to have a server that, when you just add storage, it automatically takes advantage of that. You don't have to think about drive names or moving files around.

In fact, you get redundancy, so even if you have physical failures you have recoverability... We think it is a real leadership product. Homes with multiple PCs will find it very attractive.

Guess what, Bill? You need to get out more, even if it is just down to the local Best Buy store.

For some time now I have had a network storage "server" running at home. It plugs into the network and just works. You can add as much storage as you want as larger disks become cheaper.

I plugged another USB drive into one of its USB slots. The box knew by default to use this drive as redundant storage. We use the network drive for common storage (across Windows 2000, Windows XP, Linux, and MacOSX) as well as for backup storage for each of those other machines. The USB drive backs up the common storage and backs up the backups.

Did I mention this "home server" also has a network print server? Yes, just plug in a printer's USB cable to another of the server's USB slots. I hope Bill's print server is as easy to setup (for MacOSX and Linux as well as all the Windows) whenever it arrives in Best Buy.

This setup came in many months ago at less than half the $500 target of Bill's. OK, I had a USB drive anyway I could use as the redundant storage. So purchasing that brings the sum into Bill's neighborhood *today*.

Will Bill's system work as well across all these other systems? Will it even work with Bill's own obsolete Windows 2000?

One more thing... this server of mine happens to run Linux and Samba (I know that because I am a geek and a dork, but no one needs to know that.)

Well, people with these servers may eventually find out once they bring Vista into their homes and Vista refuses (apparently?) to work with the Samba software. One more reason Vista will never see the inside of my house.

One more quote, but from Microsoft Watch...

The product will open up new sales and services opportunities for the channel. Many consumers can't properly configure a Wi-Fi router now. It's unrealistic that many could set up a server without some assistance.

http://en.wikipedia.org/wiki/Zeroconf?

Dynamic Panic

Mike ("Fuzzy" to you) and Dan Creswell are working on the Jini comfort level. I think the answer is to make the Jini starter kit more comfortable. If we stay with Jini then I hope we'll be making some contributions along those lines.

Currently Jini examples are kind of scattered in terms of where they can be found, whether they run with 2.1, what spectrum of Jini/Javaspaces they cover, and whether they reflect one person's style or some community-level "best practice".

I like examples that are small, build on each other, and "just work" with some clear code. That can be a challenge with a dynamic, distributed system like Jini/Javaspaces. There is a way to go with this in general, but some candidates can be found, and we're doing some ourselves.

Back to the question though, about having a Javaspaces without Jini. Because of Java's instance/class/class-loader/serializer design, Javaspaces would not be better without Jini. How many Java systems have (or suffer from the lack of) a decent dynamic loading capability? Jini *is* such a thing that could be used in many situations.

Even a Javaspace that is used merely to pass "data-only" entries around require dynamic class loading unless you desire explicitly managing the classpaths of all the JVMs participating. Putting methods on those entries or the objects they contain just make the need for dynamic class loading more obvious.

Not to mention that Javaspaces themselve are turned into dynamically available Jini services, available through smart proxies, distinguishable by entry values, and so on.

I suppose I am more comfortable with the idea of dynamic loading right off the bat. I have written a lot of Lisp and Smalltalk code that's gone into production, and kept running right through dynamic loading of fixes and enhancements. Gemstone Smalltalk even supports bulk or incremental migration of Smalltalk instances from one class version to another while the system continues running.

Jini and Javaspaces seem to be the Java mechanism most aimed at this level of dynamicism. Are there others?

Damn Readable Information Exchange

Planet Intertwingly’s memes.json (Sam Ruby).

Hella more readbable than XML-IMHO.

A Little Is Enough

Reflecting on the man's hanging, and the current mess the U.S. and Iraq are in, I'm recalling Philip Greenspun's controversial blog post from 2003...

By the standards of wealthy Western countries Saddam’s regime was harsh. They tortured and/or killed political opponents. They controlled the press, the mosques, and the schools. If a town were restive they might kill its entire population or at least many hundreds of people from that town. This would seem like gratuitous cruelty if done by the governments of Vermont, Dijon, or Bavaria. But in the Arab world more or less every government employs the same tactics as Saddam’s Iraq.

In fairness to the defeated dare we ask whether Saddam’s regime wasn’t employing the minimum amount of violence necessary to maintain public order in Iraq? It seems quite possible that Saddam did not enjoy terrorizing his subjects but did it because he understood the divisions within his arbitrarily drawn borders and thought keeping his subjects in fear was necessary...

We haven’t figured out what level of governmental coercion will result in an Iraqi society that is both orderly and submissive to a U.S. occupation or whatever American-friendly government follows. Saddam may yet go down in history as the kindest and gentlest 21st century leader of a unified and stable Iraq.

Resilience and the Javaspaces Model

One of the good high-level programming model introductions to Javaspaces is available behind a registration wall. I was handed the PDF but since it is copyrighted yet free, I'm uncomfortable posting it for you. I'd recommend you register and get it if you are curious about a simple model meeting a common need where Javaspaces provides much less effort than, say, JMS.

I'll call it "Resilience and the Error Hospital" while the actual title has more buzz words (e.g. SOA) and no direct URL.

The Great Beyond

Someone's been to the mountaintop...

Fiji has nothing on Vienna, which is purported to feature a complete overhaul of the OS, including a break in compatibility with "all applications," though hopefully Microsoft will have some Apple-esque transition schemes in place before that time comes. The fresh beginning will give Microsoft more OS-building freedom than it has had in a long time, but right now it sounds like they're a bit too excited about this: Vienna will supposedly do away with the Start Menu, toolbars and menus in favor of some sort of pie-menu interface, WinFS-to-the-core and search, potentially leaving long time users stranded with a brand new interface to learn from the ground up.

The OS will also feature beefy speech support, along with a sandbox mode for running non-managed code without risking your security. Much of this is hearsay so far, and we're really hoping Microsoft doesn't go off the deep end with Vienna, but we're still curious to see what they have up their sleeves after being cooped up so long ironing out Vista bugs.

Remember, when Apple *bought* their "new foundation" code base it was already more than 10 years old and had been in production in such places as Wall Street trading environments. Not to mention that the very core of that new foundation was many years older than that, and had the benefit of so many smart brains in multiple academic and industrial organizations around the world.

So who will Microsoft buy? This is the only viable option, is it not? (Assuming the rumor is true and the goal would be to deliver to production around 2012-2015.)

Update: On a related note, Kurt Cagle's prediction...

I think that Vista will be the denouement of the Gates’ era, and will likely prove the catalyst for some major senior level bloodletting and organizational redefinition. Part of this comes from the question of whether in Microsoft’s efforts to define the next big operating systems they kind of lost sight of the question of whether investing in a new OS was really the best strategy moving forward.

Ford: No, Not *That* Ford

From Market Watch...

Ford and Microsoft will jointly announce the Sync initiative at the Detroit auto show and the Consumer Electronics Show in Las Vegas...

While the Sync system is complex...

Enough said.

Wii-orld of Warcraft

A You Tube of some crazy hacker guy playing World of Warcraft using the Wii remote.

(You realize that WoW is *not* running on a Wii game machine, eh?)

Blitz 2.0

Also from Dan Creswell, a new release of Blitz Javaspaces is nearly available.

If you are not familiar with Javaspaces you will want to understand the programming model. (Among other resources, Dan's.)

Javaspaces is the most dynamic Java programming mechanism I know of. If you have a need to use Java but you like dynamic language things like Smalltalk, and dynamic concurrency and distribution like Erlang, you may like the Javaspaces programming model.

If you like object-oriented databases (for some strange reason), then Javaspaces gives you 80% of those benefits at 20% of the pain, suffering, and risk. No one really needs that other 20% of the OODB benefits anyway. Some kind of a database is typically involved in a complete system using Javaspaces, but it plays much less of a central role in the goings on.

Code Shrink, Programming Models, Patterns Are Dead

I was going to make a fairly short post pointing to Mike's observation of applying different tools and models to a familiar problem. An initial measure of effort and benefit is "code shrink" and that can draw you into the new approach even more.

Then I read Dan Creswell's post also about comparing JMS and Javaspaces...

In general, to measure the true suitability of a technology to a problem one must solve the problem in the appropriate way for each technology we are considering rather than from the single standpoint of a technology we are already familiar with.

This is something our group has been working a lot the last few weeks, i.e. the programming models for the tools we are considering. Some are more familiar than others. Also just determining where to start and how to get into a new tool and its model can be challenging. And then in some cases, rewarding when discoveries and insights are made, and you begin to see where things may lead.

By the way, the thought crossed my mind again recently... has "agile" killed "patterns" or did it die on its own? Are "patterns" the best way to present a new programming model? Does anyone really "do" patterns anymore, the way the original movement intended? Or do we just write some text and draw some pictures and call them patterns? Is there any point to the "patterns" idea anymore? I'm not sure either way.

In any case, Mike's and Dan's posts are worth absorbing... it takes some work to get into a new model, and not just repeat the familiar using a new API.

I look pretty young, but I'm just back-dated, yeah

Tough questions about Apple's "options mess". (Under-reported financial scandal of the year if not decade spans many companies, many of which have not been discovered yet. Why are share holders not way up in arms? The ultimate white collar crime?)

Elayne Boosler

I really enjoy listening to Elayne Boosler when she fills in on the Stephanie Miller Show. Her wit is wide ranging, quick, and insightful.

Apparently she also is a thoughtful blogger...

Through all the negotiations in writing between the two generals leading up to the meeting of surrender, the points reiterated by both over and over again were the desire to "avoid useless effusion of blood", and to "save thousands of human lives, and hundreds of millions of property not yet destroyed". So while the south was bled, there was still much havoc and destruction to effect barring Lee's decision. I find the most moving phrase of Grant's letters, especially in consideration of the fact that he was winning at the time, to be: "..Seriously hoping that all our difficulties may be settled without the loss of another life.." A lifelong fighter who had seen the loss of millions understood the value of one more life. The terms of surrender and disposition of the men were subjects worked out in advance, and with great civility, befitting two warriors who understood the comportment of battle. While they could have fought to annihilation, as men who had actually served before, they knew the arc of war. They understood it took at least a few people left alive in order to form a more perfect union.

It's almost 2007. ..Seriously hoping that all our difficulties may be settled without the loss of another life...

Sources

• "John Brown's Raid, 1859"
• "Surrender at Appomattox, 1865"
• EyeWitness to History, www.eyewitnesstohistory.com (2004)

Magnificent. Peace be with you in 2007.

A Vista of OSX

Fuzzy: "I love OS X. It is the only thing to have your family on."

Windley: "I love OS X. Simple as that."

Fortran 2007 Anyone?

Will 2007 be the year of Dynamic Languages? Or was that 2006?

2008?

From Infoworld's 2007 predictions, Paul Krill writes...

I’m betting that by Christmastime 2007, people will not have noticed much difference at all...

Java in its so-called closed implementation already had spawned open source projects ranging from the Spring Framework to Apache Jakarta and the Eclipse project. Open source Java application server vendor JBoss also built quite a business model without needing an open source Java.

So, in 2007 we might have to look to the Microsoft camp for excitement in the application development space, because Java’s big splash won’t amount to much.

Of course most people even in the Java world will not be immediately or even directly affected by the implementation going open source. It will still be Java 1.6, or whatever version gets the treatment initially.

But neither would I expect the nod therefore to go to dotnet. The culture there waits on Microsoft, and then studies the scripture. They will be busy studying Vista and such. Ho-hum.

Meanwhile the Java world will continue to innovate in the open market as Paul describes. I don't think 2007 will top 2006 in dynamic language ways though. The Python and Ruby implementers made their announcements in 2006, and so will be getting down to business in 2007 with initial deliveries.

I think the 2007 language breakthroughs are still clouded. On the other hand its very post-modern. They won't be neat breakthroughs.

32

From Infoworld's predictions for 2007, Tom Yager writes...

By mid-2007, 64-bit quad-core CPUs will be the de facto standard for x86 desktop and server computers. A sub-$5,000 two-socket workstation or server will sport a mind-boggling eight processor cores. Intel engineered its dual core per socket Woodcrest server/workstation CPU to allow a four core per socket upgrade with nothing but a chip swap. AMD has done the same with Opteron and Athlon 64 FX systems built after Revision F. AMD’s capacity to expand Opteron systems to eight sockets means that in 2007, IT can buy 32-way servers for the price it once paid for four-way servers. Talk about consolidation!

Somewhat Fuzzy -- Anyone Have a Whiteboard?

An interesting thread around distributed data structures and coordination models. I'm not sure where it is going, but I'm interested in the finale.

I could use a whiteboard right about now.

Em, did anyone mention shared memory yet?

Trading... Up?

From playfuls.com comes no surprise to Wii aficionados...

The folks from GigaGamez ran this story a few days ago, after several searches on Craiglist revealed quite a few PS3 owners willing to depart with their hard-earned console, in exchange for a Wii and, generally, some extra cash...

And it's not just a couple of people, but a whole lot of them; and by the looks of it, more and more are joining this "trend" by the day...

You could say that Sony got off to a bad start, but then you'd be over-estimating them.

I saw a PS3 at a store a few days ago. Someone was playing a basketball game. The graphics were really good. The hardwood floor basketball court was shining a little glare in just the right places as the camera moved around. The figures were better than I've seen in a game, but not spectacular. Their movements and the crowd's had more of the look of a televised game than I've seen in other games.

However the player was still using pretty much the standard controller of the last several years. I hear it has some gyro capabilities, at the sacrifice of a rumble. There was nothing in the players expression that conveyed the fun and "magic" of a Wii controller, nothing by a long shot. As James Robertson has commented several times over the last year, if I were in a store with maybe $600 to spend, but more likely less, even after seeing the PS3 in action, I would have to think quite a lot about where else I could put that $600.

An easier decision would be to but half of it in a Wii with the Sports game plus one more, totalling about $300. That would still leave a plentiful $300 for more games, an ipod, or many other things... including letting it sit in the bank knowing I got the most magical game experience for much less.

Ajax'd to a Standstill

My "go-to" web page for TV listings for years had been Yahoo's. I could get to where I wanted to be in two clicks. Now they've gone all Ajaxy on me. I've tried several times over the last month or so to just bear with it.

I thought perhaps I just have to find the right links, or perhaps they'll improve the page. Maybe I should have sent them my opinions. But don't they have some evaluation process? Do these evaluators just get along with this new thing better than I do?

Maps are in a similar place for me. Both Google's and Yahoo's map services are not nearly as functional for me as the previous, non-Ajax, Yahoo map.

I used to go to maps.yahoo.com and tv.yahoo.com with ease and comfort, knowing I'll get what I want quickly. But no longer.

I am on the lookout for a simple TV listing and a simple map, no Ajax required, or frankly, not even desired.

Zap2It may meet my needs for TV listings.

Wii / Not Wee

This is something to try... a Wii Sports session at a movie theater (YouTube).

Anyone Seen Ray?

From Microsoft Watch, watching for signs of Ray Ozzie...

So, where is Ray Ozzie? ...

If you've seen him, please tell us where, and, Mr. Ozzie, if you're reading this, please do send us an e-mail or instant message. If you prefer, we could rendezvous in one of those Groove work spaces. We would even be content to see you blogging again.

Point and Click Opera

I've not been able to get control of the Wii long enough to try the Opera browser yet. My kids been browsing with it. The test I'll use is Bloglines. I can browse Bloglines on my Blackberry pretty easily with one hand, while standing up on the train. If I can browse as easily with the Wii Remote from the couch, happy, lazy me.

Eventually Nintendo will have to come out with a wireless keyboard for anything more than casual browsing. And why shouldn't they?

Intelligent Design?

Jerzy points in a comment to an earlier post an Economist article on why Windows, and particularly Vista, is continuing to win the OS war. An excerpt from the Economist...

But unlike Windows, downloading applications to run on Linux and ensuring all the necessary “libraries” are in place is most certainly not for novices.

But the real difference between Unix-like operating systems and Windows is their design philosophies. Windows may squander computing power through its clumsy architecture. But by favouring simplicity of use over simplicity of design, Microsoft has been able to leverage cheap but powerful commodity hardware, to provide cost-effective software solutions.

On the first point about dependencies, I have found recent releases of Suse and Ubuntu, particularly the later, to handle this well, including updates to previously installed software. I have certainly encountered at least my share of problems with Windows components, but so have I used Windows for a wider variety of purposes, e.g. I have not yet used desktop Linux with cameras, digital audio devices, etc. What little experience I have with Macs and these purposes (external DVD recorder, digital camera, and printers) tells me that it works a good bit better than Windows.

The second point that troubles me in this quote is that Microsoft's operating system as a whole is more efficient and cost-effective from a hardware-cost perspective. I can offer strong evidence against that regarding Windows XP and Windows Vista. I have hardware that is long paid off that continues to run every version of Linux I throw at it. However on the Windows partition it cannot run anything more recent than Windows 2000, i.e. XP (through experience) and Vista (I am told) will not even install, let alone run as efficiently as the newest Linux distributions.

I will also touch on their notion that Microsoft has given Windows "simplicity of use" at the cost of design complexity. "That's funny ha-ha!" is the only reaction that comes to me. By what measure is Windows easier to use than MacOSX or Ubuntu Linux?

Update: (via James Robertson, "Load the Stupidity Module") an analysis of the cost of Vista's "content protection" mechanisms. If so, then Vista will raise everyone's hardware costs, not just Vista users. Sheesh. Thanks.

As a user, there is simply no escape. Whether you use Windows Vista, Windows XP, Windows 95, Linux, FreeBSD, OS X, Solaris (on x86), or almost any other OS, Windows content protection will make your hardware more expensive, less reliable, more difficult to program for, more difficult to support, more vulnerable to hostile code, and with more compatibility problems.

Miguel de Icaza's take on this ("Content, Restriction, Annulment and Protection (CRAP)") is classic...

Microsoft: Shooting itself in the foot. One toe at a time.

Inversion of Containment

Update: Guy Nirpaz addresses the issue further. I'm in the middle of the USC/Michigan game and can't concentrate yet.

End

Guy Nirpaz talks about all the containers available for Java applications. Some are heavier than others. Some provide more lifecycle control than others. Co-workers have looked for several reasons at OSGi and JBoss' use of JMX/MBeans.

My Jini Goggles are on right now for related reasons. While Jini per se is not a "container" there are mechanism built in and on Jini that provide some lifecycle support. In-the-large: e.g. Rio. In-the-small: Leases. And the Jini mobile object mechanism is a kind of runtime "injection" mechanism with security.

What is a "container" and are there pieces of Jini that provide an "inversion of containment" to meet similar objectives? I'm just thinking. Do you need something like Spring to abstract Jini, when Jini itself is an abstraction of lookup, injection, etc.?

The Movement You Need

Interesting movements in the Jini/Javaspaces world. Looks like Apache will likely accept it as a full-fledged project and there is a newly published book from Apress.

A prediction or at least a suggestion for 2007... the various Apache and other open source ESB's should look at Jini/Javaspaces to either/both (1) consider it for under-the-hood capabilities, or (2) exposing it's legitimate capabilities alongside the ESB's.

Gigaspaces has taken a step in this direction with Mule. The open source combination of ESB and J/JS would have many of the same advantages, in a completely Apache/OSS fashion.

Kudos

Although I rag on MSFT 99% of the time (and think they deserve it, but more on that later :-)...

I was just thinking they do deserve one big nod for seeking out people to help get them into the new world, like Ozzie, Cunningham, and Udell. Hopefully the organization will pay attention.

Update In Place vs. Coordination Space

Data caches are good. Even distributed, shared, clustered data caches are good. There are many applications where this is the right thing to use.

Comparing them to Javaspaces is kind of nagging at me. In some cases one product can serve both purposes. E.g. in Gigaspaces, the developer can choose the Javaspace API or the Map/Cache API. They can also do funky update-in-place things within a space kind of too, but that is explicitly not in the Javaspaces API per se.

In any case I think it is imperative that a developer chooses what kind of mechanism they need for specific situations. And I think there are critical differences between the Javaspace mechanism and a data cache mechanism.

In particular, certain data caches run *in* the address space of the client JVMs, while a Javaspace is *never* in the address space of the client JVMs. (There are caches that run outside the address space, e.g. memcache, and that's another angle on the topic.) When these caches use the java.util.Map API there are potentially funky goblins at play. A regular java Map has certain expectations.

Consider an object V1 with a direct object reference to object O1. Now consider another object K1. Put V1 in a shared, clustered cache using K1 as the key. Update object O1 in that JVM. In another JVM in the cluster (JVM'), do cache.get(K1') to get a copy of V1' referencing a copy of O1'.

In this second JVM', update that O1'. Then from there do cache.put(K1', V1'). Note: a cache is *not* a transparent transactional memory OODB like Gemstone/S or Gemstone/J. Not that you'd want one of those anymore, but they do go to pains to maintain referential integrity, which is the cliff this example is heading off of. So the put in JVM' will soon update the first JVM so that the key K1' leads to the value V1' with a reference to the object O1'.

Meanwhile in the first JVM there is still, outside the cache, the objects K1, V1, and O1, with V1 referencing O1. When this JVM does cache.get(K1) it gets back V1' with a reference to O1'.

Question: In the first JVM what are the identities of the objects K1, K1', V1, V1', O1, and O1'?

Answer: I believe the answer is dependent on the cache implementation. I am not sure what the JCache spec says. Either there is leeway or not all caches do the same thing, and none of these things may be what the developer expects based on experience using the out of the box java.util.Map classes in single or concurrent threads.

In JBoss Cache the developer has the choice of a "tree cache" or a "pojo cache" (maybe others). The behavior will be different based on this choice. A pojo map will patch up object references *within* the stream used to cluster the distributed caches. The tree cache does not. And I think this behavior can vary based on the use of their AOP mechanism.

Even the pojo cache though does not patch up references as far as I can tell, ever, among cached objects and their former references in a JVM outside the cache per se. I.e. the deserializer does not do a sweep of the entire JVM address space to fix identity problems.

This is not necessarily a bad thing when the cache is used as a read-mostly, shared data cache backing some external data with a well-controlled update convention.

A Javaspace does not have this problem because of a simplifying specification -- Javaspaces do not deal with object identity in JVMs. You always get a new object. If you want to deal with identity then code it yourself in the Entry objects. But really don't do that very much!

That is different, and maybe not what you'd want at first. But that may indicate your not using the best mechanism for your problem or you're not thinking about the mechanism the best way yet. This is one of those "architectural constraints" that seem to get in your way, but actually can simplify the solution to a problem for certain classes of problems. E.g. when the problem is "coordination" of processing rather than "clustering" of read-mostly data.

Yes?

Deliberately Misguiding Windows Me

From Information Week. I have a computer at home my wife uses. She needs Windows, the PC is fine, and won't even run XP. So it runs Windows 2000. (And every version of Linux up to the most recent Ubuntu and Suse! But she needs to boot into Windows.) We all know its "VersionNT" under the hood. Not that I am looking to run MSFT Defender, but this is just silly. $10 billion USD at a minimum spent on Vista! Unlikely I'll ever have it in the house. At some point I'll move her Windows 2000 and some other XP systems my kids run to virtual images on Linux and/or MacOSX, where they will remain in their formaldehyde virtually forever.

As other new products emerge from Microsoft in 2007 and beyond, more and more of them are likely to leave Windows 2000 out of the party. Which of these installation restrictions are caused by a real lack of capabilities in Windows 2000, however? Are any of them merely a "squeeze play" by Microsoft to convince buyers that it's necessary to immediately upgrade all PCs to Vista and all servers to Server 2003 or the forthcoming Longhorn Server?

One example of this conundrum is Microsoft's Windows Defender program. This antispyware program can be downloaded for free, but it will only install on Windows XP, Server 2003, and higher. The application won't install on Windows 2000, according to Microsoft's own product documentation.

Users have reported, however, that this is simply an artificial rule built into the Installshield package that copies Defender files to disk.

The installer contains a condition defined as VersionNT > 500. (Windows 2000 is technically considered version 5.0 of Windows NT.) Admins who've removed this condition using Orca, an Installshield editor, say Defender then installs and runs fine on Windows 2000.

Em

Alright I've been tagged by Dan Creswell. I just came across this tag thing a few days ago. What to say... I'll be borrowing some ideas from others, so you may recognize the patterns but hopefully not the specific content.

1. I was a Frank Lloyd Wright fanatic in high school. I was in the school of architecture at The Ohio State University (that's the proper name folks) for a couple of years. This was 1979-1981, on the heels of the energy crisis of the time, and I wanted to build solar houses. The problem was I didn't really know how to think yet and decided to explore other things.
2. Although I played Oregon Trail on a teletype and pong on a TV, I didn't even know what a computer was until I left the school of architecture in '81. I was searching for something and two friends were CS students and worked at this small company in a house near campus. They worked odd hours and the atmosphere was relaxed, so I thought something must be up.
3. I attended a very small high school in Ohio in the 1970's. This allowed me to get three varsity letters: football, track, and tennis. My best memory of that time though is writing a report on "The Arms of Krupp" about the international arms trade through the centuries. That kind of took my teachers by surprise.
4. I was a roadie for a band for a couple of years and ended up meeting and marrying one of the singers. I went on two east coast tours with them. The most interesting place we played was the mall in the Pentagon.
5. I lean towards "decentralized, worker-owned, market-socialism".

Please to be tagging Ian Cartwright, Mike Herrick, James Robertson, Mark Watson, and Steve Dekorte.

Accountant Wanted

From the San Jose Mercury News (via the Seattle Times)...

In an interview with Microsoft Chief Executive Steve Ballmer a few weeks ago, I asked if he had added up how much money it cost to develop Vista. He laughed, "I can't say I have. It would be impossible to count up. ... I'm sure it's a lot."

If we assume Microsoft's costs per employee are about $200,000 a year, the estimated payroll costs alone for Vista hover around $10 billion.

This is incomprehensible. A CEO has no idea how much his most significant product in six years cost to build.

Then the other incomprehensible "tidbit" is that it cost at least $10 billion USD. And they did not even get a new operating system out of it. The new product is really a face lift and some bug fixes on an aging infrastructure.

In light of this the stock price should be significantly lower. Software companies are difficult to invest in, and MSFT has to be one of the most difficult.

Sign of Success?

Headline: "Nintendo Recalls 3.2 Mil. Wii Wrist Straps"

Well, people are enthusiastic at the least! A sign of success? Mistakes were made, as it were.

We've had no trouble with either of our two controllers. But we will replace them with the stronger straps to be on the safe side.

My kids are going to be thrilled to find the wind storm last night resulted in no school today. Hey, kids: just watch out for those flying controllers on your day off!

Singly Cellular

Final Update:

This is my final update to this post. I will start a new one on some related topics. This update is just pointing out a new comment below from Brian Oliver of Tangosol.

The comment is fairly lengthy so I will not pull anything out here into a quote. I recommend reading it. There is good technical content I should put into another post.

The one thing I will say here is: my blog will not become a forum for vendors to pick on each other. It's not there yet, although it is walking the line. I simply will not approve your comments if I don't see them contributing to my technical interests.

This is my blog. I have spoken.

:-)

Reading Brian's comment one might get the impression any misunderstandings I have of Tangosol come from a competitor. That is not the case. I have met with Tangosol people in person. Any misunderstandings come from them.

:-)

Just *kidding*!!! Actually I have met with them, and they have a number of questions they're following up on. The misunderstandings are mine alone.

End Final Update

The notion that Jini/Javaspaces and Tangosol Coherence are direct competitors seems to come up fairly often. At least from the Tangosol folks. I think that's because Tangosol and Gigaspaces compete in the scalability market. Gigaspaces sells their non-standard features to the performance-challenged... update-in-place, etc.

But this seems to ignore the Jini part of Jini/Javaspaces as well as most of what a Javaspace would be used for. That gets short-shrift...

If the benefits of an organic model sound familiar, then you're probably already using the world's most innovative distributed system. If you're still struggling with traditional exception-based or recovery-based approaches to distributed systems (e.g. CORBA, JINI, RMI), then you have my deepest sympathy, but it's not too late to switch.

I will ignore the obvious red herrings in CORBA and RMI. But as for Jini...

I would really like to see how Tangosol Coherence lines up against all the things in Jini. Coherence is a distributed/shared data cache. One would have to establish all kinds of conventions to get the cache and its contents to do Jini-like things. Coherence is fairly proprietary as well, but ignore that for now.

Maybe the message is Jini-like things are not necessary. That seems to assume everything you need is in your cluster of Coherence-loaded JVMs. Coherence has some nice features, even for implementing Javaspaces and other standard capabilities above it. But that's not the claim being made over and again. The claim seems to be: you don't need Jini because our clustered cache is better.

Apples and oranges? I'm looking for better answers than that if someone can point me to an in-depth Jini/Javaspaces vs. Coherence comparison.

Update 1: btw there is nothing like getting up in the morning looking forward to working with the people you sit with, and then hearing later in the day how amazed the CIO and all kinds of people are with the team's results. We get to do good stuff that counts, no BS.

Update 2: Dan Creswell comments below, lending to my suspicions...

Right, so if you are under the impression that all you do with Jini/JS is build compute servers/farms, then you might assume this equivalence.

Update 3: Ian Cartwright comments below about conventional and unconventional uses of Jini/Javaspaces. He includes a link to an interesting combination of OSGi and Jini...

Newton makes use of OSGi for wiring up composites within a single JVM and Jini technology for tracking and wiring up dependencies between composites in different JVMs

OSGi is what Eclipse uses to wire independent objects into its JVM. Some folks on the team were looking at that for a related effort.

Update 4: Nati Shalom of Gigaspaces confirms the emerging consensus that Jini and caches complement each other, and a Javaspace can be used as a kind of cache, although for other uses as well. As Dan Creswell wrote somewhere, caches tend to have more reads than writes, while javaspaces (when used for coordination rather than as a cache) tend to have more takes and writes, fewer reads. A quote from Nati's comment...

If you’re building an SOA application, you'll need more then a cache. In fact, a cache gives you almost nothing on that regard. You will need a Service framework, which is what Jini provides. A service framework deals with how you discover, find services, invoke them, make them secure, manage their life cycle, etc.

Another part of his comment refers to the Rio extension to Jini/Javaspaces, an interesting service management framework. All open source under Apache as well. Some of those ESB folks should look at it.

XSD -- XML Schema Deterioration

Catching up: Ian Cartwright goes into some concrete examples about XSDs, why they are undesirable, and how to cope with them. He also addresses related serialization problems.

It hardly seems like a year ago, but it is close, when Ian was over here from the UK with Paul Hammant working with a group of us down in sunny California on fun stuff like this.

Fixed That One

Randall Scarberry displays the joys of shared memory concurrency in this article on Java...

At some point while reading this, you've probably wondered about what synchronization issues might be encountered in SMT adaptation. I encountered two with ConcurrentKMeans, both in the nested class ProtoCluster, which is a class K-means uses to track intermediate clustering results. It was clear to me that something was wrong, because ConcurrentKMeans gave results different from BasicKMeans even though it was using the same N, K, and random seed. I ran it several times, occasionally getting an ArrayIndexOutOfBoundsException originating from the ProtoCluster method add(int ndx). Then the obvious dawned on me: multiple threads were calling an unsynchronized method. (Doh!) The exception happened because one worker thread attempted to add a coordinate, while another thread was expanding the array holding the coordinate indices. Simply adding the synchronized modifier to the add(int ndx) method definition fixed the problem.

OK, fixed *that* one. Any confidence that was the last one?

Not that concurrency is easy, but almost all programming languages exacerbate this with extremely outdated memory and concurrency models.

Don't you just love exacerbation?

Eventually we'll all move to shared-nothing languages of one stripe or another to implement concurrency, Erlang being one. Along the way we'll move to better shared nothing mechanisms for our current languages rather than threads, monitors, and such, spaces being one.

Wow! I mean WOW!

An interview with Pete Lacey...

Wow! I mean, WOW!

As I see it the [WS-*] is so large and complex, and the participants so tightly coupled, that scaling to even enterprise levels is out of the question.... you will not be able to use this technology to build a fully distributed enterprise architecture.

I am shocked. I mean there is so much evidence to the contrary. Er, isn't there?

Prediction for 2007: the rush away from WS-* will look like the recent US election aftermath of Republicans running from Bush's Iraq War.

Good Luck Jon

Jon Udell decides to steer a big ship...

Bottom line: This isn't your father's -- or maybe your older brother's or sister's -- Microsoft.

Good luck Jon. Please don't join the list of the disappeared.

Where is Ozzie? Box? Cunningham was out of sight during his tenure.

How many good people does it take to create this new Microsoft? The world may never find out.

The Revolution *Wiill* Be Televised

(via Steve Dekorte)

People are starting to use the Wii's remote controller for Windows and MacOSX.

No Panic

Fuzzy isn't panic'd.

Hey Kids Rock On

James Robertson relays a presentation by Niall Ross...

The demo Niall is showing is pretty cool - using rewrite rules and a port of Store for Glorp to VW 3, he's replicating code from VW 3 into a Store repository, and then reconciling it in VW 7.x. Another cool thing - Niall and a few other people have extended the rewrite engine piece of the RB with menus, in order to make it easier to use.

Another reason why Smalltalk especially, and dynamic languages generally, win. Not likely in Java, eh? No wonder they want duck typing.

Not Necessarily The Good News

On the use of XSDs, Bob DuCharme writes...

If the bad news is that the majority of XML developers have picked an ugly, convoluted syntax that is difficult to maintain when they store metadata about their types, the good news is that at least they're storing metadata about their types in parsable XML.

That's not necessarily good news if the unwanted side effects of using XSDs gunk up your systems. The one cannot necessarily make up for the other. It is not just about "ugly syntax", nor is it even about ugly syntax at all.

The problems lie in the lack of expressiveness (semantics more than syntax) and the unnecessary dependencies XSDs can ripple through one's systems if one is not exceedingly careful. Such care is not often promoted by tools based on XSDs, yet in this realm people tend to rely on tools much more than wisdom.

Kill Java

Some people apparently want to kill Java. Hey, I am not entirely against that idea, but it should be deliberate.

In this case, some people want to continue adding to Java until it becomes nothing by trying to be everything. Java is essentially what it will be. Yeah, generics, closures, etc. are arguably helping or hurting depending on the situation... that's not what I am talking about. Read on from Paul Browne...

Now that you have Java in your open source toy bag, can I have Duck Typing please?

Yeah, right. Do you understand either Java or duck typing?

P.S. I still want to keep compile time type checking to make sure I don’t make any mistakes.

OK. Apparently not.

Here you go: if you want Java and duck typing, use Jython or JRuby or Rhino/Javascript or...

Do not add duck typing to Java. Ever. Period. End of sentence.

Today's Englebartian Shake Up

This proclamation from bit-tech.net...

DirectX 10 is probably the most important revolution in games development, at least since the introduction of the programmable shader in DirectX 8.0. Because of the way that Microsoft has designed the new driver model, DirectX 10 will only be available for Windows Vista users and there will not be a version released for Windows XP. Along with DirectX 10, Windows Vista will come with DirectX 9.0Ex – this is because pre-DirectX 10 hardware will not work under the new API due to the complete overhaul.

Of course Wii disagree. Everyone expects graphics to get better on all systems, this is not just a Vista thing.

The *true* Revolution is how the Wii's remote controller changes forever the human-machine experience at $250 USD complete. You may not like gaming, you may like Sony more than Nintendo. Nevertheless, Nintendo has taken human-machine interaction in general to an entirely new *practical* level for everyone.

This is an Englebartian shake-up.

Sorry. That's just the way it is. Period. End of sentence.

Nothing Is All Or Nothing

(via Stefan Tilkov)

A sorry commentary on the state of the software industry from Steve Jones...

SAP, Oracle, IBM and Microsoft... These are the companies who your CIO goes to visit and sits through dinners and presentations on their product strategy, and what they are pushing is WS-* in all its ugly glory. This means that in 3 years time you 100% will have WS-* in your company, in a company you work with, or in a company you want to work with.

Don't worry about WS-Dominance. It will never arrive. But beware of WS-Stupidity.

Having some large software vendor or partner inject SOAP into your data center is no reason to allow it to infect all of *your* work. Push WS-Complexity out to just those edges whose outside forces require it. Stop the enemy at the gates. Make the rest as simple as possible. Always assert your control over your own architecture or you will be a loser.

That's what we're doing anyway. We have a CIO that believes in smart people, incremental development, and lasting systems.

Yow. More Wii Fun

Maybe you're tired of my just blathering about the Wii. My son's been bogarting that Wii, but I reached another milestone with it last night. We played doubles in Wii sports. That another level of gaming fun that I don't believe can be matched with any other system.

Sorry Microsoft. Sorry Sony. The Nintendo Wii is the best thing in gaming in the last 20 years, and you have a ton of work to do to catch up.

Last night my son and I bowled, played tennis, golfed, etc. And not with some artificial hand held, buttony, doo-dah thing.

We were actually swinging rackets, clubs, putting spin on a bowling ball with our wrists, and playing *together*.

Yow. The experience playing with others is even so remarkably more amazing than playing solo.

Just In Time For Christmas

Everyone needs this combination under the tree... sexbuntu and christianbuntu!

If only Rev. Ted Haggard had known about these.

Design and Execution

I'd like to see Nintendo and Apple compare notes. Two brilliant design and execution companies that would appear to complement each other well.

Meanwhile the XBox 360 is ho-hum, Microsoft blows Vista, blows "Zune" (ugh - even the name), and blows yet again their understanding of open source. Ballmer, with little to do apparently in actually *leading* a company, can only resort to threatening Linux.

My prediction -- Novel is not the next SCO. *Microsoft* is the next SCO. Albeit with billions more in the bank -- they are a company desperate for what they've never been:

-- a design and execution company.

Wii in the House

The Wii is in the house. Game Crazy had a midnight event just for the people who pre-ordered. So we got there way early, played the demo Wii, and hung out with a small number of excited employees and customers.

We got the Wii, an extra wiimote controller, a classic controller, four additional games (plus the sports game that comes with the box), some online points for classic games, etc. for a good $50+ USD under the base price of the PS3.

And on top of that we have an amazing game playing experience. Using the wiimote controller is like no other human-machine interaction I've experienced. Feel the gentle "bump" as you traverse from option to option in a dialog, e.g. while building your online characters in the "Me Channel".

Something I learned now that I've played a good bit more since my first experience a few weeks ago: driving with the controller is something like the steering wheel, but the more I "drive" with it, the more I find myself balancing the controller in my hands and tilting the weight of it one way or another to keep the truck on course. This is not really a steering wheel, but close -- it is more of a natural analog for the truck's movement on the screen. More natural than a joy stick -- there is a "feel" for the movement, gently letting the fairly lightweight controller tilt around.

Easy. Smooth. Awe inspiring... you may be a fan of the multiple processors displaying all the PS3 graphics (although I have yet to hear of a purchaser who did not sell their purchase on ebay), but I have trouble imagining someone not coming away from a session with the Wii not thinking this is a big step toward a new style of machine interaction.

Nintendo knocked this one *way* out of the park. The feel is generations ahead of the 360 and I imagine the PS3. Whatever the Wii lacks in graphics processing will surely catch up over time with hardware and software improvements. At $250 per box, I can easily buy another box next Christmas with more graphics and still be on par with the initial cost of the competitors. Nintendo made the right investments.