Yes, Julia also has type aliases [1]. This is a pretty obvious feature when you have parametric types. The article feels a bit like the author has pretty limited experience with other languages besides Java prior to trying Ceylon.
Ceylon has a potentional to become the best statically typed language available. I really love the elegance combined with the pragmatic focus on readability, toolability and type-safety. Ceylon is so refreshing compared to Scala. Unfortunately it didn't get a lot of attention on HN, I'm quite curious what other people's impressions are.
Ceylon is very similar to Kotlin, but I much prefer Kotlin, mostly because it so seamlessly interoperates with Java (more so than any other JVM language I'm aware of). Also, Kotlin already has kickass IDE support.
Sequence literals, intersection types, type aliases, declaration-site variance, functions and methods? Got them.
Modules? Meh. The OSGi thing has always struck me as hideously overengineered; I've never understood what problem it's supposed to solve.
Nullable types? The trouble with doing this at the language level is that you can't then treat them as plain old objects. Can I write a method that's polymorphicly nullable? Can I write a method that polymorphicly handles "nullable" or Future or Validation, like scalaz's "sequence"?
Union types? Yeah, proper union types would be good.
> Modules? Meh. The OSGi thing has always struck me as hideously overengineered
And that's _exactly_ why you need modularity built into the ecosystem. OSGi and Maven _are_ hideously overengineered, and they're overengineered because there's no common model built into the language, toolset, and platform.
> I've never understood what problem it's supposed to solve.
Management of versioned dependencies between libraries and components developed by different teams. This is absolutely central to what software engineering is all about.
> Nullable types? The trouble with doing this at the language level is that you can't then treat them as plain old objects.
I don't think you've understood what this is. In Ceylon, null is the singleton instance of the perfectly ordinary class Null. A nullable type is just a union type of form Null|X, for any type X.
> Can I write a method that's polymorphicly nullable?
Sure. You should see the crazily cool stuff we can do with stuff like the signature of max(). You'll be impressed, I promise!
After that, check out signatures of operations like Set.union(), Set.intersection(), coalesce(), compose(), flatten(), curry(), etc, to see a bunch of other things you just can't write in Scala.
> functions and methods? Got them.
Does scala have toplevel functions? I thought they always had to be nested inside some object?
But my real big problem with Scala here is it just doesn't have proper function and tuple types that you can abstract over. Instead you have F, F1, F2, F3 ... F22 and Tuple2, Tuple3, ... Tuple22. That to me is just rubbish.
You beat me to this comment. Ceylon brings nothing new to the table that would make me jump the Scala ship.
What's the point of having Nullables if we're still forced to do glorified if(*.isNull) ... else ... checks? I'd much rather use Scala's Option type that has Map and GetOrElse already baked in.
Also, the tooling around Scala is starting to mature. The Kotlins and Ceylons of the world are way behind Scala in this regard as well.
Just wanted to say that I think union and intersection types are very interesting and powerful. Also agreed on the fact that Tuple22 and friends are not ideal. We are looking for ways to avoid that in a future version of Scala. I am certainly very interested in what you and the Ceylon community do in terms of language design and hope we can learn from each other.
Cheers, Martin, thanks for the note, I appreciate it! Well, there's already a couple of things we learned from you guys: FTR, Scala was the first place I ever saw declaration-site variance, which rocks. It's also the language that influenced me and the others to take type inference seriously. Definitely hope it's a two-way street :-)
Actually we're just talking about two different ways to represent the same concept. In the ML-derived languages, which traditionally did not have first-class union types - which I assume derives from the fact that they don't have _subtyping_, the workaround for representing A|B is to create an algebraic sum type Either which wraps the actual value we're interested in. For the case of null|B, there's a specialized Maybe or Option type.
Now, this pattern has recently been imported into object-oriented land by languages like Scala and now Java 8, because these languages also don't have first-class union types.
But in my opinion, that's the wrong path to have taken. In OO-land, we _do_ have subtyping, so things like unions and intersections are well-representable within the type system, and we don't need these workaround wrapper types.
[+] [-] quarterto|12 years ago|reply
[+] [-] dbaupp|12 years ago|reply
[+] [-] Uchikoma|12 years ago|reply
[+] [-] StefanKarpinski|12 years ago|reply
[1] http://docs.julialang.org/en/latest/manual/types/#type-alias...
[+] [-] finnw|12 years ago|reply
http://msdn.microsoft.com/en-us/library/aa664765(v=vs.71).as...
[+] [-] pepve|12 years ago|reply
[+] [-] RivieraKid|12 years ago|reply
[+] [-] pron|12 years ago|reply
[+] [-] codygman|12 years ago|reply
[+] [-] lmm|12 years ago|reply
Sequence literals, intersection types, type aliases, declaration-site variance, functions and methods? Got them.
Modules? Meh. The OSGi thing has always struck me as hideously overengineered; I've never understood what problem it's supposed to solve.
Nullable types? The trouble with doing this at the language level is that you can't then treat them as plain old objects. Can I write a method that's polymorphicly nullable? Can I write a method that polymorphicly handles "nullable" or Future or Validation, like scalaz's "sequence"?
Union types? Yeah, proper union types would be good.
[+] [-] gavinking|12 years ago|reply
And that's _exactly_ why you need modularity built into the ecosystem. OSGi and Maven _are_ hideously overengineered, and they're overengineered because there's no common model built into the language, toolset, and platform.
> I've never understood what problem it's supposed to solve.
Management of versioned dependencies between libraries and components developed by different teams. This is absolutely central to what software engineering is all about.
> Nullable types? The trouble with doing this at the language level is that you can't then treat them as plain old objects.
I don't think you've understood what this is. In Ceylon, null is the singleton instance of the perfectly ordinary class Null. A nullable type is just a union type of form Null|X, for any type X.
> Can I write a method that's polymorphicly nullable?
Sure. You should see the crazily cool stuff we can do with stuff like the signature of max(). You'll be impressed, I promise!
After that, check out signatures of operations like Set.union(), Set.intersection(), coalesce(), compose(), flatten(), curry(), etc, to see a bunch of other things you just can't write in Scala.
> functions and methods? Got them.
Does scala have toplevel functions? I thought they always had to be nested inside some object?
But my real big problem with Scala here is it just doesn't have proper function and tuple types that you can abstract over. Instead you have F, F1, F2, F3 ... F22 and Tuple2, Tuple3, ... Tuple22. That to me is just rubbish.
[+] [-] jaxytee|12 years ago|reply
What's the point of having Nullables if we're still forced to do glorified if(*.isNull) ... else ... checks? I'd much rather use Scala's Option type that has Map and GetOrElse already baked in.
Also, the tooling around Scala is starting to mature. The Kotlins and Ceylons of the world are way behind Scala in this regard as well.
[+] [-] terranstyler|12 years ago|reply
[+] [-] timclark|12 years ago|reply
[+] [-] modersky|12 years ago|reply
[+] [-] gavinking|12 years ago|reply
[+] [-] jeff303|12 years ago|reply
https://hibernate.atlassian.net/browse/HHH-1050
[+] [-] Uchikoma|12 years ago|reply
[+] [-] gavinking|12 years ago|reply
Now, this pattern has recently been imported into object-oriented land by languages like Scala and now Java 8, because these languages also don't have first-class union types.
But in my opinion, that's the wrong path to have taken. In OO-land, we _do_ have subtyping, so things like unions and intersections are well-representable within the type system, and we don't need these workaround wrapper types.
[+] [-] mhaymo|12 years ago|reply
[+] [-] kasey_junk|12 years ago|reply
[+] [-] RivieraKid|12 years ago|reply