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

111–120 of 148 posts

Re: Why you might want to choose Ceylon

#111

Post by pron »

twic wrote: post #83
gavinking wrote: post #58

Earlier quoted context omitted.

Now you're just lying. You said: "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)." And the context of the comment was quite clearly Ceylon interoperating with Java as anyone can verify. I have a friendly request for you: please don't comment about Ceylon on any more hackernews or reddit threads. It's great t…

> I have a friendly request for you: please don't comment about Ceylon on any more hackernews or reddit threads. This is really unproductive. Reddit and HN are discussion forums; what we want on them is more discussion, not less. We want high-quality, accurate, discussion, but if we're not getting that, the solution is to raise the quality, not reduce the volume. In particular, the last thing i, as a reader of discus…

Assume you have language with a generic type List, and an instance, v, of the type List. Can you then pass that value to a method expecting a List (assuming Number is a supertype of Integer)? Well, that depends on the variance rules of the language and the runtime. On the JVM, any type is checked both at compile time and at runtime. Erased generics, though, mean that the runtime type of v is just List, while reified generics mean that its List. When a type is reified -- namely, its full type information is available at runtime -- the runtime needs to know the relationship between any two types: does one extend the other or are the unrelated? But with generics and variance, there is no "best way" to do variance and different languages may choose different variance models. Because the runtime has to know what is the relationship between any two types, the v variable has to know, at runtime, whether it is also an instance of List or not. This means that the same generic classes cannot be shared among different languages with reified generics, if they have different variance rules, because the language's decision is baked into the compiled class. That's what I meant in my comment. Languages on a JVM shouldn't have reified generics because then they may not play well with others.

With Ceylon, the issue is different, because the JVM -- unlike the CLR -- doesn't have a standard way of specifying reified generics (and that's a good thing, IMO, because of the "baked-in variance problem"). However, that means that none of the standard Java generic classes are first-class citizens in Ceylon world, because they don't have the reified runtime type information. This isn't a problem for Ceylon because one of its stated goals (it says so right on their website) is to replace the Java standard libraries, so this incongruence doesn't even matter to them because a Ceylon List and a Java List are not even the same type to begin with. That a Java list instance does not have a reified generic type in Ceylon is, therefore, not a problem for them, because Ceylon didn't set out to make the existing classes first-class citizens of its brand-new ecosystem.

This is why I and the Ceylon guys have this misunderstanding. They think I'm saying Ceylon has a problem, but I'm not. Ceylon has certain core design goals that may be what some people want but not others, that is all. But those design decisions do have ramifications.

BTW, the "baked-in variance" problem will not get introduced into the JVM with the addition of specialized generics for value types in Java 10, because value types can't extend other types, and so a List can't also be a list of any supertype (or subtype).

Re: Why you might want to choose Ceylon

#112

Post by pron »

UnFroMage wrote: post #93
pron wrote: post #84

Earlier quoted context omitted.

> Sure, it's possible that there are some differences in how we both do interop There are no "some differences", but a radically different philosophy which is at the very core of the language's design. A Kotlin list is a Java list and vice-versa; a Kotlin map is a Java map and vice-versa; a Kotlin set is a Java set and vice-versa. The same, BTW, is true for Clojure, but unlike Clojure, Kotlin doesn't just keep the in…

> But claiming it is anywhere near Kotlin's is just preposterous. The only example you give is that they don't have their own standard library. I agree it's a difference, but you really think that makes it worlds apart? I mean, in Ceylon you can also use the JDK, so I don't quite see the big thing, but even then, OK that's one difference (and it's a justified one too, but fine, OK). That's really the thing that makes…

> I agree it's a difference, but you really think that makes it worlds apart?

Yes. Well, it's one of the symptoms. Let me explain, but instead of using my own words, let me quote Ceylon's website:

Ceylon is a new programming language that's deeply influenced by Java, designed by people who are unapologetic fans of Java... But much of our frustration is not even with the Java language itself. The extremely outdated class libraries that form the Java SE SDK are riddled with problems. Developing a great SDK is a top priority of the project... Java interoperability is a major priority for the project. However, since Ceylon will be based on its own modular SDK, making a clean break from the legacy Java SDK, Ceylon will require new frameworks designed especially for Ceylon.

In one of the comments, Gavin King, Ceylon's chief designer, explains what differentiates Ceylon from other attempts:

What's going to be very challenging is the _platform_: the libraries and frameworks. This is where most of the potential value of this project resides, but it's where we have relatively more work to do than other projects which simply aim to leverage the Java SDK "as is".

So (my words now), Ceylon is a new language with a new ecosystem. It is a greenfield project that also can interoperate with "legacy" Java libraries. Kotlin is fundamentally different, as Gavin Kind correctly notes. It's decided from the get go that the Java ecosystem is the Kotlin ecosystem. That any Java library is an idiomatic Kotlin library and will be treated the same way as if it were written in Kotlin (that goal has not been achieved 100%, but certainly 95%). That meant that any language feature that would have made the Java ecosystem different from the Kotlin ecosystem was intentionally left out. For Ceylon, the goal was different. A new better language and a new better SDK. When interoperability was concerned, wrapper types were introduced and sometimes language features (that are not recommended for Ceylon code) like use-site variance, too. That is a completely different perspective with major implications. Kotlin really does have many thousands of Koltin libraries; Ceylon doesn't. OTOH, Ceylon is a more comprehensively designed language with less compromises.

I can speak from experience. I'm the author of several Java libraries. Some of them have hundreds of API classes and thousands of methods. Making those libraries "Kotlin idiomatic" was zero effort, and adding all the necessary "Kotlin bling" (e.g. cool use of inline functions which are Kotlin's poor-man's macros) took a couple hundred lines of code, none of which were really necessary. Clojure, BTW, is similar, but less ambitious in that regard. As all Clojure collections are Java collections and vice-versa, Rich Hickey specifically said that Java libraries should not be wrapped, as many can be used as-is, simply passing in and getting out plain Clojure types. Ceylon is different. If I have a library working with Java collections (which is pretty much all of them), any use by Ceylon code would feel foreign and may require wrapping or other special handling. But that is by design. It says so right there on the Ceylon website. How can any of that be FUD?

> There. Right there ;)

I see. Then consider changing the Ceylon website because it's just full of FUD about replacing the ecosystem. I might be guilty of spreading it, but I'm not the source.

Re: Why you might want to choose Ceylon

#113

Post by pron »

lmm wrote: post #99
pron wrote: post #9

Earlier quoted context omitted.

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, abstrac…

Heh, I was wondering when you'd show up :) The study sounds interesting, though there are obvious risks to trusting self-reports, but I think you're taking a broader meaning of "familiarity" than they're using - I read the result as "programmers are likely to use a language that they know when starting a project" and I don't think you can generalize to "programmers are more likely to use a new language that's similar…

You won't find much argument from me here, but I think I need to clarify my point. I'm not saying that blue-collar is "better" or even has better chances for adoption[1] (though I believe it does), but that when you decide to go non-blue-collar, how exactly do you do that? For example, you mention "deemphasising consistency or underlying coherence" as a bad thing. But how bad is it? We know memory safety is important. Do we know sound type systems are important to the same extent? My important meta-point was that when designing a new language for the industry, you should at least do so to solve a problem that you believe (preferably with empirical evidence) causes real pain in the real world. That's how Java, Erlang, Clojure, Rust and even Kotlin were designed (Kotlin is different because it's decided to solve a less-painful problem but for much less cost, but the same thinking is there). Are crude type systems a real problem? I don't know, but I certainly have never seen any evidence to suggest that is the case. So if you set out on this path, at least conduct a survey or research (or even your own rich experience) to convince yourself that your solving a major problem. Why? Because unlike many other tools, new languages are very expensive to adopt. The higher the cost -- the bigger the benefit you must provide.

Having said that, as you correctly note there are other paths to adoption, such as being the only language on a popular platform (JavaScript, Objective-C, Swift), or being a scripting language. Those seem to have their own rules.

[1] Although Java wasn't more marketed than other heavily-marketed alternatives at the time, and Python and JavaScript both have their own peculiar adoption stories, with JavaScript still trying to look similar to its "sister-language" Java, and then being the only choice on a popular platform, and Python taking a long time for decent adoption that even today is far from C/Java/C# levels of popularity, and either case being, or at least starting out as scripting languages for small programs -- not as languages for "serious" systems.

Re: Why you might want to choose Ceylon

#114

Post by gavinking »

pron wrote: post #111
twic wrote: post #83

Earlier quoted context omitted.

> I have a friendly request for you: please don't comment about Ceylon on any more hackernews or reddit threads. This is really unproductive. Reddit and HN are discussion forums; what we want on them is more discussion, not less. We want high-quality, accurate, discussion, but if we're not getting that, the solution is to raise the quality, not reduce the volume. In particular, the last thing i, as a reader of discus…

Assume you have language with a generic type List , and an instance, v, of the type List . Can you then pass that value to a method expecting a List (assuming Number is a supertype of Integer)? Well, that depends on the variance rules of the language and the runtime. On the JVM, any type is checked both at compile time and at runtime. Erased generics, though, mean that the runtime type of v is just List, while reifie…

>> none of the standard Java generic classes are first-class citizens in Ceylon world, because they don't have the reified runtime type information This is just not true. In Ceylon when you import a Java generic class, you can do everything with it that you can do with the same class in Java.

Please stop posting incorrect things about Ceylon. You're coming off as a walking, ranting, personification of the Dunning-Kruger effect.

Re: Why you might want to choose Ceylon

#115

Post by gavinking »

pron wrote: post #112
UnFroMage wrote: post #93

Earlier quoted context omitted.

> But claiming it is anywhere near Kotlin's is just preposterous. The only example you give is that they don't have their own standard library. I agree it's a difference, but you really think that makes it worlds apart? I mean, in Ceylon you can also use the JDK, so I don't quite see the big thing, but even then, OK that's one difference (and it's a justified one too, but fine, OK). That's really the thing that makes…

> I agree it's a difference, but you really think that makes it worlds apart? Yes. Well, it's one of the symptoms. Let me explain, but instead of using my own words, let me quote Ceylon's website: Ceylon is a new programming language that's deeply influenced by Java, designed by people who are unapologetic fans of Java... But much of our frustration is not even with the Java language itself. The extremely outdated cl…

>> Then consider changing the Ceylon website because it's just full of FUD about replacing the ecosystem

It is not. You're a fabulist. Your behavior on this thread is worse than obnoxious.

>> I can speak from experience. I'm the author of several Java libraries. Some of them have hundreds of API classes and thousands of methods.

You can use them in Ceylon with no problems at all.

Please stop lying about Ceylon and please stop putting words in our mouths. Thanks.

Re: Why you might want to choose Ceylon

#116

Post by mike_hearn »

gavinking wrote: post #44
mike_hearn wrote: post #40

Earlier quoted context omitted.

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

Well the thing is that Ceylon offers fantastically smooth interop with both Java and JavaScript. That's one of it's main selling features for most people.

Right, but by "interop" I didn't just mean the ability to call into Java code and vice-versa, although I admit that's the traditional definition. Scala can do that too.

What I meant is, Kotlin raised the bar in the interop department to new heights: it uses the same collection types, so there's no conversion between Java and some other SDK, but still manages to enhance them via compiler magic and extensions. It has an auto-converter tool so nobody has to waste time rewriting code that already works in order to use the new features. It can use annotation processors, etc.

Of course it also pays a fairly steep price to get that.

Re: Why you might want to choose Ceylon

#117

Post by pron »

gavinking wrote: post #115
pron wrote: post #112

Earlier quoted context omitted.

> I agree it's a difference, but you really think that makes it worlds apart? Yes. Well, it's one of the symptoms. Let me explain, but instead of using my own words, let me quote Ceylon's website: Ceylon is a new programming language that's deeply influenced by Java, designed by people who are unapologetic fans of Java... But much of our frustration is not even with the Java language itself. The extremely outdated cl…

>> Then consider changing the Ceylon website because it's just full of FUD about replacing the ecosystem It is not. You're a fabulist. Your behavior on this thread is worse than obnoxious. >> I can speak from experience. I'm the author of several Java libraries. Some of them have hundreds of API classes and thousands of methods. You can use them in Ceylon with no problems at all. Please stop lying about Ceylon and pl…

Dude, I am quoting verbatim from your website. I have never said that you can't use Java libraries in Ceylon. I have said it is Ceylon's goal to replace Java's libraries, and that is lifted from your website. In fact, I don't even know why you're arguing, as you have not mentioned even a single point where you disagree with what I've said, yet you keep calling me a liar and a fabulist for some reason (for the record, I'm not). For all I know, we're in perfect agreement. What is it that I'm supposedly lying about? Have I misquoted Ceylon's stated design goals? Have I said that Ceylon's Java interop is bad? Ceylon's Java interop is radically different from Kotlin's because it was designed that way! You have clearly said that unlike other projects that want to work with the JDK as-is (Kotlin is one), Ceylon seeks to replace the libraries. You view that decision as a strength and place it high on the Ceylon FAQ, while Kotlin views the opposite decision as a strength. Both are fine, but the difference should be noted. It is you who is putting words in my mouth and insisting on arguing even though I don't even know what about. So unless you're willing to actually state what it is that you disagree with, please stop calling me a liar, thanks.

Re: Why you might want to choose Ceylon

#118

Post by pron »

gavinking wrote: post #114
pron wrote: post #111

Earlier quoted context omitted.

Assume you have language with a generic type List , and an instance, v, of the type List . Can you then pass that value to a method expecting a List (assuming Number is a supertype of Integer)? Well, that depends on the variance rules of the language and the runtime. On the JVM, any type is checked both at compile time and at runtime. Erased generics, though, mean that the runtime type of v is just List, while reifie…

>> none of the standard Java generic classes are first-class citizens in Ceylon world, because they don't have the reified runtime type information This is just not true. In Ceylon when you import a Java generic class, you can do everything with it that you can do with the same class in Java. Please stop posting incorrect things about Ceylon. You're coming off as a walking, ranting, personification of the Dunning-Kru…

> you can do everything with it that you can do with the same class in Java

Of course! I have not said otherwise. I have said that you can't do with them everything you can do with Ceylon classes, hence -- not first-class citizens.

Now, I would appreciate you stop calling me names, because I haven't called you names. On the other hand, you have not addressed even a single one of the main points I've raised, except come back with great fury against some statements I've made that may not have been clear. So I would also appreciate you taking the time to understand what it is that I'm saying rather than what it is you think I'm saying, because I have not said a single bad thing about Ceylon in this entire thread (on the other hand, I have paid it and you several compliments because it really is a beautiful language), except that I believe a more compromising approach to language design would prove the more pragmatic one in the long term. Please try to understand what it is that I'm saying before blowing a fuse. We are in total agreement (on the facts, at least).

I joined this discussion to sound an observation about different design philosophies in language design (in rare agreement with a comment by Imm), then I commented to a user who asked about the differences between Ceylon and Kotlin (answer: different design goals), and you just keep calling names left and right and think I'm out to spread FUD or that I have an animosity against Ceylon. Jeez. So I will say it -- again -- just so there's no misunderstanding: Ceylon is a terrific programming language, and anyone whose goals are aligned with the language's goals should definitely give it a try!

If you think I have posted something that is incorrect or can be misunderstood, please add your correction politely. Why politely? Because you just might have misinterpreted my intentions or my words, and by being polite you might avoid saying things you may regret. Even if you really think that I'm trying to hurt your language or just so stupid that I keep making the same mistakes over and over, still keep a polite tone, because other readers of the discussion may not have the same interpretation as you.

Re: Why you might want to choose Ceylon

#119

Post by incepted »

pron wrote: post #118
gavinking wrote: post #114

Earlier quoted context omitted.

>> none of the standard Java generic classes are first-class citizens in Ceylon world, because they don't have the reified runtime type information This is just not true. In Ceylon when you import a Java generic class, you can do everything with it that you can do with the same class in Java. Please stop posting incorrect things about Ceylon. You're coming off as a walking, ranting, personification of the Dunning-Kru…

> you can do everything with it that you can do with the same class in Java Of course! I have not said otherwise. I have said that you can't do with them everything you can do with Ceylon classes, hence -- not first-class citizens. Now, I would appreciate you stop calling me names, because I haven't called you names. On the other hand, you have not addressed even a single one of the main points I've raised, except co…

> On the other hand, you have not addressed even a single one of the main points I've raised, except come back with great fury against some statements I've made that may not have been clear.

And this is why creators of languages should refrain from participating in discussions about the language they created. Especially when they post so much stuff and they seem to be the only person in the 100+ messages defending the language.

Either Ceylon stands on its own merits and other people will come to correct misconceptions about it or... there's simply not enough people who care about it.

Re: Why you might want to choose Ceylon

#120

Post by pron »

incepted wrote: post #119
pron wrote: post #118

Earlier quoted context omitted.

> you can do everything with it that you can do with the same class in Java Of course! I have not said otherwise. I have said that you can't do with them everything you can do with Ceylon classes, hence -- not first-class citizens. Now, I would appreciate you stop calling me names, because I haven't called you names. On the other hand, you have not addressed even a single one of the main points I've raised, except co…

> On the other hand, you have not addressed even a single one of the main points I've raised, except come back with great fury against some statements I've made that may not have been clear. And this is why creators of languages should refrain from participating in discussions about the language they created. Especially when they post so much stuff and they seem to be the only person in the 100+ messages defending th…

Well, at least in this case, gavinking's protests were utterly unnecessary because I didn't attack the language (despite his beliefs to the contrary) so there was no need to defend it. I just wanted to clarify its clearly stated, official design goals, and later (after being called lots of names) also asked why the language designers think those goals are the right ones to address, because on the face of it, they appear to be the wrong ones to me. It is, of course, a matter of pure opinion and outlook, but still, it is interesting to hear the designers' views (especially because a new language is generally something that makes a much stronger statement -- ideological, philosophical -- than most developer-facing software products. Even if gavinking thinks I have misunderstood Ceylon's treatment of generics or the quality of the Java interop, those topics were really not the core of my statements, but rather Ceylon's basic raison d'etre.
Post reply on HN