12 ms·

- union and intersection types -- I'll have to read up on this - an elegant and powerful representation of tuple and function types -- Okay, Kotlin could do wi

- union and intersection types -- I'll have to read up on this - an elegant and powerful representation of tuple and function types -- Okay, Kotlin could do with this - reified generics -- This is apparently expensive on the JVM: http://blog.jetbrains.com/kotlin/2014/12/m10-is-out/ http://blog.jetbrains.com/kotlin/2014/12/m10-is-out/ - the cleanest solution to the problem of null -- I think saying that `String? x = "abc"` is cleaner than `var b: String? = "abc"` is subjective. -- Does Ceylon have Safe Casts? https://kotlinlang.org/docs/reference/null-safety.html https://kotlinlang.org/docs/reference/null-safety.html - awesome modularity -- Something I'll need to look into - a language module [that] completely abstracts the underlying runtime, and offers a set of elegant APIs that vastly improve on those available natively -- I guess the improvement in abstraction comes from the Reified Generics -- Have you got any examples of where the API is superior to that of the Kotlin one? For example, with Kotlin's extension functions Java File object has been extended with a readLines() function that returns all of the lines of a File as a List. I was impressed when I saw that. Underneath it is doing the usual BufferedReader and InputStream boiler plate work that you would normally write in Java. - a language specification -- https://kotlinlang.org/docs/reference/ https://kotlinlang.org/docs/reference/

lukedegruchy 11y ago
-reified generics: From what I've seen, the Ceylon guys have done a good job of implementing this and they make flow-sensitive typing possible. Without out, the benefits of union types don't fully materialize. See http://ceylon-lang.org/blog/2015/04/19/observable/ http://ceylon-lang.org/blog/2015/04/19/observable/ - problem of null: Ceylon uses union types to union between the class in question (ex String) and Null, which is a type separate from Object. Therefore, the typesystem enforces this. And yes, Ceylon has the exists operator, which means you can do if (exists stringOrNull) to instanceof/cast at the same time. - elegant APIs - With regard to file I/O: https://modules.ceylon-lang.org/modules/ceylon.io/1.1.0/doc https://modules.ceylon-lang.org/modules/ceylon.io/1.1.0/doc - language spec - Ceylon's is much more detailed: http://ceylon-lang.org/documentation/1.1/spec/html_single/ http://ceylon-lang.org/documentation/1.1/spec/html_single/
gavinking 11y ago
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
This is what a specification looks like: http://ceylon-lang.org/documentation/1.1/spec/html_single/ http://ceylon-lang.org/documentation/1.1/spec/html_single/
UnFroMage 11y ago
> - reified generics -- This is apparently expensive on the JVM: http://blog.jetbrains.com/kotlin/2014/12/m10-is-out/ http://blog.jetbrains.com/kotlin/2014/12/m10-is-out/ FTR I am not sure I believe that explanation. I was with Gavin a few years ago when Andrey Breslav asked us if we were going to implement reified generics (we had not yet at the time) because they were having trouble implementing it and so if we were not going to implement it, they would not bother. We haven't talked about this conversation publicly in the past because to be brutally honest most of it would make them look really bad, and it's likely that we won't, but this anecdote was very relevant to the discussion about reified generics. My guess is they tried and failed, strictly based on this conversation. It's possible that they really considered it too expensive, but I since that's not backed by public experiments and our own experiments tell us it's not that expensive for the benefits it gives us, I don't _have_ to believe them ;)

lukedegruchy 11y ago

-reified generics: From what I've seen, the Ceylon guys have done a good job of implementing this and they make flow-sensitive typing possible. Without out, the benefits of union types don't fully materialize. See http://ceylon-lang.org/blog/2015/04/19/observable/ http://ceylon-lang.org/blog/2015/04/19/observable/ - problem of null: Ceylon uses union types to union between the class in question (ex String) and Null, which is a type separate from Object. Therefore, the typesystem enforces this. And yes, Ceylon has the exists operator, which means you can do if (exists stringOrNull) to instanceof/cast at the same time. - elegant APIs - With regard to file I/O: https://modules.ceylon-lang.org/modules/ceylon.io/1.1.0/doc https://modules.ceylon-lang.org/modules/ceylon.io/1.1.0/doc - language spec - Ceylon's is much more detailed: http://ceylon-lang.org/documentation/1.1/spec/html_single/ http://ceylon-lang.org/documentation/1.1/spec/html_single/

gavinking 11y ago

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

This is what a specification looks like: http://ceylon-lang.org/documentation/1.1/spec/html_single/ http://ceylon-lang.org/documentation/1.1/spec/html_single/

UnFroMage 11y ago

> - reified generics -- This is apparently expensive on the JVM: http://blog.jetbrains.com/kotlin/2014/12/m10-is-out/ http://blog.jetbrains.com/kotlin/2014/12/m10-is-out/ FTR I am not sure I believe that explanation. I was with Gavin a few years ago when Andrey Breslav asked us if we were going to implement reified generics (we had not yet at the time) because they were having trouble implementing it and so if we were not going to implement it, they would not bother. We haven't talked about this conversation publicly in the past because to be brutally honest most of it would make them look really bad, and it's likely that we won't, but this anecdote was very relevant to the discussion about reified generics. My guess is they tried and failed, strictly based on this conversation. It's possible that they really considered it too expensive, but I since that's not backed by public experiments and our own experiments tell us it's not that expensive for the benefits it gives us, I don't _have_ to believe them ;)