8 ms·

For the record: - Kotlin does not have tuples, and doesn't allow abstraction over function -arity. So no, it can't to that. - Reified generics are simply not

For the record: - Kotlin does not have tuples, and doesn't allow abstraction over function -arity. So no, it can't to that. - Reified generics are simply not expensive, at least not the way Ceylon implements them. But sure, Ceylon's reified generics were implemented by Stef Epardaud who is the best programmer I've ever worked with, so I can understand if some other people find them difficult to implement efficiently. - I'm not talking about syntax. Syntax is uninteresting. I'm talking about semantics. In Ceylon, optional types are a trivial syntax sugar for a union type, not a hacked-in special case in the type system, as they are in Kotlin, and that means that I can do more with them, for example they naturally combine with union and intersection types to do useful things. - Your link to documentation for Kotlin does not include any specification for the language. Do you know what the word "specification" means in this context? Finally, I strongly recommend that you take the time to read the Ceylon documentation and inform yourself about the language. You'll find lots of really interesting ideas and information in there, and I'm certain you'll love the language!

pron 11y ago
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). Every choice in Kotlin's design has been intentional with one idea in mind -- compromise on purity in favor of interoperability (to lower the cost of adoption). So, of course you can do more at the language level with Ceylon, but Kotlin set out to do less in that arena by design. OTOH, Kotlin has several orders of magnitude more idiomatic (or very nearly idiomatic) libraries than Ceylon. There's a very clear tradeoff here, and Kotlin and Ceylon have been designed with very different underlying philosophies. The only point you can argue about is which language gets you more bang for the buck. Kotlin has intentionally chosen less bang for less buck, while Ceylon has chosen the opposite. Personally I believe that almost all language-level abstractions are relatively low-bang[1] -- or certainly have diminishing returns -- and therefore language purity should always be compromised for almost any other extra-linguistic feature (if it's a language designed for the industry rather than academia), and so I think that Kotlin has made the better decision and gives you almost as much bang for far less buck. But only time will tell, and arguing about this at this point is just a matter of personal preference. I can certainly see some people preferring the one and some the other. Another way to look at it is that Ceylon was designed to appeal to Scala people, while Kotlin was designed to appeal to Java people :) [1]: By that I mean that they're always useful for something, but in the end have a low impact on total productivity (which includes more than just writing the code).
- gavinking 11y ago
  "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)." This is simply nonsense. You made it up. There have been zero complaints about problems Ceylon has in interoperating with Java's generic types, since they simply don't exist. I can't believe you just wrote such a longwinded comment about a nonexistent problem that you imagined out of whole cloth.
  - ngrilly 11y ago
    Could you grossly explain how reified generics are implemented and how they interoperate with Java's generic types? It would be a good way to defuse pron's claim.
- gavinking 11y ago
  By the way, pron, as more general complaint, your comments about Ceylon are always very uninformed, but you state them as fact. How about you actually spend some time learning the language first before commenting any more about it here or on reddit. Because it really wastes my time and raises my stress level having to correct your - probably unintentional - FUD. It's clear that you don't know Ceylon, so please stop telling everyone else stuff that you're just guessing at. OTOH, if you want to get answers to any questions you might have you are extremely welcome to come on our Gitter channel and ask them, and I promise we're always very patient about explaining stuff there. I make that offer in complete sincerity.
  - pron 11y ago
    I don't think they are uninformed, so feel free to correct me when I'm wrong. My "long-winded" comment wasn't about generic types -- just the first, small bit -- and that bit wasn't about Ceylon's generic types, but about generic reification on a shared platform like the JVM in general, which bakes a variance model into the class. As long as you're the only one doing reification you're sort-of fine, except all those erased generic types aren't quite first-class citizens. I should have clarified that. As to the rest (and the lion-share) of my comment, I don't think it requires further clarification, and I don't see why you'd even think it's wrong. You've set out to create a new language with new, clean type semantics and a new runtime library, while Kotlin, in contrast, has had a different goal altogether. It doesn't even have its own concrete collection classes, so that's a radically different level of interoperability and a radically different design. That is the major difference between the languages rather than the list of features you've named in an answer to a question by someone else (and like I said, either approach has its proponents), so from my perspective it was you who was adding to the confusion, which I wanted to correct. The answer to the question "what is the difference between Ceylon and Kotlin?" IMO (at least when the JVM target is concerned) is that Ceylon is a completely new "greenfield" language with a new, powerful type system, new semantics and a new runtime library, while Kotlin is "a better Java", a language preserving Java's semantics and standard library while solving its pressing shortcomings and providing a more modern syntax, and made to be adopted piecemeal into Java codebases. Of course there's some overlap, too, but that's the different in philosophies in broad strokes. In terms of features, some are similar (with Kotlin adopting some of Ceylon's ideas) and some are different, but that isn't the big difference. For those reasons, BTW, while it would be very nice to have a Kotlin spec, it isn't as necessary, as most its semantics are borrowed from Java. Of course, you may well think that those linguistic features are a bigger difference than the design goals, but I will disagree (due to the reasons I laid out in my other comment), and no amount of Ceylon expertise is relevant to that disagreement.
udalov 11y ago
Could you please explain how the internal representation of null in the language's type system has any effect on the semantics of code written in that language?
- gavinking 11y ago
  Sure. So I'll give you one very over-simplistic example. Let's assume that T is an unknown type (a type parameter). You can form types like Object&T, and if T is an optional type of form S|Null, then that is reduced automatically to the type S by the typechecker. But if T is not an optional type, then it just remains T. Very useful to be able to do this kind of trick in generic code. And note that nothing here was using any special reasoning about Null: this is all just the totally generic reasoning for union types in general.
- lmm 11y ago
  Null in Ceylon is just another type, and nullable-X is just another union type, so you can use them sensibly with generics. With Kotlin if you want to write a generic method like "add two values" and have it handle nullness polymorphically then you have to think about it.

pron 11y ago

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). Every choice in Kotlin's design has been intentional with one idea in mind -- compromise on purity in favor of interoperability (to lower the cost of adoption). So, of course you can do more at the language level with Ceylon, but Kotlin set out to do less in that arena by design. OTOH, Kotlin has several orders of magnitude more idiomatic (or very nearly idiomatic) libraries than Ceylon. There's a very clear tradeoff here, and Kotlin and Ceylon have been designed with very different underlying philosophies. The only point you can argue about is which language gets you more bang for the buck. Kotlin has intentionally chosen less bang for less buck, while Ceylon has chosen the opposite. Personally I believe that almost all language-level abstractions are relatively low-bang[1] -- or certainly have diminishing returns -- and therefore language purity should always be compromised for almost any other extra-linguistic feature (if it's a language designed for the industry rather than academia), and so I think that Kotlin has made the better decision and gives you almost as much bang for far less buck. But only time will tell, and arguing about this at this point is just a matter of personal preference. I can certainly see some people preferring the one and some the other. Another way to look at it is that Ceylon was designed to appeal to Scala people, while Kotlin was designed to appeal to Java people :) [1]: By that I mean that they're always useful for something, but in the end have a low impact on total productivity (which includes more than just writing the code).

gavinking 11y ago
"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)." This is simply nonsense. You made it up. There have been zero complaints about problems Ceylon has in interoperating with Java's generic types, since they simply don't exist. I can't believe you just wrote such a longwinded comment about a nonexistent problem that you imagined out of whole cloth.
- ngrilly 11y ago
  Could you grossly explain how reified generics are implemented and how they interoperate with Java's generic types? It would be a good way to defuse pron's claim.
gavinking 11y ago
By the way, pron, as more general complaint, your comments about Ceylon are always very uninformed, but you state them as fact. How about you actually spend some time learning the language first before commenting any more about it here or on reddit. Because it really wastes my time and raises my stress level having to correct your - probably unintentional - FUD. It's clear that you don't know Ceylon, so please stop telling everyone else stuff that you're just guessing at. OTOH, if you want to get answers to any questions you might have you are extremely welcome to come on our Gitter channel and ask them, and I promise we're always very patient about explaining stuff there. I make that offer in complete sincerity.
- pron 11y ago
  I don't think they are uninformed, so feel free to correct me when I'm wrong. My "long-winded" comment wasn't about generic types -- just the first, small bit -- and that bit wasn't about Ceylon's generic types, but about generic reification on a shared platform like the JVM in general, which bakes a variance model into the class. As long as you're the only one doing reification you're sort-of fine, except all those erased generic types aren't quite first-class citizens. I should have clarified that. As to the rest (and the lion-share) of my comment, I don't think it requires further clarification, and I don't see why you'd even think it's wrong. You've set out to create a new language with new, clean type semantics and a new runtime library, while Kotlin, in contrast, has had a different goal altogether. It doesn't even have its own concrete collection classes, so that's a radically different level of interoperability and a radically different design. That is the major difference between the languages rather than the list of features you've named in an answer to a question by someone else (and like I said, either approach has its proponents), so from my perspective it was you who was adding to the confusion, which I wanted to correct. The answer to the question "what is the difference between Ceylon and Kotlin?" IMO (at least when the JVM target is concerned) is that Ceylon is a completely new "greenfield" language with a new, powerful type system, new semantics and a new runtime library, while Kotlin is "a better Java", a language preserving Java's semantics and standard library while solving its pressing shortcomings and providing a more modern syntax, and made to be adopted piecemeal into Java codebases. Of course there's some overlap, too, but that's the different in philosophies in broad strokes. In terms of features, some are similar (with Kotlin adopting some of Ceylon's ideas) and some are different, but that isn't the big difference. For those reasons, BTW, while it would be very nice to have a Kotlin spec, it isn't as necessary, as most its semantics are borrowed from Java. Of course, you may well think that those linguistic features are a bigger difference than the design goals, but I will disagree (due to the reasons I laid out in my other comment), and no amount of Ceylon expertise is relevant to that disagreement.

udalov 11y ago

Could you please explain how the internal representation of null in the language's type system has any effect on the semantics of code written in that language?

gavinking 11y ago
Sure. So I'll give you one very over-simplistic example. Let's assume that T is an unknown type (a type parameter). You can form types like Object&T, and if T is an optional type of form S|Null, then that is reduced automatically to the type S by the typechecker. But if T is not an optional type, then it just remains T. Very useful to be able to do this kind of trick in generic code. And note that nothing here was using any special reasoning about Null: this is all just the totally generic reasoning for union types in general.
lmm 11y ago
Null in Ceylon is just another type, and nullable-X is just another union type, so you can use them sensibly with generics. With Kotlin if you want to write a generic method like "add two values" and have it handle nullness polymorphically then you have to think about it.