5 ms·

Well it should be very clear, that if you believe that Ceylon has a problem interoperating with Java's unreified generics, that you don't know enough about Ceyl

Well it should be very clear, that if you believe that Ceylon has a problem interoperating with Java's unreified generics, that you don't know enough about Ceylon to be able to comment with any sort of certainty on the topic of Ceylon and Java interop. Because you quite obviously have never even tried it once. That's clear, isn't it?

pron 11y ago
I didn't say that Ceylon has a problem interoperating with Java's unreified generics, just that reified generics on a shared platform have their own issues. The level of interoperability, though, is radically different from Kotlin's. And yes, I have never tried Ceylon because its stated design goals -- while great -- are not what I'm looking for. If I got the design goals and philosophy wrong I'll happily give it a try. I will also reiterate that I can certainly see that other people may prefer Ceylon's design goals over Kotlin's.
- gavinking 11y ago
  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?
  - pron 11y ago
    Happily, as long as you don't misrepresent the difference between the languages.
    - gavinking 11y ago
      Thank you, I appreciate it.
      - pron 11y ago
        Thank you!
  - twic 11y ago
    > 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.
    - justthistime_ 11y ago
      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.
      - tome 11y ago
        Seconding that.
      - pron 11y ago
        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.
    - lomnakkus 11y ago
      > 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.)
- UnFroMage 11y ago
  > The level of interoperability, though, is radically different from Kotlin's There's no truth in that. Sure, it's possible that there are some differences in how we both do interop, and that some things are easier in one or the other, but overall you've no basis for claiming that, and I strongly suspect you haven't tried Ceylon for interop at all or you would not say that. When you do try and find interop things that we should improve, please let us know in our issue tracker and we'll do our best to fix it. Meanwhile, please stop with the FUD.
  - pron 11y ago
    > Sure, it's possible that there are some differences in how we both do interop There are no "some differences", but a radically different philosophy which is at the very core of the language's design. A Kotlin list is a Java list and vice-versa; a Kotlin map is a Java map and vice-versa; a Kotlin set is a Java set and vice-versa. The same, BTW, is true for Clojure, but unlike Clojure, Kotlin doesn't just keep the interfaces, but also the implementations. Kotlin hardly even has a standard library. The Java standard libraries are Kotlin's standard libraries (modulo some extension methods). Ceylon has its own standard libraries, and, in general, Java libraries are not idiomatic Ceylon libraries. That Ceylon even has CeylonList/JavaList types shows how the two approaches are worlds apart. Comparing it to Kotlin in that regard is ridiculous, and I don't even know why you'd try. It is one of Ceylon's strengths that it has its own library, and one of Kotlin's that it doesn't. Each appeals to different needs, and I don't see why you feel you should blur the differences. > When you do try and find interop things that we should improve It's not about that. You may think that Ceylon's Java interop is great. It may be just the right amount of interoperability that you want. But claiming it is anywhere near Kotlin's is just preposterous. I didn't say that Ceylon's Java interop is bad, but it's just not even in the same ballpark as Koltin's. But that's OK, because the two languages have different philosophies. > Meanwhile, please stop with the FUD. Please stop calling it FUD. I have never, ever said people shouldn't use Ceylon, that it's a bad language or even that Kotlin is better. I have emphasized the big difference in design goals between the two languages that makes them very different in practice: Ceylon has an advanced, very elegant, beautiful type system, while Kotlin has many thousands of libraries. Where is the FUD? OTOH, instead of calling it FUD, and since this is a Ceylon thread, I would very much like to hear a justification for Ceylon's design; not the choices of the particular language features -- I will readily admit that Ceylon is the best language ever devised by man -- but why being better at the language/typesystem level, without offering a new paradigm warrants switching a language in the first place. After all, it doesn't offer anything radical when it comes to concurrency (like Clojure or Erlang or Go) or functional purity/equational reasoning (like Haskell). It's just cleaner and more elegant than Java or Scala. OCaml is another such beautiful, well-designed language, but, perhaps sadly, it has hardly seen any adoption. Why do you believe that is enough to get people to switch to a new language? For example, I know that Joe Armstrong thought a lot about the problem of fault-tolerant systems, and he came up with the idea of isolating failure; Rich Hickey thought a lot about state and identity and came up with Clojure's data structures and controlled mutation. Their reasoning is fascinating. What is that behind Ceylon's (I can tell you the reasoning behind Kotlin)? Did you reach the conclusion that a major obstacle to building modern software at this point in time is deficiencies in the type system? I'm not mocking, and I'm not saying it isn't, but unlike in Clojure's, Erlang's, Rust's and Kotlin's case (or Haskell or Scala), I've just never seen the Ceylon philosophy explained. I've read Ceylon's guiding principles, but they haven't answered the question. If simply doing the same thing better justifies starting over, then supposing Ceylon takes off, in a few years Ceylon, too, will accumulate cruft, and its design mistakes (in the language or libraries) will become apparent. What will Ceylon advocate then? Backwards compatibility or breaking changes (or maybe a new language altogether)? And if the idea is to start over every 20 years -- I can see the merit in that argument -- why not a whole new paradigm? Is everything OK except mistakes in library design and the type system? You don't have to answer, and you can either address or ignore my views -- but please don't call them FUD.

pron 11y ago

I didn't say that Ceylon has a problem interoperating with Java's unreified generics, just that reified generics on a shared platform have their own issues. The level of interoperability, though, is radically different from Kotlin's. And yes, I have never tried Ceylon because its stated design goals -- while great -- are not what I'm looking for. If I got the design goals and philosophy wrong I'll happily give it a try. I will also reiterate that I can certainly see that other people may prefer Ceylon's design goals over Kotlin's.

gavinking 11y ago
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?
- pron 11y ago
  Happily, as long as you don't misrepresent the difference between the languages.
  - gavinking 11y ago
    Thank you, I appreciate it.
    - pron 11y ago
      Thank you!
- twic 11y ago
  > 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.
  - justthistime_ 11y ago
    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.
    - tome 11y ago
      Seconding that.
    - pron 11y ago
      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.
  - lomnakkus 11y ago
    > 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.)
UnFroMage 11y ago
> The level of interoperability, though, is radically different from Kotlin's There's no truth in that. Sure, it's possible that there are some differences in how we both do interop, and that some things are easier in one or the other, but overall you've no basis for claiming that, and I strongly suspect you haven't tried Ceylon for interop at all or you would not say that. When you do try and find interop things that we should improve, please let us know in our issue tracker and we'll do our best to fix it. Meanwhile, please stop with the FUD.
- pron 11y ago
  > Sure, it's possible that there are some differences in how we both do interop There are no "some differences", but a radically different philosophy which is at the very core of the language's design. A Kotlin list is a Java list and vice-versa; a Kotlin map is a Java map and vice-versa; a Kotlin set is a Java set and vice-versa. The same, BTW, is true for Clojure, but unlike Clojure, Kotlin doesn't just keep the interfaces, but also the implementations. Kotlin hardly even has a standard library. The Java standard libraries are Kotlin's standard libraries (modulo some extension methods). Ceylon has its own standard libraries, and, in general, Java libraries are not idiomatic Ceylon libraries. That Ceylon even has CeylonList/JavaList types shows how the two approaches are worlds apart. Comparing it to Kotlin in that regard is ridiculous, and I don't even know why you'd try. It is one of Ceylon's strengths that it has its own library, and one of Kotlin's that it doesn't. Each appeals to different needs, and I don't see why you feel you should blur the differences. > When you do try and find interop things that we should improve It's not about that. You may think that Ceylon's Java interop is great. It may be just the right amount of interoperability that you want. But claiming it is anywhere near Kotlin's is just preposterous. I didn't say that Ceylon's Java interop is bad, but it's just not even in the same ballpark as Koltin's. But that's OK, because the two languages have different philosophies. > Meanwhile, please stop with the FUD. Please stop calling it FUD. I have never, ever said people shouldn't use Ceylon, that it's a bad language or even that Kotlin is better. I have emphasized the big difference in design goals between the two languages that makes them very different in practice: Ceylon has an advanced, very elegant, beautiful type system, while Kotlin has many thousands of libraries. Where is the FUD? OTOH, instead of calling it FUD, and since this is a Ceylon thread, I would very much like to hear a justification for Ceylon's design; not the choices of the particular language features -- I will readily admit that Ceylon is the best language ever devised by man -- but why being better at the language/typesystem level, without offering a new paradigm warrants switching a language in the first place. After all, it doesn't offer anything radical when it comes to concurrency (like Clojure or Erlang or Go) or functional purity/equational reasoning (like Haskell). It's just cleaner and more elegant than Java or Scala. OCaml is another such beautiful, well-designed language, but, perhaps sadly, it has hardly seen any adoption. Why do you believe that is enough to get people to switch to a new language? For example, I know that Joe Armstrong thought a lot about the problem of fault-tolerant systems, and he came up with the idea of isolating failure; Rich Hickey thought a lot about state and identity and came up with Clojure's data structures and controlled mutation. Their reasoning is fascinating. What is that behind Ceylon's (I can tell you the reasoning behind Kotlin)? Did you reach the conclusion that a major obstacle to building modern software at this point in time is deficiencies in the type system? I'm not mocking, and I'm not saying it isn't, but unlike in Clojure's, Erlang's, Rust's and Kotlin's case (or Haskell or Scala), I've just never seen the Ceylon philosophy explained. I've read Ceylon's guiding principles, but they haven't answered the question. If simply doing the same thing better justifies starting over, then supposing Ceylon takes off, in a few years Ceylon, too, will accumulate cruft, and its design mistakes (in the language or libraries) will become apparent. What will Ceylon advocate then? Backwards compatibility or breaking changes (or maybe a new language altogether)? And if the idea is to start over every 20 years -- I can see the merit in that argument -- why not a whole new paradigm? Is everything OK except mistakes in library design and the type system? You don't have to answer, and you can either address or ignore my views -- but please don't call them FUD.