gavinking

It seems to me that the best solution here is to split the single file into one js file for each package. A big part of that file is the implementation of the metamodel, and it's very likely that a lot of people won't even want to use that on the client side.

We've even discussed the pros and cons of actually splitting the metamodel into its own separate module, ceylon.metamodel, or whatever.

P.S. My tests with uglify-js suggest that minification probably isn't the most fruitful path here.

Yay!

Folks, please feel welcome to Ask Me Anything.

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

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

Earlier today I, in all sincerity, invited you to our Gitter channel, where there's always people discussing this stuff night and day. That invitation is still there. You're welcome any time you like.

It's just a getter. Lots of languages have getters.

ceylon.locale is also shaping up to be really useful. Localization in JS is just terrible.

So, that's a good example: ceylon.time is implemented in pure Ceylon, and is totally cross-platform.

Well where there is a big difference between the underlying capabilities of the platform, differences are unavoidable.

I mean, examples of things that are cross-platform in Ceylon: collections, localization, promises, regexes, HTML construction, logging, testing, dates/times.

Examples of things that are platform specific: I/O, database access, filesystem access, distributed transactions, the HTTP server.

That's pretty reasonable and natural, isn't it?

Thank you, I appreciate it.

Yes, it's one good way to think about how they fit into the whole ecosystem of the language. Thanks.

Would you please open an issue here with the things you would like changed:

https://github.com/ceylon/ceylon-lang.org/issues

Thanks.

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 that you like Kotlin and are having success with it. I'm happy for you. Post about how great Kotlin is on all the Kotlin threads you like.

But it's just not a good thing for anyone that you're going posting on Ceylon threads, speculating about made-up problems with Ceylon, and pretending you know Ceylon when you don't.

So please stick to the Kotlin threads is all I'm asking, OK?

Sure. So I'll give you one very over-simplistic example. Let's assume that T is an unknown type (a type parameter).

You can form types like Object&T, and if T is an optional type of form S|Null, then that is reduced automatically to the type S by the typechecker. But if T is not an optional type, then it just remains T.

Very useful to be able to do this kind of trick in generic code.

And note that nothing here was using any special reasoning about Null: this is all just the totally generic reasoning for union types in general.

"Another way to look at it is that Ceylon was designed to appeal to Scala people"

This is quite clearly not true, and yet another assertion that you just made up and stated as fact. We're Java not Scala developers, and we designed Ceylon for other people like us. Don't try to tell me what my own motivations were.

In fact, it's very difficult to imagine, even charitably, why you would possibly be motivated to make such a claim unless you were deliberately trying to spread misinformation.

Well it should be very clear, that if you believe that Ceylon has a problem interoperating with Java's unreified generics, that you don't know enough about Ceylon to be able to comment with any sort of certainty on the topic of Ceylon and Java interop.

Because you quite obviously have never even tried it once.

That's clear, isn't it?

By the way, pron, as more general complaint, your comments about Ceylon are always very uninformed, but you state them as fact.

How about you actually spend some time learning the language first before commenting any more about it here or on reddit. Because it really wastes my time and raises my stress level having to correct your - probably unintentional - FUD. It's clear that you don't know Ceylon, so please stop telling everyone else stuff that you're just guessing at.

OTOH, if you want to get answers to any questions you might have you are extremely welcome to come on our Gitter channel and ask them, and I promise we're always very patient about explaining stuff there. I make that offer in complete sincerity.

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

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.

This is what a specification looks like:

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

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

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!

Well, y'know, you could go with your gut - or you could actually try it out for yourself!

I think you'll decide your gut was wrong, but there's only one way to be sure.

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.

If you look above in this subthread you'll see the following comment:

> I think what they're saying is that it's good to give credit where credit is due.

I don't think I was conflating. Or at least, if I misinterpreted, then so did at least one other person. Which suggests that the original comments were very open to such an interpretation.

Yeah, I think that's probably right.

> I don't think it's a blind love, but all those things will ship in one of the next versions of Scala, too.

Well it's really lovely and encouraging to see Ceylon exercising such a strong influence on Scala. Makes me very proud.

What I'm trying to say is that I don't think that the total complexity or total expressiveness is ultimately much different. You trade class types + interface types for record types + named structural types. You trade class inheritance for record extension. You gain a tiny little bit of flexibility via structural typing - but in my opinion much less than is often claimed, since in all these languages so-called structural types are only partially structural - and you lose some power at the tooling level (refactorings are no longer guaranteed to work). You gain a bit of flexibility by decoupling initialization into a function, but you also gain a bit of verbosity and lose a little bit of modularity.

Ultimately it's a bit of a wash and honestly I would probably be almost as happy with OCaml or Rust or something like that as I am with Ceylon. I think both systems work well and are intellectually consistent. I don't think either is clearly superior to the other.

I never said I've never looked at Scala. I think you can tell from my responses to you in this thread that I'm in fact quite knowledgeable about Scala. What I said was that I had not looked closely at how Scala does constructors and that they were not an inspiration behind the design of constructors in Ceylon.

Whatever, your attack on me was totally uncivil and unjustified, as you now realize, which is why you're backpedalling it so furiously. You've never interacted with me before, and so coming in here with a blazing personal attack was completely unreasonable behavior. I think you see that, so let's just drop it now.

> Ceylon's approach isn't very good in terms of language complexity.

Here's another assertion for which you simply have not provided evidence. How are Ceylon's constructors more "complex" than Scala's constructors? The actual syntactic weight of both constructs is almost identical. And in terms of complexity, the factory-method-on-a-companion-class pattern is significantly more complex in terms of ceremony than doing the equivalent thing in Ceylon.

Look man, stepping back a second, I can see that you're clearly a fan of Scala and that Scala is something you love and enjoy. That's great! But Scala isn't perfect and other languages can have good ideas too. I highly recommend you spend some time learning Ceylon, since it has a bunch of awesome things in it that I know you'll love: the things we can do with union and intersection types, disjointness, abstraction over tuple and function types, etc, are just beautifully elegant and powerful. Don't let the fact that you love Scala blind you to other ideas.

You wrote:

> Much of the rest of the work seems to mirror what Scala did several years ago, and this seems to nearly replicate that.

I have already demolished this claim on this thread, as you very well understand.

I personally make it a policy to admit error when I err. It's up to you to decide whether this is also your policy, or whether you prefer goalpost-shifting and prevarication.

> No, I demanded you reference a similar language to actually compare the benefits of your changes.

I make it a firm policy to not talk about other new languages when I blog about Ceylon, because whenever I have mentioned Scala in the past, even just in passing, I have found myself the subject of quite vicious personal attacks. I'm going to continue with that policy, this thread notwithstanding. But thanks for your feedback anyway.