size matters

Fellow IBMer Bob Blainey recently posted a blog entry "Are you a Pakled?" which touched on software bloat. This is a subject near and dear to my heart, burned into me after spending a good five years or so in the embedded software space.

At the time, the devices that we were targeting would typically have something like 2MB ROM and 2MB RAM available. Think of the ROM like hard drive space, and the RAM is the memory in a computer today. We worked with devices that had less memory, sometimes, and near the end of my run, worked with devices that had much more memory available. But the 2/2 story was sort of the rule of thumb.

That's not a lot of space, so you worry about every byte. You worry about every new library that you need to add to your runtime. Not just in terms of it's disk footprint, which ate ROM, but the runtime footprint, which ate RAM. There were always hilarious situations where we'd be talking to product groups with no embedded experience, where they'd die laughing when we told them their library had to fit in 10K bytes; or it would be us laughing when they told us their runtime only required 1MB of RAM.

If you enjoy the "solving puzzles" aspect of software development, this is just an additional challenge on top of all the other challenges, which made it, for me, a terribly fun working experience.

You can imagine the "sticker shock" that hit me, when my first position after leaving the embedded world, involved J2EE. Whoa. And the sticker shock continues to this day, in every new piece of work I'm involved in. But it's not just me; most of my colleagues back in the embedded days seem to experience this sticker shock in their day-to-day jobs, which is something that I think most developers just don't think very much about. Like the kid in "The Sixth Sense", we see bloat - everywhere.

It's heartening to see the resurgence in interest in embedded development, in places like the iPhone and Android, since I hope this means we'll be seeing a lot more folks taking an interest in software bloat.

Aside: the Pakleds, referenced in Bob's post, were one of the most memorable races for me in the Star Trek series, but I wasn't able to find any video clips from the show. I did find a little audio clip though; this is Riker asking a Pakled what they need.

web ui progress

The hotness of the day (well, yesterday) appears to be video at 280atlas.com (permalink at Viddler here). It's technically very impressive. But I'm also a bit saddened. I worked on similar technology 15 years ago, for desktop applications. You know what I'm talkin' 'bout. I won't say the word.

Sad because, even 15 years ago, web browsers were around, in some state. Why has it taken this long for things to progress this far? It's nuts. Seems like a lost decade, to me. Of course, it's not like we were even really innovating in this space, back then, either. Interface Builder goes back even further.

Feh, always with the rock throwing. So let me shine a little brightness, as well.

First and foremost, hats off to the folks at 280north.com. Getting all this to work on the clumsy web browsers we use today is surely no small feat. It looks gorgeous. The layering is interesting, built on Cappuccino and Objective-J. Stuff to look into.

Two things I saw in the demo that I liked, in terms of UI constructs: "Layout Support" and "Split Views".

The "Layout Support" appears to be similar to what we used to call "Form attachments", back in the day, that allowed you to specify how widgets were attached to things - other widgets, parents, etc - and how they would resize. Ours were based on Motif's XmForm constraint resources. (Aside: isn't it hilarious that the first reference I found to XmForm was in the lesstif online doc?) Although kind of crazy complicated, and really easy to screw up when you were coding by hand, and requiring you implement a constraint solver IIRC, you could do some incredible stuff in terms of making windows full of widgets which responded in a nice way to resize requests. And even just doing (non-absolute) layout by specifying which things were next to other things, and letting the system figure everything out based on default sizes.

"Split Views" are similar to what we called "Split Panes" (think that's what we called them), that were a late edition to our product, but to me added the last little bit of UI goodness for users. Instead of providing either fixed width, or perhaps proportional width child windows inside a parent, Split Panes gave users the ability to resize those child windows as they saw fit. After they got added to the product, there was really not much else that I found I needed, to be able to whip up a nice little UI with intelligently resizable innards. Separate the top level bits of a window into Split Panes, and then layout those children using Form attachments, or perhaps recurse with another Split Pane.

Sure would be nice if these were native capabilities provided by our browsers. CSS (and Tables!!) and Framesets just don't cut the mustard. Ah, not to worry, we'll have a <video> element we can use in our applications soon, and that will more than make up for the lack of these other, much less interesting capabilities.