Making it stick.
It's About Time
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?
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
Meta Stuff and WinFS
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.
When Everything is Persistent...
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.
Messages and its Gerund: Reliable Messaging on the Cheap
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.
java.util.concurrent
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.
Collections, messages, and blocks... and Databases
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.
On Messages and Files, and the Rest of the Future of Data
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.
