Making it stick.

I've read some criticism of Victoria Livschitz's interview mostly correcting the usual misunderstandings of the average software developer or manager. But consider this...

Consider a few common concepts that people universally use to understand and describe all systems -- concepts that do not fit the object mold. The "before/after" paradigm, as well that of "cause/effect," and the notion of the "state of the system" are amongst the most vivid examples... The sequence of the routine itself -- what comes before what under what conditions based on what causality -- simply has no meaningful representation in OO, because OO has no concept of sequencing, or state, or cause.

She makes a good point here, and this applies not just to OOP. We build the concepts of time, sequence, and causation into applications from scratch when they are required by the customer. We have essentially no support for these at the language level.

How does a developer typically denote that some event has occurred? Like this...
has_occurred = True

How does a developer typically recall that some event has occurred? Of course sprinkly these liberally...
if has_occurred: ...

We have the State pattern to manage behavioral differences based on the current state, but we have almost no common patterns for behavioral differences based on the history of state.

How much runtime should a runtime need? The OS and frameworks developers have to work with today are so much bigger than they need to be. Let's remind ourselves of what it takes to port an OS that has a vector graphics GUI, an OO file system, garbage collection, etc. to bare metal...

The background is the Mitsubishi has a nifty single-chip RISC computer that integrates RAM on the same chip as the CPU. But they didn't have any software for it. So they got a bright summer intern named Curtis Wickman to port Squeak to it.

Curtis had to write all the device drivers from scratch, including a display driver, the mouse and keyboard handlers, a Flash RAM file system, a loader, and sound output.

This took four to six weeks, I think. However, we were then able to put a generic Squeak image onto it and it looked and behaved exactly as it does on a PC or Macintosh. Even though we knew intellectually that this would be the case, it was somewhat mind-bending when Alan grabbed the mouse during our demo began doing an unrehearsed demo and everything worked perfectly!

The amount of code required for this "bare machine" implementation is quite modest; 2000 lines of C and a hundred or so of assembly code, as I recall. -- John Maloney

I think automated meta stuff is the least of issues to be concerned about with WinFS.

I've been watching the PDC video presentations on WinFS. Having worked in the distributed object oriented database industry for a number of years, I can foresee potential nightmares that are being portrayed as dreams in these videos.

Why not make a real database more manageable for applications and end users? As it stands WinFS seems about half baked and certainly schizophrenic.

Conceptually WinFS is near the top of appealing Longhorn concepts. Practically, WinFS comes across as a needing a good bit more reality infused to get into production.

Another recurring thought on databases as a coordination mechanism...

On messages, files, and persistence: when everything in your runtime is transparently persistent, and you've stripped away all the mechanisms that have only to do with making a transaction ACID, what you are left with is merely a coordination mechanism.

In this future there will still be a use for a tuple space, a versioned document tree, and a dimensional model.

Mark continues on messages and files with a crucial observation...

Filesystems, after all, are one of the few things that define and hold together operating systems; they allow for unintended uses of data. If you expose everything through a specialized API, everyone who comes into contact with the system ? developers, administrators, and users ? has to learn a new means of accessing it.

True, but I would generalize this to any kind of database. A filesystem is simply one kind of database. In its typical form, it is outmoded. But Mark continues...

Put another way, I can’t think of any good reason why you wouldn’t want to expose persistent state as a file. that doesn’t mean that there can’t be other interfaces, but why lock it up in them?

P.S. Sean, I’m not sure specialised RPOST/RPUT methods are necessary; I think it can be done with a pattern, or maybe a few extra headers.

Mark's click-submit-only-once pattern is thought provoking.

The java.util.concurrent package is a great asset for Java. (JSR 166). The package has been around for a long time from Doug Lea. Hopefully most developers are using it already.

This package is far more valuable than any new syntax that could be added to the language.

Blaine Buxton rightly wants to delay his collection calculations, i.e. use objects as a means for lazy evaluation. This is something they're good for, but doesn't get much attention.

In fact this is just what Avi Bryant does in ROE (Relational Object Expressions). Consider that a relational database is essentially a collection, and often a large one, that you would like to operate on efficiently. And so his collection messages are simply delayed as long as needed.

I would expect some of the implementation ideas behind ROE would be applicable to Blaine's intention.

Mark Nottingham's questions on messages and files...

Why do messages — which in developers’ minds, inevitably means “short-lived” — have an advantage over files? Making your OS message-based seems to just add complexity, not make data more portable and ubiquitous.

...have me thinking about many things which I will boil down to a small hypothesis.

When we think of messages, we should say "messages are documents, typically shorter in length and shorter in duration". Then "message passing" is like "document passing". When we think of longer lived documents and messages, we should think merely of "passing" them to a service that has the responsibilty for the life of that document. Of course this should be independent of OS or file system. (Those are implementation details only. Our applications should rise above them.)

From working on systems in a half dozen domains I have come to the conclusion there are three simple patterns we should lean on for making documents and messages persistent.

• Tuples Spaces (think Ruple Forums) for in-progress, state machine-like transactions and collaboration.
• Versioned document trees (think Subversion's file system) for long-lived, shared, document editing.
• Star Schema-based storage (think Sybase IQ, a simple, low-maintenance, scalable database technology) for read-only transaction history and analysis.

I deeply believe (it is my hypothesis) that these are the only patterns you need, and the implementations going forward can become far simpler and adaptable than all of today's cruft. As for "messaging" (the gerund, i.e. SOAP and its ilk), WS-xxx is a band wagon approach toward more complexity. Messaging protocols are a means to an end (i.e. getting a message into one of these persistent "end point like" locations). All collaboration can take place via these "persistence" mechanisms. They are actually coordination mechanisms, and persistence is a by-product since collaboration is frequently different-time and/or different-place, and even when computing is solo or collaboration is same-time and same-place, you often would like a history.

This is the rest of the future, so to speak. The present vision of rest is blinded by HTTP. Although HTTP is an application layer mechanism, it does not address application semantics in a deeply meaningful way. Consider that any of the above persistence mechanisms, and many others, can be defined with or without HTTP. Saying HTTP is sufficient is like saying the verbs "go", "stop", "turn left", and "turn right" are sufficient for defining any children's playground activity. The real meaning is in the decisions of when to take these actions and how to interpret the response of the collaborators in the activity.

These three persistence mechanisms match the needs of the kinds of decisions our systems make for us, and the kinds of decisions we wish to make with them. You can tell me how crazy I am on this wiki page.

Anders Hejlsberg: There is clearly a performance aspect to it. One possible solution would be to say, "There are no value types. All types are heap allocated. Now we have representational identity, and so we're done, right?" Except it performs like crap. We know that from Smalltalk systems that did it that way, so something better is needed.

This is really one more thing generally not worth worrying about. *This* is the real lesson of Smalltalk in the real world. I have seen precious few Smalltalk (or Lisp, or ...) applications that required this kind of minutiae. Large matrices of doubles in these cases, usually, are the culprit. In these cases the work arounds are not enough to justify complicating the language for everyone.

A good 64-bit data representation will make this point moot in just that many more scenarios. But when Smalltalk and other simple dynamic languages are cruising with 64-bits, the complicated languages like C# will *still* be burdened with all their interfering mechanisms.

When a language is formed by piling feature on top of feature, you run out of gas sooner rather than later. Such is the case with "partial classes". Could one have foreseen the desire for "partial methods"?

What do you do when your language is not dynamic enough, but the next feature may be the straw that breaks the camel's back? You resort to code generators.

dotnet *demands* a good dynamic language ASAP.

If you enjoyed Jared Diamond's Pulitzer Prize-winning Guns, Germs, and Steel, you might be interested in reading this transcript of his talk on the collapse of past societies.

If Montana were an isolated country, Montana would be in a state of collapse. Montana is not going to collapse, because it’s supported by the rest of the United States, and yet other societies have collapsed in the past, and are collapsing now or will collapse in the future, from problems similar to those facing Montana. The same problems that we’ve seen throughout human history, problems of water, forests, topsoil, irrigation, salinisation, climate change, erosion, introduced pests and disease and population; problems similar to those faced by Montanans today are the ones posing problems in Afghanistan, Pakistan, China, Australia, Nepal, Ethiopia and so on.

Answering a question on whether technology is the answer to envionmental collapses of the future...

The second thing is that the lesson we’ve learned again and again in the environmental area is it’s cheaper, much cheaper and more efficacious to prevent a problem at the beginning than to solve it by high technology later on. So it’s costing billions of dollars to clean up the Hudson River, and it costs billions of dollars to clean up Montana, it would cost a trivial amount to do it right in the beginning. Therefore, I do not look to technology as our saviour.

The industry needs encouragement to make modest, but significant, advances, like the kind advocated for by Jon Udell.

Bravo. And encore.

Bush is speaking now in a clip on CNN. He is using phrases like, "America did the right thing."

Why defend yourself and your administration when you can defend America?

Next phrase: "I could take the word of a madman or I could protect Americans."

Is this implying George Tenant, Dir. CIA, is a madman? 8^)

Has rhetoric ever been as blunt in an administration?

My take on Model Driven Architecture as it is currently being defined is this:

The current definition, whether it is Microsoft's or the OMG's (PDF), is that the approach assumes no improvements on the underlying technologies. In particular, MDA assumes no *simplifications* on the underlying technologies. Rather in these approaches, MDA *is* the simplification.

The problem then is that an MDA is like a compiler in the way compilers were typically described in classrooms about 25 years ago:

1. The compiler generates assembly code.
2. The assembler generates binary code.
3. The linker generates an executable.
4. The loader loads it and initializes the PC (program counter).

The Microsoft approach professes to be more "agile" (love that word) than the OMG approach. Still it does not seem to be an attempt to improve our tools so much as contain them and force them to submit themselves to the MDA interface.

Phil Windley interprets Jim Flowers to be saying that...

Jim's fundamental point, I think, is that getting real people with real problems (i.e. elections office staff) in the debate will add significantly to level of discussion and move us closer to real solutions.

But this seems to ignore that so called real people with real problems *already* purchased and implemented unbelievably corruptable electronic voting solutions in order to replace the existing corrupted mechanical voting solutions.

Jim's position also seems to ignore that at least in some cases (e.g. in California) the use of such systems is not only deplorable, but it is explicitly *illegal*.

Yet more evidence that computer programmers are effectively writing the laws in many cases through the implementation of systems that fail to obey the law. At least in California the situation appears to be improving. Whether machines will be corrected before they're used again, and what retributions that would entail, is yet to be determined.

The state's school superintendent has proposed striking the word evolution from Georgia's science curriculum and replacing it with the phrase "biological changes over time."

Cox repeatedly referred to evolution as a "buzzword" Thursday and said the ban was proposed, in part, to alleviate pressure on teachers in socially conservative areas where parents object to its teaching.

I say why bother. Let evolution take its course.

Ted Neward attended a talk on risk analysis and decision making. This is the gem for technology facing (and technology fascinated) developers. Heed...

Cost-benefit analysis is a skill, not an arcane art, and more technical leads and architects need to spend more time working on it. But we don't, because it's not NEARLY as cool as working with the latest O/R mapping layer or tool, despite the fact that using the latest O/R mapping layer or tool in of itself represents a risk that should be carefully examined using a cost/benefit analysis.

If only we got as excited about adding 25 points of business value to a system.

The intent is there, the accomplishment is there. The only bummer is the notation of the query language itself. Who wants to write code like that?

Whatever your political stripes, if you are an American who believes the airwaves are still a public resource, do all of us a favor and participate in this brief boycott of CBS.

Remember, the airwaves are licensed and renewed by the public to CBS. They are not privately owned.

Michael is examining some code in Smalltalk and C. Here it is...

" The original Smalltalk example. "
canvas displayLineFrom: (topPoint x - gibDistance @ topPoint y) to: (topPoint + 1).
/* The original C example. */
canvas.displayLineFrom_to( Point.asPoint(topPoint.x() - gibDistance, topPoint.y()), topPoint.MoveBy(1,1));

I would not hesitate to use the "Descriptive Temporary" pattern. (Is there one? Maybe there should be.) Taking this to the extreme, I might end up with something like the following in Smalltalk and C, respectively. Keeping to short methods, I would not have much more code than this in a single method or function. I think this style, while longer, is easier on my brain...

" The Smalltalk example with descriptive temporaries. "
x := topPoint x - gibDistance
y := topPoint y
lineBegin := x @ y
lineEnd := topPoint + 1
canvas displayLineFrom: lineBegin to: lineEnd.
/* The C example with descriptive temporaries. */
int x = topPoint.x() - gibDistance;
int y = topPoint.y();
Point lineBegin = new Point(x, y);
Point lineEnd = topPoint.MoveBy(1, 1);
canvas.displayLineFrom_to(lineBegin, lineEnd);

Now, this also has the effect of making Smalltalk more readable than C since there is less line noise. But I learned Smalltalk before I learned C.