But ...

A design should not be tied to a language.

But I have to say, I like it when I hear maturer programmer complain about a programming language. I always thought that it is a sign of immaturity and childness to hate a language because it just feels like an ugly to do work with it.

Languages are an interface, and people develop taste in that, for example I like to express my self in traditional arabic, not that I can't express the same in the egyptian slang.

I don't think Apple wanted to make a decision based on taste, thy wanted to be practical, but the truth is, taste and other human factors sould have been part of their market research.

I do think people nowadays have a programming language crisis, too many languages just trigger more taste issues, people are learning to have more sophisticated taste, Java was ok, but now, we want more, python is not good enough, Ruby is getting rusty, and Perl 6 will be boring before it's even released.

Now people are looking to more exotic ways Mozart/Oz, MetaOcaml, and Haskell.

"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.

Welcome to IWETHEY!