7 ms·

This was very interesting to read. > So if you're truly serious about JavaScript VMs or the Dart VM or whatever as a real target platform for your language, yo

by hrjet 12y ago

This was very interesting to read. > So if you're truly serious about JavaScript VMs or the Dart VM or whatever as a real target platform for your language, you need to design your language and language module for that. Would it be fair to say that Ceylon's design is heavily guided by the needs and constraints of Javascript in addition to Java interoperability? I am concerned that those of us who only care about pure JVM projects will be carrying the extra burden imposed by Javascript.

gavinking 12y ago
I would say that Ceylon is heavily guided by the constraints of wanting to always do The Right And Elegant Thing, and not unduly compromise on that in light of the nature of the underlying VM. _Which_ VM doesn't quite enter into that question. We're not crazy about this; of course compromises are necessary; hell, we just added use-site variance to the language purely to make Java interop better. So to clarify: ceylon.language and ceylon.collection are designed the way they are because they're like way better and cleaner than java.lang and java.util. Not because they represent a "compromise" with JavaScript. Likewise, the main reason that Ceylon only has 3 numeric types (Integer,Float, and Byte) is because that seems to me the Right Thing from the point of view of the goals of the Ceylon type system. It just so happens that this is also the right thing if you want cross-platform execution. Hope that answers the question.
gavinking 12y ago
As a further clarification, when I said: "there are a bunch of operations that I would love to add to ceylon.language, but can't, because they are simply unimplementable in JS", I don't mean that those operations aren't available. Just that they're exiled to a different module. As a further sort of clarification: we're Java developers, not JavaScript guys. We recognize the importance of the JavaScript VM. But Java is where our hearts are at ;-)

by hrjet 12y ago

gavinking 12y ago

I would say that Ceylon is heavily guided by the constraints of wanting to always do The Right And Elegant Thing, and not unduly compromise on that in light of the nature of the underlying VM. _Which_ VM doesn't quite enter into that question. We're not crazy about this; of course compromises are necessary; hell, we just added use-site variance to the language purely to make Java interop better. So to clarify: ceylon.language and ceylon.collection are designed the way they are because they're like way better and cleaner than java.lang and java.util. Not because they represent a "compromise" with JavaScript. Likewise, the main reason that Ceylon only has 3 numeric types (Integer,Float, and Byte) is because that seems to me the Right Thing from the point of view of the goals of the Ceylon type system. It just so happens that this is also the right thing if you want cross-platform execution. Hope that answers the question.

gavinking 12y ago

As a further clarification, when I said: "there are a bunch of operations that I would love to add to ceylon.language, but can't, because they are simply unimplementable in JS", I don't mean that those operations aren't available. Just that they're exiled to a different module. As a further sort of clarification: we're Java developers, not JavaScript guys. We recognize the importance of the JavaScript VM. But Java is where our hearts are at ;-)