Comments on Sven Efftinge's Blog: Dear Java killers,

Excellent points, most of them. I'd agree with...

2011-11-10T18:42:17.827+01:00

Excellent points, most of them. I'd agree with Dusan about what you're calling "obsolete" features, though.

As a guy who worked on ANTLR, and other code-generators, constructs like break, continue, case-fallthru make code generation much simpler.

In day-to-day programming, I also regularly use break/continue to make loop processing much more clear, eliminating yet-another-boolean-flag-in-a-loop-condition growth.

Keep up the good work on xtext! Awesome tool!

I agree with most of your post, which is why I don...

2011-11-10T13:55:18.402+01:00

I agree with most of your post, which is why I don't understand the decision to add a "def" to function definitions in Xtend which only adds unnecessary verbosity.

Unreified generics get a bad rap, but maybe undese...

2011-05-07T21:27:43.951+01:00

Unreified generics get a bad rap, but maybe undeservedly so. One thing that's important to note is that the only widely-used languages that do reify generic are the .net languages and C++. Do ML, OCaml, or Haskell have reified generics? Nope. And, yet, they are often seen as ideal implementations of universal polymorphism.

In my opinion the shortcomings of Java's generics lie elsewhere: No coverage of primitive types, wildcards making life complicated for library users (as opposed to library designers), arrays sticking out like a sore thumb, to name just three. Neither of these problems is found in .net (nor, I should say, Scala), and that's why .net and Scala generics are generally perceived to be superior.

Thanks for this great article Extreme Java

With Groovy, you can have the benefits of static c...

2011-04-19T20:44:37.353+01:00

With Groovy, you can have the benefits of static checking with IDEA joint-compiler. It's like bring the best of both worlds.

> closures Java has closures since ... i don&#...

2011-04-18T18:31:32.055+01:00

> closures

Java has closures since ... i don't know when -- inner classes create closures. What it's lacking is clean syntax for lambdas.

With respect to reified generics, the essential pr...

2011-04-18T16:41:54.050+01:00

With respect to reified generics, the essential problem with them is that they encourage a style of programming that is not scalable: they encourage explicit type checks. One of the fundamentals of object-oriented programming is that it is necessary to separate interface from implementation to keep concerns properly decoupled, but as soon as you start doing explicit dispatch based upon concrete type, you couple whatever is doing the dispatching to the implementation of those types.

There are, of course, situations (serialization being the prime example) where having the extra type information would be nice; here, Scala provides such a mechanism with implicit manifests. Local and optional reification can be useful, but I don't believe that it should be the default, as most of the time it would cause more problems than it solves.

Mmm, I tried to post my comment some days ago (wou...

2011-04-18T11:28:45.090+01:00

Mmm, I tried to post my comment some days ago (would have been the first one) but Blogger rejected it. Looks like it is the OpenID identification which is broken... [EDIT: Google account doesn't work either. Will try just Name/URL...]

I will just paste the comments below, even if some points have been already addressed by some comments above.

"Don't make unimportant changes"
I agree, I found that the search of originality in Ceylon was sounding strange. If Java was irregular, it was just a matter of making it more regular with existing vocabulary.

"Static typing"
I won't argue there! :-) But "I wouldn't try to come up with a new statically-typed Ruby, since that doesn't make much sense.": you don't know Mirah programming language, don't you? ;-)

"I don't think that more than 1% of all Java developers have really understood generics. [...] most Java developers think they know generics and feel quite comfortable with it"
So there is a difference between self perception of knowledge and real knowledge? :-)
"After all generics in Java are rather sound"
Indeed, they have been designed by the creator of Scala... :-) who has been frustrated by the limitations of the JVM.
I think I disagree with your view about reified generics, but I am not competent enough to argue...

"Use Type Inference"
Not arguing there! ^_^'

"Care about Tool Support"
Idem, and the Scala community is aware of that as well. I just disagree with your analysis of the name proposal. Actually, I didn't even know the feature existed, and I doubt I will use it... Yes, I like the varName: typeName syntax, I find it clearer/more regular than the Java syntax and that's one point that annoys me in Ceylon.

"Closures"
Yes, we need them.

"Get rid of old unused concepts"
I agree, except we still do lot of bit shifting and masking, eg. in image processing, I don't see them superfluous.
OK, maybe we don't need them at the syntax level, they can be hidden in a class, speed is rarely a concern there.

Blogger clearly prefers to erase the types as well...

2011-04-18T10:46:45.078+01:00

Blogger clearly prefers to erase the types as well while processing the entries :)

c in last snippet is collection of animals.

Q1: In what ways? Logically, you should be able ...

2011-04-18T10:28:03.414+01:00

Q1: In what ways?

Logically, you should be able to do more with more information available; things like

- do X based on incoming not erased type; X={routing, (un)marshalling, ...}
- new T (generic argument injected from outside)
- remove useless generic arguments and casting from codebases with stuff similar to this
http://www.vshank77.com/2009/12/builder-pattern-abused.html
- ...

Q2: What are you doing there?

With 100 mil. "advice" files I meant many files across enterprise projects in whole industry, not in my project :)

Q3: Any examples?

Let's assume you have classes Animal, Dog & Cat...

Would code bellow be a issue, or it is just a special case because of type erasure?

public void go(Collection c) {
c.add(new Cat());
}

Completely agree "timate thing for a develope...

2011-04-17T13:24:43.760+01:00

Completely agree "timate thing for a developer to write programs in a language you've built your own", on that situation you can't blame other for any shortcomings of language though :)

Javin
Top 10 Java Serialization Interview Question

> Dusan said... > Couple of things: > >...

2011-04-16T22:48:35.485+01:00

> Dusan said...
> Couple of things:
>
> 3)
> Type erasure was the worst idea ever and as far I
> know it was done as a compromise for
> compatibility reasons. If this would be working, we
> would be much more expressive

In what ways?

> + we would not
> need to have 100 mil "advice" files spread across
> enterprise projects (see projects like Dozer,...)

What are you doing there?

>
> Type erasure also heavily contributed to all the
> edge cases, exceptions and complexity of generics
> in general.

Any examples?

>
> 7)
> Fundamentals like bit operations are required:
> hashing, libraries that deal with binary and hi
> performance stuff and others rely on this...
> (unsigned data types are completely missing...
> leading to inefficient hacks on java side)
>
> I would like to know the reaction of ANTLR guys to
> fall trough switch removal proposals... :)

My last point should have been:
Don't be everything to everyone. ;-)

> Anonymous said... > moreover creating a ne...

2011-04-16T22:44:18.479+01:00

> Anonymous said...
> moreover creating a new language should be an
> community process at least to define feature set
> (specs) and implementation. it should be developed
> bit by bit.
>
> new language must not be developed in isolation
> otherwise it will fail.

A programming language needs to be concise and coherent. It needs to be scoped, and should have a certain flavor and *feel*. A lot of very good languages have been initially designed by just one person (e.g. Scala, Java, Ruby, Python).

> Cay Horstmann said... > Loved the article,...

2011-04-16T22:41:10.214+01:00

> Cay Horstmann said...
> Loved the article, but I was a little confused about
> the point you are making with generics. It hasn't
> been my experience that all nine million Java
> programmers have a solid understanding of
> generics. Sure, anyone can deal with array lists of
> Foo, but when it comes to wildcards or erasure, I
> think most people just close their eyes and hope
> that the moment will pass. Which it usually does-

Yes, they are somehow used to it.

> -except for library writers, of course, who will
> need to knuckle under and master this stuff. So, to
> get to my question, how is different from Scala?

Even if Scala's type system is maybe even better from a neutral point of view it is very different and that scare a lot of people off. Even though they don't fully understand the type system they use (Java's) they are used to it.

I don't think that there are library users and library writers. Every programmer is both. It's just that some libraries are bad and some are good and some have few clients some have many.

> Isn't Xtext targeted for niche/business s...

2011-04-16T22:32:50.063+01:00

> Isn't Xtext targeted for niche/business specific DSL's
> and not so much for large codebases of a generic
> language ?

DSLs are small programming languages and Xtext is a framework for programming language development.

It is mostly used for smaller languages but that is just because the market for general purpose languages is not that big. Xtext is used for grown-up language IDEs (also commercial ones).

This one for instance is built with Xtext : http://goo.gl/Hsz79

> Adam Rabung said... > Great post. Can you ...

2011-04-16T22:25:10.812+01:00

> Adam Rabung said...
> Great post. Can you elaborate on why reified generics
> are a bad idea (besides Java interop problems)

It is mostly the interop problem.
But they would also have a huge effect on a lot of other language concepts. You should for instance change the instanceof operator to allow generified types. And what about overloaded methods such as foo(List) {} foo(List) {} should that be allowed than?

> Dennis Doubleday said... > Java 7 does hav...

2011-04-16T22:06:24.310+01:00

> Dennis Doubleday said...
> Java 7 does have some movement toward type
> inference in Project COIN.

Yes, it's slowly getting better. Very slowly.

>
> "There is no way your language can be successful
> without closures." Seems a bit extreme--after all, 9
> million Java developers disagree :-)

I don't think they disagree.
They might be a huge percentage of developers who don't know what closures are or at least don't know why they are so important.

The rest simply agrees with me :-)

"Given that over nine million people are used...

2011-04-16T21:58:25.320+01:00

"Given that over nine million people are used to it and absolutely understand the semantics, I'd consider this an unfortunate decision."

Just do as in C#, whether impl inheritance or interface inheritance, it's the same keyword (or character).

"I wouldn't try to come up with a new statically-typed Ruby, since that doesn't make much sense."

Well that's what Mirah is though.

"Also note that reified generics are a bad idea."

Beg to differ. Try to explain to a Java generics newbie, why he is not allowed to implement Comparable[T] and Comparable[K]. That's a duality of the type-system we just don't need.

Couple of things: 3) Type erasure was the worst ...

2011-04-16T21:58:14.806+01:00

Couple of things:

3)
Type erasure was the worst idea ever and as far I know it was done as a compromise for compatibility reasons. If this would be working, we would be much more expressive + we would not need to have 100 mil "advice" files spread across enterprise projects (see projects like Dozer,...)

Type erasure also heavily contributed to all the edge cases, exceptions and complexity of generics in general.

7)
Fundamentals like bit operations are required: hashing, libraries that deal with binary and hi performance stuff and others rely on this... (unsigned data types are completely missing... leading to inefficient hacks on java side)

I would like to know the reaction of ANTLR guys to fall trough switch removal proposals... :)

Good post.

Thanks

> Anonymous said... > The example used for y...

2011-04-16T21:56:42.436+01:00

> Anonymous said...
> The example used for your fifth point is inconsistent
> with your fourth. If you're using type inference then
> the IDE won't know the type until your past the
> assignment operator i.e. val myVal = ...

That is only if you initialize the field.
My example also works for function/method parameter declarations in Scala vs. Java.

> Eric Parnell said... >I would add that you...

2011-04-16T21:54:29.266+01:00

> Eric Parnell said...
>I would add that you need some level of functional >programming ability such as maps, folds, pattern >matching, currying, and functions as first-class objects.

I have omitted libraries in my most just to make it shorter, but integrating with the JDK and at the same time being able to add features to existing types like collections is very important. The higher-order functions you mentioned should ideally be made available on java.lang.Iterable using a library approach.

Pattern matching is nice but I think a type guarded switch statement is sufficient and much easier to understand (and to implement).

Currying can be done via library and functions as objects IMHO isn't a good idea since objects of types with just one method fits much better with the existing JVM concepts and libraries.

What is irregular about the concept of "exten...

2011-04-16T19:20:41.443+01:00

What is irregular about the concept of "extending" the contract of an interface with a specialised interface, and "implementing" said contract with a class? Java is extremely regular in that respect.

I've responded to this post wrt Gosu here: ht...

2011-04-16T18:52:11.396+01:00

I've responded to this post wrt Gosu here:

http://guidewiredevelopment.wordpress.com/2011/04/16/re-dear-java-killers/

Cheers,
Carson

thanks for write up I would like to add that apart...

2011-04-16T13:33:57.544+01:00

thanks for write up
I would like to add that apart from ide/tools consideration the language shoul be easy to type also. for example i hate to type colon :

moreover creating a new language should be an community process at least to define feature set (specs) and implementation. it should be developed bit by bit.

new language must not be developed in isolation otherwise it will fail.

Enjoyed this blog post immensely (I disagree with ...

2011-04-16T09:51:07.530+01:00

Enjoyed this blog post immensely (I disagree with a couple of the arguments made though)