March 26, 2004

Hypercard, RIP

Due Diligence: A Eulogy for Hypercard:

To the surprise of few, Apple's Hypercard passed away quietly this week, after life support was finally withdrawn by the company. It had a run of over 16 years - though the last were in circumstances of at best benign neglect. Not a bad duration for a software product, but it still hurts to see it go, since I had some part in its gestation.
From a software architecture point of view, HyperCard had a number of interesting ideas which might bear reexamination. At a time when persistent object stores were still novel, HyperCard was built around one. It's not going too far to say that its user interface was simply a reification of the object database. HyperCard's programming model was object-like, but didn't fall neatly into either the class/instance or delegation styles. Individual visible cards in a stack were created as instances of prototypic backgrounds and could be pre-populated with text fields and action buttons. Default message passing was an odd hybrid of visual containment and fixed object hierarchy. These features, plus a very texty scripting language, seem to have made for a very approachable tool for the nonprofessional coder or database creator.
I never spent a huge amount of time with Hypercard (not owning a Mac). I did spend a while on MOO, which has some of the same attributes (transparent persistence, prototype inheritance, naked objects) in a network environment; and Notes, which at one point I thought would deliver HyperCard-like capabilities on a distributed data model. And it nearly did.

Now Groove, which has the most awesome distributed object store I've seen (it's XML, too). The programming model, like a lot of things in Groove, is inside-out compared with many previous approaches. Notes began with list-oriented @functions, and grew to include Lotuscript, then Java (and JavaScript). Groove began with C++, then script, now .NET and web services... and, some day (soon?) it'll become as accessible as HyperCard ever was. Roll on.

C# attributes

One of the powerful thing about .NET languages is the ability to define custom attributes on sourcecode (methods, classes, and so on), and so have very a very concise meta-programming syntax. Two great examples today:

Forms development in InfoPath SP1 (preview download) can now include .NET languages (your previous choices being JScript or VBScript). There's a little Visual Studio addin which hooks these together using custom attributes. An example via Aaron Skonnard:
[InfoPathEventHandler(MatchPath="Button1", EventType=InfoPathEventType.OnClick)]
public void Button1_OnClick(DocActionEvent e)
// Write your code here

And a wildly general use of attribute extensions: XC# "can influence the way the compiler works by adding or removing statements, renaming classes and members or canceling custom attribute generation... comes with compilation attributes for obfuscation, declarative assertions, code coverage, design rules, code verification, spell checking and more..."

Robin Good on Groove V3

Did I mention restraint? Robin Good is excited: in a hands-on review, some great praise and some very good suggestions for improvement. Just read it.

March 24, 2004

Groove Reloaded

Version 3 of Groove is almost ready - it's in beta test. The development organization here has been firing on all cylinders for a long while, and finally the marketing guys started talking about the upcoming version. I'll restrain myself to the occasional comment, because most recently I've been focused on applications for the 2.5 servers more than on the V3 code (although that'll doubtless change).

Even if you don't follow all the weblogs, here's one must-read article today. Steve Gillmor at eWeek has taken a look at V3, and thinks GFS is the killer app:

Performance has been improved by a factor of 2, 4 or in some cases 10. But a new feature, GFS (Groove File Sharing), is perhaps the tail that will wag the dog.
...Now, with the ability to synchronize files directly from the Windows file system across Groove's secure XML network, users can share documents in the context they're already comfortable working in: Windows Explorer.

March 23, 2004

Self - The Movie

Maybe software should work like this.

March 22, 2004

.NET rocks (at last)

Finally, I wrote some proper C# code. Some random observations.

Let's get JScript.NET out of the way first. As I may have mentioned before, I think JavaScript is a great language: it's maybe not quite bendy enough (lacking lisp- or CodeDOM-style macros and the ability to define real first-class syntax elements), but incredibly flexible, elegant, concise. Objects are hashtables, functions are closures, classes are instances, datatypes aren't strict. With lint, who needs a compiler?
JScript.NET is JavaScript minus the good bits. I can think of no reason to use it. If you want a .NET language, use C# or managed C++ instead.

C#, now, is a nice enough language. But more importantly, the framework is great.

  • The framework includes the compilers. ("csc.exe", the command-line C# compiler; and the others).
  • ASP.NET compiles and installs code on the fly. You can write an ASP.NET page in NotePad, with server-side C# code, and the just-in-time compilation will build and deploy the appropriate DLLs whenever it needs to.
  • Writing a web service (.asmx) is even easier than writing a Web page. Again, you can just write your class as half-dozen lines of code in NotePad and put it onto your web server; the framework will automatically compile the code, deploy it to the GAC, build WSDL on the fly, and implement HTTP GET/POST and SOAP interfaces.
  • Reflection is quite nice. Custom attributes are really really awesome. It's cool that typeof returns a Type, too.
Anyhow: I'm hooked.

March 20, 2004


My quota was exceeded. Attempting to save a weblog entry caused four of the underlying BerkeleyDB files to be corrupted. After fixing them with db_dump and db_load, MovableType was still completely hosed. Now back, on MySQL. Archive links may have broken (hopefully not).

Just when there's so much to write about, too.

March 09, 2004


Continuing my occasional reviews of books everyone read last year: "Linked", by Albert-László Barabási. Summary: just read it, right now. If your interests in any way include software, science, marketing, economics or social dynamics, the book has plenty of important and challenging ideas presented in an easily-read progression. I'm specifically recommending it to Dylan and Mike.

Almost anything you care to measure about weblogs -- number of inbound links, number of outbound links, posts per day, number of readers, number of writers -- follows the power law distribution. Millions of weblogs have only a few inbound links; and vice versa. Plot log(rank order) against log(your measure), you'll see a straight line.

Unlike, say, a plot of population height (something like a bell curve, with a clear mean value), these are scale-free networks. There's no typical number. In some ways they are self-similar at wildly different scales.

The same is true of webpages in general, as Barabási's research team discovered several years ago. It's also true of the physical infrastructure of the Net: bandwidth per link, or links per router. And our social connections (number of acquaintances, number of co-workers, number of sexual partners, etc) and of many other systems. It seems that scale-free topologies are an inherent result of the way some networks grow: incrementally adding links, with "preferential attachment" meaning that links in the network are created not simply at random, or only bounded by distance, but that big often begets bigger.

In Linked, Barabási takes a journey through the very recent discovery of these scale-free systems, and unfolds the story of the models to explain their existence, their formation, and their dynamics. It's developed at a gentle enough pace that Dylan's always half a step ahead ("Dad - this can't be right!" - "Yes, I know, you have to read the next chapter to find out why!"), but narrated with nicely diverse examples of why this stuff matters.

At the end of the book, after some discussion how how networks fail (and how they can be made to fail), it's clear that the dynamics of network growth are still largely unexplored. This isn't Crossing the Chasm or The Tipping Point yet, but it's just as important if you're exploring how {markets, groups, organizations} work.