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.