gavinking

7 ms·

1.
by gavinking 11y ago
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
2.
by gavinking 11y ago
Yay! Folks, please feel welcome to Ask Me Anything.
3.
by gavinking 11y ago
>> 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 experienc
4.
by gavinking 11y ago
>> 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, y
5.
by gavinking 11y ago
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.
6.
by gavinking 11y ago
It's just a getter. Lots of languages have getters.
7.
by gavinking 11y ago
ceylon.locale is also shaping up to be really useful. Localization in JS is just terrible.
8.
by gavinking 11y ago
So, that's a good example: ceylon.time is implemented in pure Ceylon, and is totally cross-platform.
9.
by gavinking 11y ago
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 construc
10.
by gavinking 11y ago
Thank you, I appreciate it.
11.
by gavinking 11y ago
Yes, it's one good way to think about how they fit into the whole ecosystem of the language. Thanks.
12.
by gavinking 11y ago
Would you please open an issue here with the things you would like changed: https://github.com/ceylon/ceylon-lang.org/issues Thanks.
13.
by gavinking 11y ago
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 th
14.
by gavinking 11y ago
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 automatica
15.
by gavinking 11y ago
"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 des
16.
by gavinking 11y ago
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 Ce
17.
by gavinking 11y ago
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 o
18.
by gavinking 11y ago
"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 ze
19.
by gavinking 11y ago
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.
20.
by gavinking 11y ago
This is what a specification looks like: http://ceylon-lang.org/documentation/1.1/spec/html_single/
21.
by gavinking 11y ago
What has happened to our culture? People are actually proud of being too lazy to read anything longer that a tweet?
22.
by gavinking 11y ago
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, Ceyl
23.
by gavinking 11y ago
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.
24.
by gavinking 11y ago
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
25.
by gavinking 11y ago
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 misinterprete
26.
by gavinking 11y ago
Yeah, I think that's probably right.
27.
by gavinking 11y ago
> 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
28.
by gavinking 11y ago
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 inheri
29.
by gavinking 11y ago
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
30.
by gavinking 11y ago
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

More ›