Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why you might want to choose Ceylon

ceylon-lang.org

Post reply on HN
Print view View original

31–40 of 148 posts

Re: Why you might want to choose Ceylon

#31

Post by lmm »

bad_user wrote: post #18
lmm wrote: post #2

Have they tightened up the floating point semantics? Or do you still get different rounding behaviour on the JVM, dart and JS? I want to like Ceylon because it's the language Scala should be (assuming that higher-kinded types made it in - I could never work without them). It's Scala with all the ugly parts polished away, Scala with ten years' progress in language design. But it does nothing that Scala can't. Scala mi…

A language without higher-kinded types or type-classes cannot be the language that " Scala should be ". And these aren't things that can be easily added later. And I don't think it will ever happen. And don't get me wrong, but software is about trust and I do not trust somebody like Gavin King for delivering a good language after Hibernate :) > Shapeless implicit macros to use tuples generically What can you do in Ce…

> A language without higher-kinded types or type-classes cannot be the language that "Scala should be". And these aren't things that can be easily added later. In other words I don't think it will ever happen.

I mentioned higher-kinded types; last I knew they were an experimental feature. I thought Ceylon offered some way to do "open interfaces" (the vital part of typeclasses IMO)? If not then that's definitely an issue.

> And what can you do in Ceylon about this? Or our we talking about a dream?

In Ceylon you have arity abstraction over tuples built in, so you can do HList-style operations by default. Scala will supposedly add this in Don Giovanni but in the meantime you have to use Shapeless with its implicit macros and it's slightly less nice (e.g. the error messages are less clear).

>Scala.js is reusing the Scala compiler in what happens to be the cleanest transition I've seen. Care to explain?

I think it's fair to call Scala.js "retrofitted", and I think the article is right that a language that was designed from the ground up to be JVM-independent will inevitably be better at it.

My whole point was that these are minor rough edges to Scala that aren't really that important, so I'm not sure why you're being so defensive.

Re: Why you might want to choose Ceylon

#32

Post by adrusi »

bad_user wrote: post #18
lmm wrote: post #2

Have they tightened up the floating point semantics? Or do you still get different rounding behaviour on the JVM, dart and JS? I want to like Ceylon because it's the language Scala should be (assuming that higher-kinded types made it in - I could never work without them). It's Scala with all the ugly parts polished away, Scala with ten years' progress in language design. But it does nothing that Scala can't. Scala mi…

A language without higher-kinded types or type-classes cannot be the language that " Scala should be ". And these aren't things that can be easily added later. And I don't think it will ever happen. And don't get me wrong, but software is about trust and I do not trust somebody like Gavin King for delivering a good language after Hibernate :) > Shapeless implicit macros to use tuples generically What can you do in Ce…

Scalajs is reasonably good, but it is retrofitted; it's a javascript backend for a language that wasn't specifically designed for a javascript backent. Ceylon was designed to compile to javascript. I haven't used either so I can't comment as to whether it actually makes a difference.

Re: Why you might want to choose Ceylon

#33

Post by dlandis »

gavinking wrote: post #20
aembleton wrote: post #19

It doesn't have extension functions. Since moving to Kotlin for my projects, I really enjoy the power that these provide: https://kotlinlang.org/docs/reference/extensions.html What does Ceylon give me over Kotlin?

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 native…

> Well, if you read the linked article, a number of things are mentioned

The article was an overly verbose 2000 word wall of text.

Re: Why you might want to choose Ceylon

#34

Post by bad_user »

lmm wrote: post #31
bad_user wrote: post #18

Earlier quoted context omitted.

A language without higher-kinded types or type-classes cannot be the language that " Scala should be ". And these aren't things that can be easily added later. And I don't think it will ever happen. And don't get me wrong, but software is about trust and I do not trust somebody like Gavin King for delivering a good language after Hibernate :) > Shapeless implicit macros to use tuples generically What can you do in Ce…

> A language without higher-kinded types or type-classes cannot be the language that "Scala should be". And these aren't things that can be easily added later. In other words I don't think it will ever happen. I mentioned higher-kinded types; last I knew they were an experimental feature. I thought Ceylon offered some way to do "open interfaces" (the vital part of typeclasses IMO)? If not then that's definitely an is…

Sorry, I sound defensive only because I'm in a bad mood, nothing to do with the subject at hand.

Thanks for the clarifications.

Re: Why you might want to choose Ceylon

#35

Post by gavinking »

aembleton wrote: post #28
gavinking wrote: post #20

Earlier quoted context omitted.

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 native…

- 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/ - the cleanest solution to the problem of null -- I think saying that `String? x = "abc"` is cleaner than `var b: String? = "abc"` is sub…

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!

Re: Why you might want to choose Ceylon

#36

Post by gavinking »

dlandis wrote: post #33
gavinking wrote: post #20

Earlier quoted context omitted.

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 native…

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

What has happened to our culture? People are actually proud of being too lazy to read anything longer that a tweet?

Re: Why you might want to choose Ceylon

#37

Post by gavinking »

aembleton wrote: post #28
gavinking wrote: post #20

Earlier quoted context omitted.

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 native…

- 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/ - the cleanest solution to the problem of null -- I think saying that `String? x = "abc"` is cleaner than `var b: String? = "abc"` is sub…

This is what a specification looks like:

http://ceylon-lang.org/documentation/1.1/spec/html_single/

Re: Why you might want to choose Ceylon

#38

Post by pron »

gavinking wrote: post #35
aembleton wrote: post #28

Earlier quoted context omitted.

- 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/ - the cleanest solution to the problem of null -- I think saying that `String? x = "abc"` is cleaner than `var b: String? = "abc"` is sub…

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.…

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).

Re: Why you might want to choose Ceylon

#39

Post by lukedegruchy »

aembleton wrote: post #28
gavinking wrote: post #20

Earlier quoted context omitted.

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 native…

- 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/ - the cleanest solution to the problem of null -- I think saying that `String? x = "abc"` is cleaner than `var b: String? = "abc"` is sub…

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

- 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

- language spec - Ceylon's is much more detailed: http://ceylon-lang.org/documentation/1.1/spec/html_single/

Re: Why you might want to choose Ceylon

#40

Post by mike_hearn »

aembleton wrote: post #29
logicchains wrote: post #24

Earlier quoted context omitted.

>Having IntelliJ just work is always discounted more than I think people should. To be fair, Kotlin has the advantage of being created by the company that makes IntelliJ, so it's got a big head start IDE-wise.

Yes, and that is really important when it comes to language use. The more people who use the language, the more it can develop and the more libraries that can be built for it. The other advantage of Kotlin is that it builds on top of the existing Java code base. Java has had decades to build up an ecosystem of frameworks and libraries. Kotlin builds on these with excellent interop.

I like Kotlin too but in fairness this is a Ceylon thread ;)

From what I can see, Ceylon has a blend of strengths that should make it appeal to a certain segment of the market. On one hand, it's a fresh start and has a lot of the cleanness and terseness that I like from Kotlin. On the other, Gavin is clearly very much into type systems and type theory, and Ceylon has a more complex/powerful type system than Kotlin does.

I'll admit that I'm not totally sure whether the additional complexity is worth it, but I'm very open to being persuaded.

So it seems to me like Ceylon should appeal to people who currently like Scala or Haskell and push the type systems to the limit, but really want something without historical baggage like XML literals and other oddities. And I'm sure there are plenty of programmers like that.

The real question will be interop costs. Kotlin doesn't have any and that's the main reason people can consider it in existing projects, or introduction inside large corporations. Ceylon takes a more Scala-like approach where it has its own standard library, its own collections, etc.

Post reply on HN