the move to Java wasn't the win they thought it would be. As he says:

"It's quite possible WebObjects would have simply completely died if it remained Objective-C. But WebObjects is hardly burning up the world as pure Java nowadays, is it?"

It has less users than ever as a Java technology, which pretty well bears out my prediction that moving it to Java would just make it a red headed step child. The old Nexties hate it because its not Objective C. The J-heads hate it because its "proprietary" and "non-standard" (not universally lame).

These days I'm preferring Seaside with GLORP but there are maturity issues there that WebObjects had nailed.

I think his take on Python is dead wrong too. Squeak would be more natural and I've done a Squeak/Objective C bridge with Avi Bryant and Alain Fischer. Its a little shakey and needs work but the calling syntax is the same so its a big win. Plus, if you want a scripting language for Objective C, there's always[link|http://www.fscript.org| FScript].

"A design should not be tied to a language. "

How can you say that? There are a number of features in languages that enable certain design capabilities.

For instance, because there is message forwarding in ObjectiveC and Smalltalk, distributed objects is trivial and requires no code generation. You simply create a subclass of ProtoObject as a proxy and override doesNotUnderstand: aMessage (in ObjectiveC the equivalent is called forwardInvocation:(NSMethodInvocation*)msg) to package up the info about the invocation and send it over the wire. Its dead simple.

Its also impossible in something like Java or C++ without doing code generation. So right there message forwarding makes a particular design sensible in one language and madness in another.

Howabout "faulting" objects from a database? The same kind of message passing/doesNotUnderstand: trapping can allow you to create an object that stands for a query to a database, and in its implementation you can say:

self become: (classToBecome fromQuery: (self query execute)).

This causes the object to become an object of a different class. Nearly impossible with static langauges. (OK, nothing is impossible, but many things are impractical without godlike skills in the lesser languages).

I spoke with one of the developers who ported EOF to Java. He remarked that EOF was "possible to implement EOF in Java since you knew how it was supposed to work, but Java would never have led to EOF's invention because of all of its limitations". However, faking faulting and become: was really problematic and was mostly solved with a fairly ugly code generation hack.

AOP requires a whole separate technology in Java, but in Smalltalk its almost part of the language.

Continuations - the essential secret sauce in Seaside - don't exist in Java. There is an attempt to "fake it" using fancy thread blocking that gets you part way there, but again, because this is so hard to do in Java, yet easy to do in Smalltalk, it would never be invented in Java.

Language capabilities definitely influence design.