[gavinking]

Now you're just lying. You said:

"The problem with reified generics isn't their efficiency, but that they don't play nice with other generic types on the platform (which is the vast majority)."

And the context of the comment was quite clearly Ceylon interoperating with Java as anyone can verify.

I have a friendly request for you: please don't comment about Ceylon on any more hackernews or reddit threads. It's great that you like Kotlin and are having success with it. I'm happy for you. Post about how great Kotlin is on all the Kotlin threads you like.

But it's just not a good thing for anyone that you're going posting on Ceylon threads, speculating about made-up problems with Ceylon, and pretending you know Ceylon when you don't.

So please stick to the Kotlin threads is all I'm asking, OK?

[twic]

> I have a friendly request for you: please don't comment about Ceylon on any more hackernews or reddit threads.

This is really unproductive. Reddit and HN are discussion forums; what we want on them is more discussion, not less. We want high-quality, accurate, discussion, but if we're not getting that, the solution is to raise the quality, not reduce the volume.

In particular, the last thing i, as a reader of discussions, want is for a discussion forum to turn into a confederation of theocracies where nobody but the local priesthood are allowed to speak.

So, pron, i also have a friendly request for you: please continue to comment about Ceylon wherever you like - but make sure you've done your homework before doing so!

Specifically, if you could produce a concrete example of how Ceylon's reified generics interact poorly with Java's generics, that would be really interesting. If you could produce an example of how non-Ceylon reified generics interact poorly with Java generics, then that would be interesting, and gavinking could explain how Ceylon avoids the problem, which would also be interesting. And if you find that actually, there isn't such a problem with reified generics, that would be interesting too, not least for you.

[pron]

Assume you have language with a generic type List<T>, and an instance, v, of the type List<Integer>. Can you then pass that value to a method expecting a List<Number> (assuming Number is a supertype of Integer)? Well, that depends on the variance rules of the language and the runtime. On the JVM, any type is checked both at compile time and at runtime. Erased generics, though, mean that the runtime type of v is just List, while reified generics mean that its List<Integer>. When a type is reified -- namely, its full type information is available at runtime -- the runtime needs to know the relationship between any two types: does one extend the other or are the unrelated? But with generics and variance, there is no "best way" to do variance and different languages may choose different variance models. Because the runtime has to know what is the relationship between any two types, the v variable has to know, at runtime, whether it is also an instance of List<Number> or not. This means that the same generic classes cannot be shared among different languages with reified generics, if they have different variance rules, because the language's decision is baked into the compiled class. That's what I meant in my comment. Languages on a JVM shouldn't have reified generics because then they may not play well with others.

With Ceylon, the issue is different, because the JVM -- unlike the CLR -- doesn't have a standard way of specifying reified generics (and that's a good thing, IMO, because of the "baked-in variance problem"). However, that means that none of the standard Java generic classes are first-class citizens in Ceylon world, because they don't have the reified runtime type information. This isn't a problem for Ceylon because one of its stated goals (it says so right on their website) is to replace the Java standard libraries, so this incongruence doesn't even matter to them because a Ceylon List and a Java List are not even the same type to begin with. That a Java list instance does not have a reified generic type in Ceylon is, therefore, not a problem for them, because Ceylon didn't set out to make the existing classes first-class citizens of its brand-new ecosystem.

This is why I and the Ceylon guys have this misunderstanding. They think I'm saying Ceylon has a problem, but I'm not. Ceylon has certain core design goals that may be what some people want but not others, that is all. But those design decisions do have ramifications.

BTW, the "baked-in variance" problem will not get introduced into the JVM with the addition of specialized generics for value types in Java 10, because value types can't extend other types, and so a List<int> can't also be a list of any supertype (or subtype).

[gavinking]

>> none of the standard Java generic classes are first-class citizens in Ceylon world, because they don't have the reified runtime type information <<

This is just not true. In Ceylon when you import a Java generic class, you can do everything with it that you can do with the same class in Java.

Please stop posting incorrect things about Ceylon. You're coming off as a walking, ranting, personification of the Dunning-Kruger effect.

[pron]

> you can do everything with it that you can do with the same class in Java

Of course! I have not said otherwise. I have said that you can't do with them everything you can do with Ceylon classes, hence -- not first-class citizens.

Now, I would appreciate you stop calling me names, because I haven't called you names. On the other hand, you have not addressed even a single one of the main points I've raised, except come back with great fury against some statements I've made that may not have been clear. So I would also appreciate you taking the time to understand what it is that I'm saying rather than what it is you think I'm saying, because I have not said a single bad thing about Ceylon in this entire thread (on the other hand, I have paid it and you several compliments because it really is a beautiful language), except that I believe a more compromising approach to language design would prove the more pragmatic one in the long term. Please try to understand what it is that I'm saying before blowing a fuse. We are in total agreement (on the facts, at least).

I joined this discussion to sound an observation about different design philosophies in language design (in rare agreement with a comment by Imm), then I commented to a user who asked about the differences between Ceylon and Kotlin (answer: different design goals), and you just keep calling names left and right and think I'm out to spread FUD or that I have an animosity against Ceylon. Jeez. So I will say it -- again -- just so there's no misunderstanding: Ceylon is a terrific programming language, and anyone whose goals are aligned with the language's goals should definitely give it a try!

If you think I have posted something that is incorrect or can be misunderstood, please add your correction politely. Why politely? Because you just might have misinterpreted my intentions or my words, and by being polite you might avoid saying things you may regret. Even if you really think that I'm trying to hurt your language or just so stupid that I keep making the same mistakes over and over, still keep a polite tone, because other readers of the discussion may not have the same interpretation as you.

[incepted]

> On the other hand, you have not addressed even a single one of the main points I've raised, except come back with great fury against some statements I've made that may not have been clear.

And this is why creators of languages should refrain from participating in discussions about the language they created. Especially when they post so much stuff and they seem to be the only person in the 100+ messages defending the language.

Either Ceylon stands on its own merits and other people will come to correct misconceptions about it or... there's simply not enough people who care about it.

[pron]

Well, at least in this case, gavinking's protests were utterly unnecessary because I didn't attack the language (despite his beliefs to the contrary) so there was no need to defend it. I just wanted to clarify its clearly stated, official design goals, and later (after being called lots of names) also asked why the language designers think those goals are the right ones to address, because on the face of it, they appear to be the wrong ones to me. It is, of course, a matter of pure opinion and outlook, but still, it is interesting to hear the designers' views (especially because a new language is generally something that makes a much stronger statement -- ideological, philosophical -- than most developer-facing software products. Even if gavinking thinks I have misunderstood Ceylon's treatment of generics or the quality of the Java interop, those topics were really not the core of my statements, but rather Ceylon's basic raison d'etre.

[lomnakkus]

> please continue to comment about Ceylon wherever you like - but make sure you've done your homework before doing so!

The issue with this type of comment is that we (humans) have a set of cognitive biases which often lead us to think that we've "done [our] homework" when, in fact, we haven't. Such a person would probably actually only absorb the first portion of the quoted sentence from your post.

(Sorry for the slightly OT.)

[justthistime_]

He did the same uninformed rants about other languages for a long time already. It's unlikely that he will do his homework any time soon.

[pron]

What's unlikely is that you'll ever try to understand what it is that I'm saying when I talk about language design goals.

[tome]

Seconding that.

[pron]

Happily, as long as you don't misrepresent the difference between the languages.

[gavinking]

Thank you, I appreciate it.

[pron]

Thank you!