In a follow up post on his blog, Jon Udell brings up another role for dynamic languages in the web services "revolution" -- on the client side.

One that I didn't allude to in the column, but think about a lot, is the role that I have long believed dynamic languages should play in the rapid development of what we are now calling "rich Internet clients," or what Adam Bosworth has recently been calling the Web services browser.

This is one of the reasons that I am interested in Chandler -- it is based on Python. If you look at Haystack, you'll see that they took the same approach, except they did it all themselves. They rolled an RDF aware equivalent of Python in Java (called Adenine) and then built Haystack on top of that. (By the way, as I built the link for Haystack, I noticed that they've done a new release).

My personal experience with this goes back at least 10 years now. When I was graduate student, Emacs was my world. In particular, via GNUS, VM, and BBDB, I was managing all of my "personal information" via applications built atop a dynamic language, Emacs Lisp. Configurability, behavior change, smart behavior, etc. Now I'm not suggesting that Emacs is the platform for information clients, but for me it's long been a proof that this is a feasible and desirable thing to do.

Later today, I saw Don Box's follow up to Jon's posting. This was more on the language/plumbing end of things:

More and more, however, I'm less convinced the problem is with languages per se but rather is related to how dynamic linking and binding works in most modern object systems.

If you are looking at doing more decoupling of components in the system then I agree that the linking and naming/binding models are the places where you'd try to change things. To build extensible, flexible applications, both client and server side, this is going to be a requirement.

I think we can do way better than the current state of the practice.

Is there something in the research literature that points at what you are thinking?

I don't think the answer is for everyone to adopt Perl - if that's our only hope let's give up now.

I'm in agreement with this.

Today's "modern object systems" are more loosely coupled than their predecessors (I'm not saying that's enough). I think that there are two reasons for that: automatic memory management (aka garbage collection) and dynamic linking.

In the early 90's when I argued with people about Lisp like languages, I was always getting pushback on the syntax, and on garbage collection. Today, I no longer have to argue with people about garbage collection. Java and C# have made it acceptable. But people misunderstand its importance in constructing modular systems. Most people like garbage collection because it eliminates memory smashes. This is true and definitely a big benefit. But the bigger benefit of having garbage collection in the language is that subsystem designers no longer have to worry about which subsystem owns the memory. This makes it much easier to break things apart and reuse them. When you have to manage memory by hand, your subsystem has two "protocols" jammed into a single mode of expression (the API). You have the application level protocol for the subsystem, and you have the memory management protocol for the system, so that subsystem users know how to interact with objects that came from the system. We don't have to deal with that any more and that decouples subsystems a lot. So we killed two birds with one stone, but we only saw the carcass of the smaller bird.

I specifically said dynamic linking here and not virtual machines. Virtual machines are one way of implementing dynamic linking, but not the only way. The "non-scripting" dynamic languages have been doing this for quite some time.

If some qualities of dynamic languages turn out to be a match for a need in the web services / information client realm, then I'm happy because it may give people a reason to look seriously at dynamic languages again. And then maybe over time, they'd discover some of the other good qualities as well.

Chris Winters posted an embarrassing comparison between the Perl libraries and the Java libraries for a simple task. Unfortunately, for Java, use of the libraries rapidly blows up the code. More code == more opportunities for bugs. It would be instructive to see C#, Python, Ruby, Lisp/Scheme, and Smalltalk versions of this. It just goes to show that the design of the libraries is just as important as the design of the language. This is related to Kim's overuse of abstraction posting about abstraction and syntax. Designing libraries is about designing syntax. It's nice that the libraries provide a large number of abstractions. But it would be nice to have some additional "syntax" for the common case.

It figures that I post about the new GnuPG, and the very next day someone comes out with a tutorial for using GnuPG with Enigmail, a plugin to either Mozilla Mail or Thunderbird. Just one more reason to get off Outlook.

• [ via Chris Double and Gordon Weakliem ] Bill Clementson has started a Lisp blog, which is great. But there's no RSS feed...
• Alek wants to know "Where Are Java Senior Engineers?". Chris Brumme is doing major marketing damage to Java.net, and he doesn't even work in marketing or PR.

Gay and Troy don't live on Bainbridge Island, but they do live on Vashon Island, which makes them fellow islanders...

Go check out their web based aggregator MyWireService. Gzip enabled too.

The final version of NetNewsWire 1.0.4 is out, but it hasn't even made the list of aggregators on the front page. Go do Brent a favor, and get the latest and greatest. Do me a favor, and point that newly Gzip enabled aggregator at my RSS and cut my bandwidth consumption.