5 ms·

Well, if you read the linked article, a number of things are mentioned, including: - union and intersection types - an elegant and powerful representation of

Well, if you read the linked article, a number of things are mentioned, including: - union and intersection types - an elegant and powerful representation of tuple and function types - reified generics - the cleanest solution to the problem of null - awesome modularity - a language module [that] completely abstracts the underlying runtime, and offers a set of elegant APIs that vastly improve on those available natively - a language specification None of which is offered by Kotlin. That's quite a lot, actually.

aembleton 11y ago
- 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/
- 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
      "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
  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/
- 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/
- 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 ;)
dlandis 11y ago
> Well, if you read the linked article, a number of things are mentioned The article was an overly verbose 2000 word wall of text.
- gavinking 11y ago
  What has happened to our culture? People are actually proud of being too lazy to read anything longer that a tweet?
  - vvanders 11y ago
    I think it's a fair complaint, it is fairly dense and as something that's supposed to encourage adoption you might want to have a quick high-level summary. On a slightly different note(and no idea if this goes against HN guidelines) but you've got a fairly argumentative tone. If you're really interested in seeing the language flourish I'd try not being as combative. Community is just as important as how well a language is designed and based on the tone of a lot of the sub-threads here I'm not really inclined to look into Ceylon any further.
    - bassislife 11y ago
      Alas, to his defense, it's slightly unnerving to read malinformed, biased critics all-thread long. I would really advise him to try and ignore most of them if he wants to keep his sanity though. (serious, been there, done that.) Especially since I think that the language looks quite promising. Sometimes, it's ok to correct things even if a little harshly though. People will always find a dumb argument anyway.
randomThoughts9 11y ago
Not the best place to mention this, but I never understood why, at least when talking with the functional oriented people, the union types are not explained as providing first level support for the Option, Either and the Try monads.
- gavinking 11y ago
  Yes, it's one good way to think about how they fit into the whole ecosystem of the language. Thanks.
- lomnakkus 11y ago
  Well, I guess it depends on what you mean by "first level" support. For example, the T|Null thing doesn't give you code composability of the type monad transformers do -- at least as far as I understand it[1]. (I'm sure there are other things, but that's the first thing that popped into my head.) FTR, I am a typed-FP weenie, but I still find Ceylon quite interesting, though I haven't done anything non-trivial in it yet. [1] I still haven't fully understood the (experimental) HKT support, so maybe that can accomodate this?
  - randomThoughts9 11y ago
    There are some places where monad composability would improve your code but in general, at least the way I see it, you can replace a scala for comprehension with a set of IF statements, each IF eliminating a wrong value (null, exception, etc). Not to mention that you can have as many options as you like (A|B|C|D|E), whereas the mentioned monads must be composed in order to capture the same thing. But it's true I never built a big ceylon project, so I can't say I know how that works out in practice.

aembleton 11y ago

- 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/

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
    "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
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/
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/
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 ;)

dlandis 11y ago

> Well, if you read the linked article, a number of things are mentioned The article was an overly verbose 2000 word wall of text.

gavinking 11y ago
What has happened to our culture? People are actually proud of being too lazy to read anything longer that a tweet?
- vvanders 11y ago
  I think it's a fair complaint, it is fairly dense and as something that's supposed to encourage adoption you might want to have a quick high-level summary. On a slightly different note(and no idea if this goes against HN guidelines) but you've got a fairly argumentative tone. If you're really interested in seeing the language flourish I'd try not being as combative. Community is just as important as how well a language is designed and based on the tone of a lot of the sub-threads here I'm not really inclined to look into Ceylon any further.
  - bassislife 11y ago
    Alas, to his defense, it's slightly unnerving to read malinformed, biased critics all-thread long. I would really advise him to try and ignore most of them if he wants to keep his sanity though. (serious, been there, done that.) Especially since I think that the language looks quite promising. Sometimes, it's ok to correct things even if a little harshly though. People will always find a dumb argument anyway.

randomThoughts9 11y ago

Not the best place to mention this, but I never understood why, at least when talking with the functional oriented people, the union types are not explained as providing first level support for the Option, Either and the Try monads.

gavinking 11y ago
Yes, it's one good way to think about how they fit into the whole ecosystem of the language. Thanks.
lomnakkus 11y ago
Well, I guess it depends on what you mean by "first level" support. For example, the T|Null thing doesn't give you code composability of the type monad transformers do -- at least as far as I understand it[1]. (I'm sure there are other things, but that's the first thing that popped into my head.) FTR, I am a typed-FP weenie, but I still find Ceylon quite interesting, though I haven't done anything non-trivial in it yet. [1] I still haven't fully understood the (experimental) HKT support, so maybe that can accomodate this?
- randomThoughts9 11y ago
  There are some places where monad composability would improve your code but in general, at least the way I see it, you can replace a scala for comprehension with a set of IF statements, each IF eliminating a wrong value (null, exception, etc). Not to mention that you can have as many options as you like (A|B|C|D|E), whereas the mentioned monads must be composed in order to capture the same thing. But it's true I never built a big ceylon project, so I can't say I know how that works out in practice.