Ho Hum? Think Again

Steve Dekorte draws the line...

If there were ever a question of which party is more evil (certainly a question on which reasonable people could, in the past, disagree), I think it's been put to rest today.

Our representatives swear an oath to protect and defend the constution, not to pass legislation to keep their party's president out of jail.

I'm An Isolationist - You Probably Are Too

I rec'd an email about my recent thing to do with the "shared nothing" vs. "shared memory" models, JRuby, et al. being crammed into the JVM, CLR, Parrot, and so on.

The point of the email is well taken. Essentially JRuby is a good thing because the JVM is widely adopted and accepted in enterprises. This is the vehicle that will allow JRuby to be widely adopted. I agree with that approach, and do think JRuby, Jython, IronPython, and related languages are all very good things to have.

I'd rather have a widely adopted shared-nothing environment. That is the model of the future. The shared-memory model *is* the current model but there is plenty of evidence we've been done with it for some time. Another five years or so will be necessary for this to really sink in.

But we have JRuby now. Yeah, I'll program in JRuby today. At the same time I will push for something better, and expect to get it about 2010 or so.

Let's be clear that the JVM has been lurching toward a shared-nothing model already for well over five years.

The servlet model, the EJB model, the Jini model... these are all in various ways attempting to provide semi-shared-nothing models so we can each contribute our own isolated parts to the whole. Unfortunately they're each anachronistic, one-off, partial solutions. JSR 121 is attempting to make this even more general for all kinds of pojo scenarios.

Given the isolation model that just comes for free with Erlang, the vast majority of the complexity and variation of these lurches toward isolation for Java would just go away. (Erlang itself has a *little* cruft but that's nitpicking.)

I've been through the garbage collection wars, the dynamic typing wars. I think we'll get better isolation more easily but so far it remains a subtle point in the community at large.

Iceman: "You like to work alone. I've heard that about you."

Update: A Fellow traveller writes...

Yes, you can layer a shared nothing architecture on top of a language that does not hand-hold you towards a shared nothing design, but the scope for error is huge. Remember the days of malloc anyone? Same idea.

I don't think it is quite that drastic. Yes, I lean toward semi-functional languages like Scheme and Erlang, mostly Scheme because you can more easily write all kinds of languages in Scheme. Gambit Scheme is a good candidate platform for building mult-language shared-nothing runtimes.

But even "heavily-imperative" languages like Smalltalk, Ruby, and Python can take much better advantage of a shared-nothing runtime model. These implementations just need to be able to run more than one environment within an OS process. Kind of like doing a "fork" that forks an isolated process within the current OS process. Now you have two or more Smalltalks, Rubies, Pythons, Javas, etc. running in that one OS process, isolated one from another.

When these are truly isolated and efficient then nothing should prevent an OS process from mixing these languages "sub-processes" within the same OS process. These are not new ideas, but have never really been fully explored. Most of the bits and pieces are in place. It's just around the corner.

The Wiki Way and Other Ways

OK -- two more things about work. First, this... the past is the future, and/or vice versa...

And the wiki... I have used several wikis in various settings in the past, but this team is using its wiki really well so far, with no sign of letting up.

We'll have to get Mr. Panic From Fuzzy to explain "Page Slap" sometime.

Less Bigness

Dan Cresswell wonders...

I just wonder if our systems would be less big and less complex if we admitted we don't understand all things and stopped making so many incorrect assumptions about how things should be done?

The New(?) Architecture of Redisplay

I came across recently an email message on Tweak (a GUI for Squeak Smalltalk) and display refreshes in the presence of asynchronous processes...

So why not use processes?! Looking back at some older conversation about using multiple processes it appears to me that we've been holding back on it because of synchronization issues. While this is certainly understandable (we all know how hard process synchronization can be) I think that we can solve this problem in a very simple way that gives us the best of all worlds.

Here it is:

The basic problem that we have when using multiple processes is that we can't always say for sure when they are run. Because of this, the system may activate some process while we're in the midst of redrawing the screen, handling events, executing some (interfering) other process etc.

Yes, to multiple processes.

I developed some CAD tools a couple different times way back when, that had to deal with distributed processes and asynchronous messages. More recently, but still seven years ago (dear lord, really!) I developed an example graphics editor in Erlang and Tk. Today I would approach an intraprocess design the same as the distributed. First and foremost -- get rid of shared memory and the synchronization issues go way down. Synchronization becomes a design tool rather than an accident waiting to be found, or a burden of self-over-protection.

Here's the real news... there is a *lot* to learn from understanding how Emacs works.

Emacs got the architecture of asynchronous redisplay right 25-30 years ago when it was dealing with the asynchronous nature of text redisplay in the presence of asynchronous keyboard interrupts. The "command pattern" and graphics, etc. are just elaborations on the theme.

Another thing Emacs got right is keyboard maps from keys to functions. A "mode" is a more or less different map from keys to functions. A "modal dialog" is just pushing a new mode map into the keyboard process for some period of time. Emacs embodies a pretty good "model-view-controller" separation.

Processes and display refresh -- expand the Emacs way into true multi-processing. One process owns a display device. Other processes, local or otherwise, may be able to send it display update events. Those messages may have priorities, or rather the display process may understand which collaborators have priorities.

The display process will always try to process the most important update message next. Display update may be postponed until some or all update messages have been processed. If there is a hope of getting through the message queue in time, then the display process will postpone a refresh until the queue is empty, otherwise some logic of when to stop postponing the refresh has to be coded.

Virtual Fun

I'm really enjoying my new job. The team is a lot more fun than those I've been part of over the last few years. Partly because those teams in the recent past have been almost 100% "virtual" i.e. distributed. No matter how much good work you can get done "virtually" it is difficult to maintain a healthy "virtual" sense of humor, you can't walk to the coffee shop, or talk in the hallway. Distributed bases can work, but each base has to have a small set of people who see each other at least several times a week. The people, the atmosphere, and the work all make a difference too.

My current team is co-located *and* they have a sense of humor (senses of humor?). And they are very smart, and stuff. And they've watched Team America: World Police several more times than I have. (Me: Once, but I laughed my ass off enough for three viewings. Although now I *have* to get the unrated DVD version.)

This week as my manager reports we found a kindred spirit visiting from several thousand miles away in Belfast, over beers. They've done good stuff with virtualization, open source, etc. So we're looking forward to this Portland base working with the Belfast base on some common interests.

And I am looking forward to having a lot more fun, and working on interesting things with smart people. What a difference a few weeks make.

The Middle of the Road

Oh dear. Can we not leave well enough alone?

Getting It Through Not Understanding

Tim Bray on Ruby...

I’m already using method_missing, any language that doesn’t have that just seems crippled.

Welcome. We've been waiting for you. A helluva long time.