another weblog

This year I decided to attend my college’s homecoming because it was my class’ five-year reunion.

Homecoming was fine, and was pretty fun, because I got to see a bonfire started by a bomb (video soon), I got to catch up with professors and I also found out that, somehow, my school’s anime club is Still Alive.

However, the reunion was a mistake, and unless I actually go with people I know (which isn’t happening, because most of my best friends from college are either people who were not in my class year and/or thousands of miles frm Indiana) I’m not going again. Not only did I not know anybody there, but the reunion committee thought a small bar would make a suitable venue.

Yeah, that sounds like a great time. I was in and out of the bar in forty-five seconds.

I guess it would be okay if I were a thirty-two-year old salaryman with no heady goals to achieve, but, well, I’m not.

I’m watching Jensen Harris deliver a talk at Windows Build titled “Eight traits of great Metro style apps”:

http://channel9.msdn.com/Events/BUILD/BUILD2011/BPS-1004

(An MPEG-4 video file is available for people who don’t want to install Silverlight.)

Readers of this blog will know that I take Tufte’s data-ink ratio, no chartjunk, honesty of presentation etc concepts pretty seriously. (Except when it comes to my weblog, but that’s more of a case of me being too lazy to fix it.)

Metro style seems to embrace the exact same ideas. In that talk, you’ll hear Jensen Harris talk about “content before chrome”, “fading into the background”, “every pixel is information”…the sorts of things you’d read in a Tufte book or hear at a Tufte presentation.

The bits and pieces that I’ve heard of the WinRT API, which implements Metro, are also interesting. I haven’t seen any official MSDN documentation on WinRT (probably because it’s still in preview, which is annoying), but from what I hear the API embraces event-driven programming in a fundamental way by being mostly asynchronous and more declarative. Having not seen any WinRT APIs I can’t really say what that means, but here’s what I do know:

• OS X’s Core Animation framework handles animations declaratively and asynchronously: you declare layers and keyframes and kick off an animation job. The framework then animates elements for you.
• Adobe Flex’s animation elements are quite similar.
• Metro makes a big deal out of animation fluidity and user interface responsiveness. One easy way to kill UI responsiveness is to block the UI thread by waiting for I/O in the same thread. Forcing asynchrony goes a good way towards eliminating those blocks.
• One common knock against asynchronous programming is that most languages aren’t designed with asynchrony in mind. If you write var x = f() then it is (often) assumed that the computation f() will complete and then x will be bound to something. Asynchronous execution does not guarantee that; instead, they require programmers to reify the “and then do something with that information” bit. (For language nerds or Wikipedia addicts: Asynchronous programming requires programs to be written in something like continuation-passing style, and that, done wrong, ends up with lots of nested functions, which is a bear to maintain.) C# 5.0 introduces some new constructs (based on CPS transformations!) that make it possible to write code that looks like var x = f(); var y = g(x) where f() is an asynchronous computation, and g() may or may not be asynchronous.

This is the first time in a long while that I’ve been excited to play with a Microsoft technology. I suspect Miguel de Icaza and the Mono team will get this stuff into Mono pretty soon, so that I won’t have to use Windows to use it, and so that my applications won’t be shackled to Windows.

===

Also. When I was still using Google+ I wrote that I’d run a ten-foot wall at Grant Park before the end of the summer.

Took a bit longer than “end of the summer”, but I did it. Repeatedly.

Video soon.