Of course after I write a few entries about the .NET CLR, Microsoft lowers the patent boom that we've all been waiting for. In one way this is a relief, because we don't have to wait for them to lower the boom any more. They've done it, and we can see what kinds of claims they are making. From my look at the filing, it seems like their claims are very general and overly broad. It seems like the claims are mostly directed at the web services stuff, but their description is so broad, it seems like it would cover J2EE 1.4 with it's web services functionality. And look at claim 42:

A method of organizing a set of types into a hierarchical namespace comprising: creating a plurality of groups from the set of types, each group containing at least one type that exposes logically related functionality; assigning a name to each group in the plurality; and selecting a top level identifier and prefixing the name of each group with the top level identifier so that the types in each group are referenced by a hierarchical name that includes the selected top level identifier prefixed to the name of the group containing the type.

This sounds like the Java package mechanism to me.

Its going to be interesting to see how this plays out. It probably just made a whole lot of people who were interested in the CLR (like me) a lot less interested. Until this filing, there was some hope that things might be different, that the ECMA process might mean something. But not it seems clear that nothing has changed.

Chris Double points out:

Maybe I'm misunderstanding Ted but I don't agree with this statement. Perhaps it was true in the past but modern Lisp's and Smalltalk's seem to have no problems talking to the machine.

I did say I was oversimplifying a bit. It is true that today, and for some period of time, Lisps and Smalltalks have been able to talk to the hardware. But it is a recent development, and many who had already formed opinions about these languages didn't bother to learn about them. Plus, every Lisp at least, had a different way of doing this. So from an industrial perspective, you were being locked in to a particular vendor's Lisp implementation (never mind that this is exactly what is happening today with Java and C#). I remember going to a trade show in 96 with some of my Taligent co-workers after Taligent was fully bought out by IBM and we were porting parts ofthe CommonPoint frameworks as a crossplatform OpenDoc / OLE solution. The Harlequin guys had a demo of Harlequin Dylan where they were using Dylan to implement an inprocess COM server. They were showing the ability to start and stop the server from Dylan as well as dynamically update the code and continue. This "hot-swap" debugging feature got into the JDK in 1.4, only 6 years later...

Today what we need some degree of uniformity for talking to the machine. That's the benefit of Java or the .NET CLR. The library stack. It's there if you want to use it. If not, you don't have to use it. But you have some least common denominator to fall back on.

S# is interesting, but it has the single source problem. If Dave Simmons gets hit by a truck, S# users will be in a world of hurt. That's why I'm excited about the possiblity of an open sourced Functional Developer.

Charles Cook has also picked up the Dylan thread:

Dylan has features such as MI, multi-dispatch, no casting, and macros which are all missing from both Java and C# (the macros being real macros in the Lisp sense and not C-style macros). I get the impression that Dylan is a considerably richer language than Java or C# yet is claimed to be just as efficient as those languages.

Real macros solve so many problems its not funny. Look at all the AOP work going on in Java these days. There's two camps. The "we must modify the language so that this stuff is integrated" camp, which is working on things like AspectJ, and the "we cannot modify the language because no one will use it" camp, which is working on things like Nanning and Rickard's unreleasd AOP library. If Java had macros, we could integrate AOP in a seamless way, without having to write custom compilers and all the rest of the stuff that the AspectJ guys are doing. And besides, the AspectJ folks are taking all the lessons that they learned doing Meta Object Protocols for Lisp/CLOS and repackaging them as AOP. Charles also writes:

Its difficult to say for sure whether being familiar with a wider range of languages actually helps you design and implement better Java or C# programs. My feeling is that being more aware of the limitations of these languages does help: seeing things from a broader perspective improves understanding and in the same way that Patterns enhance the way you think about design problems, knowledge of a wider range of languages gives you more concepts to work with, even if you cannot directly use some of the techniques with the language you are working with.

Those interested in patterns should look at Peter Norvig's article on Design Patterns in Dynamic Languages. I first heard about this work when I interviewed with him when I was thinking of going to Harlequin. Oddly enough, it was my interview with him that convinced me that Dylan was not going to be successful in a commercial sense. However, his paper is just excellent. Norvig tried implementing patterns in a bunch of languages, and discovered that 16 of the 23 GoF design patterns are either invisible or much simpler in Dylan. The best pattern is the one that you don't need.