XML, the right format for object graph serialization

I was reading this blog entry, and my annoyance meter was piqued:

One of the advantages of having a canonical representation of an object tree, is that it serves as a great interchange enabler. That canonical representation doesn't need to be Xml, but it seems like a good choice.

Sigh. The assumption of an "object tree" - object graphs usually aren't trees, they typically have lots of cross-references. Objects in memory form edge-labeled graphs, while XML is a node-labeled tree. Converting objects to XML requires some naming scheme for those objects which have relationships more complex than parent-child.

If you design your objects along functional lines and make them immutable after the constructor has finished executing, this scheme can work, but I don't believe there are many useful structures with no cross-references whatsoever. It works best if you have a rooted namespace context like TComponent and its Owner, or something similar where objects can be identified by a URL - ideally one and only one URL.

I believe that in some decades from now, we'll look back at this objectification of the world, this current habit of seeing the power of objects in e.g. GUI libraries and then applying the same hammer to all manner of delicate problems, as one of the bigger mistakes in the history of programming. Basically, both hierarchical data (e.g. XML) and relational data (collections of fact tuples) are bad fits for object orientation, and in the code side of the house (as opposed to data) lightweight processes (think Erlang) haven't had their due. And popular programming languages are starved of higher-order abstraction facilities.

I wonder how this is going to change. C# is gaining its extensions (and cruft - having both lambdas and anonymous delegates in the language is a bit of an eyesore), but it's still pretty poor in many other ways. It's very deeply wedded to imperative, linear thinking, with very few transformations before execution. Static typing is fine, but metaprogramming and dynamic programming's rise show why it is also constraining. Statically typed languages that lack a higher order, a way of programming over the type domain as well as the value domain, end up falling back to reflection and other weakly typed loopholes to overcome traditional (C, Pascal, Java) static typing's inflexibility.

Silverlight and DLR announcements

The latest buzz in the dev community online is all about Silverlight. From my perspective, there are a number of things to tease apart:

• Silverlight as a Flash alternative
• Silverlight as a WPF-lite, with CLR
• Silverlight as a dynamic language runtime, and the DLR itself (standalone) - one can preview this framework in IronPython

Flash alternative

I know I'm not a typical web user, but my main experiences with Flash have been:

• Amazingly annoying advertisements

  This is the main reason I disable Flash by default, with FlashBlock in Firefox. If I wasn't able to use Flashblock, I would uninstall Flash instead - I'd rather lose video than suffer distraction.

• A video solution

  One of Flash's nice advantages is that it keeps the Linux folks onside, as even though it's not open-source, they can still consume.

• Extremely crummy rich applications

  I have never encountered a Flash application that (a) had good keyboard support and wasn't terminally mouse-dependent or (b) didn't prioritise flashy (ha!) animation over and above actually making use of the richer platform than poor/pure HTML or (c) whose rich vector animations didn't regularly peg a CPU at 100%.

So, hopefully folks will excuse me if I view Flash as effectively a video codec, and that MS will face a somewhat uphill battle trying to supplant it as a preferred codec.

WPF-lite with CLR

There's another thing I find striking about the Silverlight story: how similar it is to Java applets. Things that make Java applets suck are (a) the cold start cost (chuggalug of disk, bloat of memory) and (b) ugly Swing UI controls, and (c) the plain fact of JVM dependency.

Cold starts are always important, and I feel the CLR has a better handle on controlling those costs than most JVMs, and certainly expected browser memory usage is a lot higher these days, regularly climbing above 200MB on my machine for one.

It ought not to be hard for WPF to improve on Java's controls, and there are folks out there already looking to market for this platform.

The dependency is the most troubling issue. Flash has gotten to where it is chiefly (I believe) because of video; MS needs some similar mass-market hook to get adoption, and I'm not sure its video implementation is a differentiator, much less an advantage - mainly because I haven't seen it yet. But really: how much better could it be, that would make a difference?

DLR: Dynamic Language Runtime

As a language guy, this is the most interesting part of the whole enchilada. JavaScript/EcmaScript in the browser is slow, and needs techniques such as JIT compilation, dynamic call optimization based on caching, etc. that DLR makes available in order to be made faster.

The DLR is also an interesting platform play, creating an interoperability platform suited to dynamically typed languages with late-bound types, methods and fields. Most dynamic languages permit things like expando methods, jamming on fields and closures to existing objects and extending them, very rich reflection and metaprogramming, runtime 'eval' support, etc. - but all in quite similar ways. In some respects, DLR is a little like late-bound COM for the .NET generation.

It's interesting that the Java platform never developed this, even though it's the other main target for dynamic languages looking for performance improvements. The open-source movements for e.g. Jython, JRuby etc. never really get together and try to find the commonalities, and implement them in a shared library, and eliminate duplicated effort. It's one of the structural deficiencies of open source - once the code's been implemented in specific layer, it tends not to migrate to a lower layer. It's also an obvious move that it's taken someone like MS to make - I wonder if Sun regrets not doing something like this. Finally, it's notable that Java doesn't have anything like Reflection.Emit, one of the most interesting features of .NET for me ever since it came out, and one that DLR leverages heavily for its performance benefits. Java users have to work a lot harder to get the same effect, dynamically generating .class files.

Conclusion

I think there's a big need for a rethink of JavaScript in the browser, but I'm not sure that Silverlight is the solution. Part of me hopes that it is, but I'm afraid that when people wake up out of their daydreaming, and look at things in the cold light of the dawn, they'll see that Silverlight needs to do so much to prove itself as a simple video platform (or some other hook) and get adoption, over the next (say) 3 years, before it can hope to be considered an application development platform. Proving that it's not just Java Applets Mark II, or limp along as a second-rate competitor like QuickTime, is going to be tough.

On the other hand, the DLR, as a thing in itself, is great stuff. I can see opportunities to add DLR awareness to more traditional statically typed languages and get benefits from both worlds.