Messaging the Way God Intended

I like this characterization from James Robertson. It really does go back to before Alan Kay conceived of Smalltalk, Kay observed several distinct things behaving similarly, like the Burroughs B5000 and biological cells. And now HTTP is just like that. HTTP is a basic message passing mechanism that can be used in all kinds of situations. It's not ideal but then what is? HTTP is wide spread and we're seeing it spread even further than current conceptions. Languages are becoming more dynamic, and so is messaging on all kinds of networks. Spinning up a new process for passing messages via HTTP and XMPP has to become easier still.

Smalltalk arrived on the message passing frontier a long, long time ago. In a lot of ways, HTTP messaging resembles what happens in Smalltalk - you send the server a message, and if it doesn't understand, it sends you back an appropriate HTTP error message (kind of like a DNU in Smalltalk). The server doesn't crash, it doesn't throw up its hands and stop; rather, it awaits the next message.

This kind of architecture has to be flexible, and growable at runtime. Smalltalk has been that way since the beginning, and HTTP servers operate in much the same way - you can add messages that they'll understand in well understood, dynamic ways. It's kind of nice to see people understanding this strength :)

APEX?

APEX == A Programming language EXclusively for who?

I must be missing something. Why on earth would anyone invest their information systems in a proprietary hosted language?

Please clue me in. And why is this guy doing the seig heil? 8^)

From zdnet...

Mark Gorenberg... hailed Apex as the most significant announcement since Sybase announced stored procedures.

Really. I am flabbergasted.

(Harumph)

Blaine Buxton bellows...

I feel like we get lumped in with the grumpy Lispers.

(Harumph)

All My Languages Use an Image File

Blaine points out a fantastic feature Smalltalk has had (yes, since the 1970s), that more language systems should emulate.

My favorite part of the night though was the reaction I got when I shut down the image, restarted it, and was at the exact point that I left it instantly. The power of image-based development compels thee!

But the thing is *all* my languages are now image based. Ever since I started using VMWare, my entire machine's state is saved and restored, rolled forward with snapshots, linked and branched, etc.

It's not all the way there as with Smalltalk, e.g. no browsing and selecting from "change sets", etc. But it is pretty useful.

I bet other people using virtual machines like VMWare had no idea their languages were "image based"! What a weird thing. Who'd want that? 8^)

Building Any System

From Curtis Poe, "Building Large Systems"...

Here’s a little secret that many “test-infected” developers know: testing makes you a better programmer. It’s not just that your code works. It’s that if you find something is hard to test, that’s a code smell. Maybe your superWunderFunction() which takes 13 arguments isn’t designed terribly well. That’s not saying that all hard-to-test code has a design flaw... but as you test more, you start writing code that’s easier to test...

When you start writing code that is easier to test, do you know what you’re doing? You’re eating your own dog food. You’re using your code and you start writing code which is easier to use. It starts becoming better-designed code. As an added benefit, if programmers are unsure how to use your code, they can always read the tests. Tests are not a substitute for documentation, but they are an excellent supplement to it.

Matt Drudge - Pedophile? LOL

Well, that might be going overboard. He only supports pedophiles with their habit when they are Republican congressmen.

There's a difference, right?

On the October 2 edition of his nationally syndicated radio program, Internet gossip Matt Drudge stated that Foley's sexually explicit alleged communication with a minor through an instant-messenger program "wasn't coerced." Drudge went on to say that "the kid was having fun with this" because the alleged conversation included "[t]hese LOLs throughout the entire conversation, these 'laugh out louds.' " Drudge even went so far as to accuse the underage former pages -- whom he twice referred to as "beasts" -- of "egging the Congressman on" during their alleged conversations, claiming that "[t]hese kids were playing Foley for everything he was worth," as Media Matters for America noted.

But this coverup is across the board with Republican politicians (Gingrich, et al.), spokespeople (Snow, et al.), and media celebreties (Limbaugh, et al.).

I would hang my head and stay inside for a week if I were a self-respecting Republican right now. This is a disgrace so far beyond that previous Clinton disgrace. Where is the outrage at the acts? Where is the outrage at the cover-up? Where is the outrage at the cover-up of the cover-up? We're talking about *children*.

Vote the other ticket in the election. Then they get to investigate everyone for the next couple of years to find out what's really been going on in congress and the administration.

And how about that congressman (Reynolds?) who brought some "kids from his community" to his press conference so the media could not ask detailed questions about sex?

LOL indeed.

When All Else Fails

There is a lot of fear about dynamic languages in the comments at James Robertson's blog (and at Tim Bray's).

I recommend these handy little things called "tests". When all else fails, do the right thing.

The devil is out to steer you onto the wrong path.

I'm convinced that they are not suited for large-scale software development...

I guess if I listened to the devil, he'd have me recall all those large-scale applications I've written over the last 25 years that have designed electronics, moved things through factories, dispatched equipment in hurricanes, and so on because they're not written in a suitable language.

Beware the devil. Over on the devil's own blog...

I think there [a solution]: dynamic languages that allow you to type your variables if you feel like it, and the only language that I can think of that does that at the moment is Groovy.

Well, let's see. Common Lisp had that about 22 years ago. Maybe there's something to learn from a couple decades of real experience? Conclusion? Feh.

This is the devil that used to want you to program in C, not Smalltalk. Then C++, not Smalltalk. Then Java, not Smalltalk. Now he's willing to give you Smalltalk if you type your objects once in a while.

Don't listen to the devil. Write tests in simple, dynamic languages. Do good work. Keep the devil at bay.

October PSUG - Smalltalk in Portland

The Portland Smalltalk User Group meeting is next week. New location at the Gemstone offices in Beaverton.

Erlang Workshop

Some slides, etc. are online.

Shades of Kelsey

Also from the recent Scheme Workshop... "An Incremental Approach to Compiler Construction"...

Real-life compilers are too complex to serve as an educational tool. And the gap between real-life compilers and the educational toy compilers is too wide. The novice compiler writer stands puzzled facing an impenetrable barrier, “better write an interpreter instead.”

The goal of this paper is to break that barrier. We show that building a compiler can be as easy as building an interpreter.

Termite Part Deux

From the recent Scheme Workshop, here is the follow-up for Termite, Concurrency Oriented Programming in Termite Scheme (pdf).

Our system is well suited for building custom protocols and abstractions for distributed computation. Its open network model allows for the building of non-centralized distributed applications. The possibility of failure is reflected in the model, and ways to handle failure are available in the language. We exploit the existence of first class continuations in order to allow the expression of high-level concepts such as process migration.

Are You Not Entertained?

From the Republican House's torture bill (again via Steve D.)...

"No court, justice, or judge shall have jurisdiction to hear or consider any claim or cause of action whatsoever, including any action pending on or filed after the date of the enactment of the Military Commissions Act of 2006, relating to the prosecution, trial, or judgment of a military commission under this chapter, including challenges to the lawfulness of procedures of military commissions under this chapter."

Let's remember back a few years...

If this were a dictatorship, it'd be a heck of a lot easier, just so long as I'm the dictator. -George W. Bush

The next couple of years will make the highlight reels of American politics. Someone's going down, but it is not yet clear who. So far it looks like Lady Liberty is heading for the floor.

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.