Mark Roseman's Blog

Quite a week.

With the ProjectForum 6.0 release going out this past Monday (and released to our hosting customers a bit before), this has been quite a busy week.

Major releases are always a source of worry, particularly these days when betas don't generate the sort of interest they did in the "good old days". With an entirely new, fairly browser-specific Javascript wiki/html editor (using tinyMCE), this one had the potential for more than a few problems.

While there's been a good number of glitches (some just stupid things on our part, some little things, and a lot of just weird things that are difficult to explain), overall we're getting a good response. That doesn't mean there won't be a patch release coming out in the next few days (there will), or that we've got everything sorted out (ha!), but given the magnitude of change and potential for trouble, I'm actually pleased how things have gone.

Automation Junkie.

Every once in a while I'm reminded just how time-saving it is to have an easily scriptable toolset around. Today it's doing the screenshots for TkDocs (see e.g. the widgets page in the tutorial).

Each of those little user interfaces is described by a short little Tcl/Tk script (ok, big shock). Those are combined with subversion, scp, a bunch of command-line screenshot tools (one for each platform), a big chunk of ImageMagick, and a bit of script code to tie the whole process together.

That way, any change or addition to any of the little UI scripts, and I can generate a complete new set of multi-platform screenshots in about a minute. Cool.

MacBook Air.

Needless to say, very cool looking, and very technically impressive in terms of how they were able to make it so small.

For me personally, I wish they'd have introduced a subnotebook instead though. To be honest, the Apple notebooks are reasonably thin already. But I'd rather have something with a smaller width and depth, and technologically, doing that doesn't require the huge capability sacrifice that ultra-ultra-thin does. The form factor of my 12" PowerBook still is a better fit for my needs, so I was hoping they'd do something along those lines or a bit smaller. Maybe in a couple years time...

Occupational hazards.

One thing about computing, the level of occupational hazards are pretty low. Biggest might be getting hit in the head by a frustrated colleague throwing a monitor across the room; not as bad now with the LCD monitors replacing CRT's (though they have longer range), and completely avoidable for those of us working out of home offices.

The only real worry for most people is RSI of one form or another. I'd decided to try the thin but otherwise conventional keyboard that came with my iMac for a while, but with increasingly common wrist pain, it was time to swap that for wrist braces and another new ergonomic keyboard (and a new mouse, and another new hard drive to use for Time Machine... well, if you're already ordering one thing...). Been a few days (and some heavy writing days) and noticing an improvement already, thankfully.

New Tk Website.

Over the Christmas holidays I started working on a new website resource for Tk developers. The idea is to provide a language-neutral, up-to-date (8.5+) best practices tutorial and associated documentation. Because a lot of the Tk documentation out there is pretty out of date or very thin, especially for non-Tcl developers, I hope this can become something useful.

It's still very much in progress, but you can see what's there so far at www.tkdocs.com.

We'd hopped out to Edmonton this past weekend to visit family, so got a good chunk more written on the plane. With any luck, I should continue to have some reasonable amount of time to keep working on it over the next week or two.

Communities and Priorities.

In many ways, the communities that surround programming languages are as interesting as many of the languages themselves (no, I'm not being sarcastic, programming languages can be interesting!). See the current over-the-top Rails Rant for an entertaining yet somewhat insightful take.

I've started working on something (will share soon) that involves some cross-language stuff, including digging into some internals. Ruby and Tcl are an interesting contrast, and it comes down to priorities of the core language people in each group.

Matz's philosophy on Ruby is very much that it is a language that programmers should enjoy, and that it should bring delight. That is, reading and writing code should be fun. In Ruby, it is. The syntax is beautiful and elegant, concise and just seems to have that perfect way of expressing almost any problem you throw at it; you may not know what that is at first, but when you stumble on it, it will put a smile on your face. I'm sure Ruby's deep cultural roots in Japan and its appreciation of artistic simplicity and elegance is a huge factor.

Tcl's design aesthetic (yes it has one) is more spare, far less about emotion and more about rigid adherence to rules: Everything Is (appears to be) A String, everything is a command, and the 11/12 syntax/parsing rules. Some (ok, many) might question whether the paradigm these rules set out is fun to program in, or elegant, but the logical consistency is appealing to many, and it's clear that some people are able to leverage that to do great things.

Tcl's reverence of rules springs naturally from the engineering/comp sci culture where it was born. This is even more evident when you look at its implementation. All the rigor that still goes into Tcl's internals — the bytecode interpreter, performance, full Unicode, threading, deployment, cross-platform and all this not only correct, but cleanly coded and well documented. Not surprising given Ousterhout's operating system roots, but it also served to attract people with the same perspective and priorities, and those are the types of people working on it today.

Implementation-wise, Tcl (which is also older of course) is worlds apart from Ruby. Ruby's performance is poor, I18N not there, threading questionable, deployment immature, code documentation of varying quality, and about 25% the amount of test code. It's why, among the dynamic languages, you often see Tcl used successfully in the more "extreme" situations, where correctness and performance and reliability are crucial. The expert Tcl programmer can take things further than the expert Ruby programmer in that regard.

Of course, extreme situations don't affect most development situations, though it's not unusual to get to the point where the pain starts getting very noticeable. But again, priorities. The Tcl guys can't understand why people aren't quite as obsessed with performance and corner cases, and don't understand why people make such a big deal about the syntax... it's just a bunch of rules after all; learn them and all is good.

The Ruby guys... well, it's not that performance etc aren't important, but there's just not as high on the priority list, and success is more "good enough" than "perfect". Which makes perfect sense for a less hardcore engineering culture that also values aesthetic and other concerns. Besides, you spend most of your time reading and writing code (90%?) and not in the really tough parts when the implementation can help you or bite you in the ass (another 10%-90%, depending on the project). Aren't both parts important?

What I want of course is a language with as good an implementation as Tcl has, so I have a development tool that is incredibly robust and scales to different sized problems better, but at the same time is as enjoyable and productive to read and write programs in as Ruby.

Tcl as a language won't significantly change. Ruby's implementation could and is, and its got an eager crowd of followers. The question is whether or not they've attracted the type of people and priorities that will deliver as good an implementation as it needs, and soon enough. I hope so, but I'm not holding my breath.