Sun has a new article describing new language features in JDK 1.5. I love this sidebar quote:

The new language features all have one thing in common: they take some common idiom and provide linguistic support for it. In other words, they shift the responsibility for writing the boilerplate code from the programmer to the compiler.

In other words, we're modifying the language because we didn't have a macro system that we could do this with -- at least for generics, enhanced for, static import, and attributes. Getting rid of boilerplate code is what macros are all about.

Also notice that 3 out of the 6 features in the article are being copied from C#.

James Strachan is conflating the language and the IDE. It is not impossible to write an Eclipse-like IDE for a dynamic language. Python and Perl are not the only dynamic languages in the world. Just because you don't see them for Python, Perl or Ruby doesn't mean they aren't there. Look at some of the environments for like Lisp and Smalltalk. I want the combination of the most productive language and the best environment.

Tim Bray weighs in with some good points:

The languages in the "R.I.P." list above do have some other advantages beyond strong typing. One of the big ones is memory footprint: if you're writing a big system with big complex in-memory data structures (which every big system I've ever worked on has had), their size can spiral out of control insanely fast in any of those dynamic languages. These things want you to build all your structures around hashes and dictionaries, which we all know perfectly well only work well when sparsely populated; work it out.

The memory bloat argument also applies to Java and C# (unless you are doing unsafe programming).

Secondly, and in the same spirit, there do remain performance issues. There are is some (small) number of people who have to write low-level webserver code, and if you've ever done this under the gun of a million-hits-a-day load, you quickly become a control freak with an insane desire to remove as many as possible of the layers which separate your code from the silicon.

The performance argument is valid one, but again, you have to take Java and C# off the list of good languages. Today's modern Lisps in can outperform Java and C# code running on their respective VM's. And under some, but not all circumstances, a good Lisp compiler can get you close to C. But I agree that there'll be a place for C for quite some time.

Sam quotes Sean McGrath. As much as I like Python, Python and Perl were not the world's first dynamic languages, and many of the criticisms levelled at them don't apply to languages like Lisp and Smalltalk.

Dave Winer adds another dimension:

And going dynamic is just the beginning. Add an integrated object store to the language and you really start flying.

To which I can only say, YEP!

Today I poked my nose into the OSAF Chandler chats. I'm glad to see these starting up and I'm hopeful that they will help get some momentum going for Chandler.

Some of the topics in the early chat were building the community, "what is chandler?", and ZaoBao, the RSS aggregator parcel.

I think that a lot of people don't really understand what Chandler is, so they think it's yet another Outlook replacement, which is boring, so they aren't interested in Chandler. I look at Chandler as a platform for building tools to help deal with the deluge of information. That deluge occurs in many forms: e-mail, RSS items, events, tasks, contacts, and a bunch of other free-form and structured information. The base Chandler product is a jumping off point for constructing (via customization, training, and programming) a personal information environment.

Chandler has a rudimentary RSS aggregator called ZaoBao. I think that trying to turn ZaoBao into a killer aggregator could help show what Chandler can do, and uncover some areas of the architecture that still need work.

In the late chat, the most interesting discussion was around Bayou, a project from Xerox PARC that may help with some of the data replication issues that the Chandler team is facing.

The Chandler team will be posting the IRC chat logs at some point.

I'd like to find out about ThreadsML. But I can't seem to find a specification or any single document that describes what ThreadsML is. I looked at the new ThreadsML site. But to no avail. Does some kind soul out there have the magic URL?

Jon Udell's article on SpamBayes is making me jealous. I just switched off of Outlook because it was taking outrageous amounts of time to talk to my IMAP server. I settled on Mozilla Mail in part because of the bayesian spam filtering. Mozilla's bayesian filtering still seems to be letting spam through. Unlike SpamBayes, I can't get any insight into the scoring of words. It could be that my spam corpus is too small -- mail has to get past spamassasin on the server before it hits Mozilla. Maybe I'll turn off spamassassin and see what happens (Ulp!)...

There are a few annoyances that I have with Mozilla mail:

• There's no visual status of whether a message has been forwarded or replied to.
• A signature is appended to every message - including replies.

I guess Carlos and I are going to have to agree to disagree on dynamic typing. My personal experience is that dynamic languages are more productive than languages with static typing. When someone can produce a language where I am more productive than I am in Lisp, I'll be happy to hold that up as the destination. All other factors being equivalent (libraries, IDE), if I had the choice of Java + Generics or Lisp, I'd choose Lisp. If we get to choose libraries and IDE, then give me a Symbolics Lisp Machine over Java+Eclipse any day of the week.