Re: Another nit

Ted Neward wrote:

I would argue this is very bad language design. The rules are so
obscure, hard to communicate, hard to teach, hard to learn. The
programmer who focuses on understanding and using these rules might be
far better off focusing on the application and writing code in a clear
transparent way so that other developers, testers, algorithm designers
can focus on the application and not get bogged down in language
minutiae.  Above all, the code has to be easy to read and not require
the reader to carry out a large amount of implicit knowledge in her
head. With Java you have to know precious few language-specific rules, a
few basic principles carry you a very long way.

    

So explain why Enum<T> inherits from Enum<T> again? Or why the Target
annotation in turn makes use of the Target annotation? (They both have good
reasons for this, but frankly most Java developers point to them both as
examples of why Java has crossed a complexity threshold in 1.5.)
  

(I think you meant Enum is defined as |class Enum<E extends Enum<E>> ....|, and yes this is odd.) I am not a fan of 1.5; it has become quite complex ... and all this without closures and proper treatment of concurrency and emasculated annotations! Sigh. Thats why there are people working on new languages :-).

I didnt follow your argument, though. Of course one wants simplicity of conception, design, implementation, principle of least surprise.  I think it is debatable how much implicit coercions are a help to the reader.

But perhaps we are off-topic.

Best,
Vijay

-- 
X10: Programming parallel machines, productively (http://x10.sf.net)