Live data from Hacker News

Why you might want to choose Ceylon

ceylon-lang.org

1–10 of 148 posts

Re: Why you might want to choose Ceylon

#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 might need a pile of bodges to offer these things - Shapeless implicit macros to use tuples generically, type-level libraries abusing the implicit resolution rules to implement unions, a retrofitted JavaScript backend. But that stuff has been written now, and as a developer it works - maybe with a couple of ugly extra lines here and there, but that's all.

I'm glad it exists, but I just can't see people choosing the more polished language over the one with ten years worth of library and tool support when there's no USP beyond that polish.

Re: Why you might want to choose Ceylon

#3
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…

I agree somewhat.

One feature of Ceylon that caught my attention however is that Ceylon modules are implicitly OSGi modules. If you are building a microservices-type JVM application based on OSGi, Ceylon could make this a lot easier.

Re: Why you might want to choose Ceylon

#4
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…

Fully agree.

I dabble with whatever new languages come out as any other language geek, but at work it only matters the languages validated by the IT department or requested by the customer.

So, like many, I only work with languages blessed as first class languages in vendor SDKs.

With Scala and Clojure barely being adopted by most Java shops (in perpetual terms), I don't see where Ceylon might fit in without a story to sell.

Re: Why you might want to choose Ceylon

#5
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…

> Have they tightened up the floating point semantics? Or do you still get different rounding behaviour on the JVM, dart and JS?

Doing so ought to be trivial if they haven't. Java has a mode where it uses doubles everywhere. JavaScript has Math.fround() for single-precision arithmetic.

Re: Why you might want to choose Ceylon

#6
I looked for example projects in Ceylon with step-by-step info on how to setup/deploy:

* Hello World web application

* Simple online store implementation (authN, database access via ORM layer, logging)

* Todo MVC implementation

* RESTful/XML/SOAP web services

* RESTful/XML/SOAP clients

* Examples for writing AngularJS and React front-ends with Ceylon back-end services, with info on how to host such as to minimize and cache assets and server-side query caching and either side-loading or multi-table joined/extended data structures, updating and reading/accessing those data structures partially.

* Examples for easily timestamping and userstamping models

* Examples for using testing frameworks: unit, integration, (web) acceptance

Here's what I found in looking for that:

* This hello world: http://ceylon-lang.org/documentation/tour/basics/

* No Ceylon JS example at http://todomvc.com/ but this Todo list: https://github.com/vietj/cayla-mvvm/blob/master/source/io/ca...

* Two examples in what I assume is the official examples git repo at: https://github.com/ceylon/ceylon-examples containing N-queens and Game of Life only.

Also, I'd want to see benchmarks. Show me how much it is "like" performance of equivalent Java, Dart, and JS as is claimed by comparing to maybe a Play Framework app, the Dart example client-server https://www.dartlang.org/server/google-cloud-platform/app-en... , and a simple MEAN stack and/or full-stack example using ReactJS.

In addition to those examples, I'd want to see a larger community behind it with a variety of projects, e.g. specialized ORM, larger web app/services framework, simple web app/service framework each that have their own communities using it.

I think it is cool, but I don't think it is even in the same ballpark with solutions/combinations like Play+Scala, MEAN, Rails, Elixir+Phoenix, etc. for wide application in web/services.

Re: Why you might want to choose Ceylon

#7

I looked for example projects in Ceylon with step-by-step info on how to setup/deploy: * Hello World web application * Simple online store implementation (authN, database access via ORM layer, logging) * Todo MVC implementation * RESTful/XML/SOAP web services * RESTful/XML/SOAP clients * Examples for writing AngularJS and React front-ends with Ceylon back-end services, with info on how to host such as to minimize and…

Here are some other articles with examples I recently wrote on Ceylon:

- http://taiar.github.io/log/2015/10/09/ceylon-programming-lan...

- http://taiar.github.io/log/2015/10/23/ceylon-programming-lan...

Basic toy stuff but has some points on Java interoperability and explores other language aspects.

Re: Why you might want to choose Ceylon

#8
post #3
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…

I agree somewhat. One feature of Ceylon that caught my attention however is that Ceylon modules are implicitly OSGi modules. If you are building a microservices-type JVM application based on OSGi, Ceylon could make this a lot easier.

Agreed! Ceylon modularity is awesome!

Re: Why you might want to choose Ceylon

#9
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…

I think it's part of a general trend of language designers (and even language fans) not understanding what makes languages work in practice. For academic languages this may not matter, but if you actually want your language to be used, you need to pay attention. A recent study[1] has shown that "extrinsic" factors (performance, tooling, familiarity, libraries) matter a lot more than intrinsic factors (syntax, abstractions) when it comes to adopting programming languages. A language that understood this beautifully was Java[2] (and, I believe, Go, which is very much in the spirit of the Java philosophy), that analyzed existing "advanced" languages like Scheme, Self and Modula (and indeed some of the people involved with those languages were among Java's early designers) and realized that the features that give those languages most bang-for-the-buck weren't clever abstractions but extra-linguistic features such as GC, dynamic linking and JITs[3], that can be packaged in a crude, "blue-collar" language that's familiar (and familiarity is indeed among the top factors in choosing a language, while "correctness" -- as in more powerful type system -- and particular language features are among the last). James Gosling called it a wolf in sheep's clothing. A wolf in wolf's clothing may look more fierce, and the sheep's clothing may indeed limit its maneuverability a bit, but it can still be almost as wolfish, yet much more palatable.

OTOH, Kotlin took whatever it could from Ceylon (the nullability types, flow-sensitive typing) while keeping 100% seamless interoperability with Java as the top priority, so it may not be a revolution, but its adoption costs are virtually zero. It doesn't even have much of a runtime library; it was designed in such a way that all cool features could be applied to Java's standard library. The idea was that abstractions are great as long as they don't come at the expense of more important features, such as availability of libraries, tools etc (Kotlin even supports Java's annotation processors, so popular libraries that rely on compile-time verification/code-generation such as Dagger can work on Kotlin code).

Of course, I take this much further than you and believe, unlike you, that the contribution of advanced language-level abstractions is not so pronounced at all (or, at least, it hasn't been shown to be significant), and obviously I have a very different perspective on Scala than you, but at least we can agree on something :)

[1]: Paper: http://lmeyerov.github.io/projects/socioplt/papers/oopsla201... Accompanying talk: https://www.youtube.com/watch?v=v2ITaI4y7_0

[2]: https://youtu.be/Dq2WQuWVrgQ?t=14m12s about why Java was designed the way it was

[3]: Sun had experimented with a JIT for Self long before it was introduced to Java, and the plan was to make Java exploit JITs almost from the get-go.

Re: Why you might want to choose Ceylon

#10
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…

> I want to like Ceylon because it's the language Scala should be

> but I just can't see people choosing the more polished language over the one with ten years worth of library and tool support when there's no USP beyond that polish

It seems all a matter of time. What would Ceylon look like to you after some years of library and tool support?

Post reply on HN