10 ms·

Top Ceylon language features I wish we had in Java

35 points by lukaseder 13y ago

quarterto 13y ago
7. Type aliases Is there any other programming language that ever thought of this awesome feature?? Um. To name a few: C has typedef; Go has type; Haskell has newtype.
- dbaupp 13y ago
  As far as I can tell, that Ceylon feature is actually equivalent to `type` in Haskell, not `newtype`.
- Uchikoma 13y ago
  And Scala as another JVM language.
  - yareally 13y ago
    Kotlin, Ceylon's close JVM cousin, is going to eventually add them as well. http://blog.jetbrains.com/kotlin/2012/01/the-road-ahead/ http://blog.jetbrains.com/kotlin/2012/01/the-road-ahead/
    - dodyg 13y ago
      Kotlin has changed so much that you can't really rely on that 2012 road map.
      - yareally 13y ago
        One of their developers mentioned a few months ago that type aliases were still an upcoming feature[1], though I do agree with your statement in general. [1] http://blog.jetbrains.com/kotlin/2013/08/kotlin-m6-is-here/#comment-9023 http://blog.jetbrains.com/kotlin/2013/08/kotlin-m6-is-here/#...
- finnw 13y ago
  More importantly, Java's main rival C# has an (incomplete) version of this: http://msdn.microsoft.com/en-us/library/aa664765(v=vs.71).aspx http://msdn.microsoft.com/en-us/library/aa664765(v=vs.71).as...
- pepve 13y ago
  I think that's a sarcastic stab at Java, not a real question by the author.
- StefanKarpinski 13y ago
  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. [1] http://docs.julialang.org/en/latest/manual/types/#type-aliases http://docs.julialang.org/en/latest/manual/types/#type-alias...
terranstyler 13y ago
IMO, the article lacks a comparison to the functional elephant in the JVM room.
- timclark 13y ago
  Would that be clojure?
  - terranstyler 13y ago
    Yes, just to elaborate: The improvements over Java are things addressed in (typed) clojure. I get the feeling that comparing Ceylon to Java is like comparing a 1990s car against a 1980s car. That's not to say the comparison is invalid but if (and only if) the goal is to have/make/evaluate a good car you should compare it to 2010s cars.
    - RivieraKid 13y ago
      I really enjoyed programming in Clojure, especially 4clojure.com, an amazingly fun way to learn a new language. But I think that I would be similarly productive in it (or perhaps less) than in Java even after let's say 1 year experience because of: * Worse readability (parens, less regular). That's the #1 problem of Clojure. * IDEs, including LightTable, are not even close to the usefulness of Eclipse or IDEA. * Imperative code is easier to write and more importantly more readable in Java. * Formattig code for readability is PITA. In Eclipse, I usually just press Ctrl+Shift+F to autoformat after every edit.
      - pron 13y ago
        I develop mostly in Java with quite a bit of Clojure. While my favorite IDE is NetBeans, when I work on a mixed Java/Clojure project I use IntelliJ IDEA with the Cursive[1] plugin. You can freely jump from a Clojure call to Java code, and when you rename a Java method, it refactors the Clojure code as well. [1]: http://cursiveclojure.com/ http://cursiveclojure.com/
RivieraKid 13y ago
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.
- pron 13y ago
  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.
  - RivieraKid 13y ago
    Agree that Kotlin has slightly better interoperability and IDE support (but Ceylon is interoperable with Java too and has an Eclipse-based IDE). But I like Ceylon more because: * Union and intersection types. * I find the type system cleaner and more elegant. * It's an attempt to build a whole new platform with a new SDK. Kotlin is, in a way, just a syntax skin over the Java platform. * Reified generics. Kotlin got rid of them. * I personally find Ceylon's "String str" more readable than Kotlin's "str: String". * Type-safe metaprogramming. * Comprehensions (not 100% sure Kotlin doesn't have them). * It's compilable to JS. * Slightly more regular syntax, more readable generic declarations, better web documentation, currying, spread operator, etc.
    - timclark 13y ago
      Some of the smaller decisions the Ceylon team has made also seem nicer than the Kotlin equivalent. For example I prefer the Ceylon "if(exists x) {}" to the Kotlin "if(x != null)" - even though the Ceylon is further from the Java syntax.
    - pron 13y ago
      Kotlin also compiles to JS and has typesafe Groovy-style builders. I don't like the union and intersection types, and think Kotlin being "a syntax skin over the Java platform" is its main advantage. Thing is, neither Kotlin nor Ceylon (nor Scala, IMO) add something fundamentally necessary over what's available in Java (8). They mostly provide productivity enhancements. For me, added productivity is really nice, but it doesn't justify switching a language, unless it's a 10x productivity boost (Clojure is different; it provides a whole new way of thinking and managing state and data, which is very important for concurrency - this is big). So in that case, I'd rather give Java a facelift than change to something else altogether. Kotlin is just a Java facelift. It's trivial and transparent to mix Kotlin and Java classes, even in the same package.
Uchikoma 13y ago
Minor point: Nullable types and Maybe are two completely different things, which can be used for some overlapping use cases.
- mhaymo 13y ago
  I don't understand the difference, and a quick search turned up nothing. Care to educate?
  - timclark 13y ago
    There is no major difference between a nullable type and a maybe - the big difference is between non-nullable types and maybe. If you have a maybe I in my ignorance can assign a null to it, if you have a non-nullable type the compiler will prevent me from assigning a null to it.
    - mhaymo 13y ago
      Ok, so in a default non-nullable type system, nullable types are equivalent to maybes.
      - pestaa 13y ago
        As far as I can tell, you are right, although in my view maybes are one step ahead: they form a monad. (Not saying there's anything stopping you from doing the same thing with nullables, but still they're a slightly different concept.)
- gavinking 13y ago
  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.
jeff303 13y ago
What does one do when Hibernate is “finished” and feature complete and one needs new challenges? Maybe implement this? :) https://hibernate.atlassian.net/browse/HHH-1050 https://hibernate.atlassian.net/browse/HHH-1050
kasey_junk 13y ago
Union & Intersection types are such a big deal that they alone are enough to make me want to play with Ceylon.
- RivieraKid 13y ago
  Agree, imho the killer feature of Ceylon.
lmm 13y ago
As a scala fan: 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.
- jaxytee 13y ago
  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.
  - frowaway001 13y ago
    And it's not like one is stuck with Option either. I think the ability to choose which abstraction is the best for a specific use case (Option, Either, Validation, Future, etc.) is the major benefit over languages which just bake the handling into the language. Sure, those languages could just ship with additional classes which did that, but the problem is that they wouldn't be able to use the syntax sugar which is built-in for the special case of nulls as well as other language constructs like Scala's for-comprehensions which work for all types of a certain shape, not a single, built-in special-cased item.
    - gavinking 13y ago
      Again, nullable types are not "baked into" the language. They are syntax sugar for a union type. Also, Ceylon doesn't need Either, since that is just a workaround for not having union types. Seriously, union and intersection types are _really_ fundamental notions in set/type theory, and having them as basic constructs of the language makes the language _much_ more expressive. I seriously urge you to try it out. You'll love them, I guarantee it.
modersky 13y ago
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.
- gavinking 13y ago
  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 :-)

35 points by lukaseder 13y ago

7. Type aliases Is there any other programming language that ever thought of this awesome feature?? Um. To name a few: C has typedef; Go has type; Haskell has newtype.

dbaupp 13y ago
As far as I can tell, that Ceylon feature is actually equivalent to `type` in Haskell, not `newtype`.
Uchikoma 13y ago
And Scala as another JVM language.
- yareally 13y ago
  Kotlin, Ceylon's close JVM cousin, is going to eventually add them as well. http://blog.jetbrains.com/kotlin/2012/01/the-road-ahead/ http://blog.jetbrains.com/kotlin/2012/01/the-road-ahead/
  - dodyg 13y ago
    Kotlin has changed so much that you can't really rely on that 2012 road map.
    - yareally 13y ago
      One of their developers mentioned a few months ago that type aliases were still an upcoming feature[1], though I do agree with your statement in general. [1] http://blog.jetbrains.com/kotlin/2013/08/kotlin-m6-is-here/#comment-9023 http://blog.jetbrains.com/kotlin/2013/08/kotlin-m6-is-here/#...
finnw 13y ago
More importantly, Java's main rival C# has an (incomplete) version of this: http://msdn.microsoft.com/en-us/library/aa664765(v=vs.71).aspx http://msdn.microsoft.com/en-us/library/aa664765(v=vs.71).as...
pepve 13y ago
I think that's a sarcastic stab at Java, not a real question by the author.
StefanKarpinski 13y ago
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. [1] http://docs.julialang.org/en/latest/manual/types/#type-aliases http://docs.julialang.org/en/latest/manual/types/#type-alias...

terranstyler 13y ago

IMO, the article lacks a comparison to the functional elephant in the JVM room.

timclark 13y ago
Would that be clojure?
- terranstyler 13y ago
  Yes, just to elaborate: The improvements over Java are things addressed in (typed) clojure. I get the feeling that comparing Ceylon to Java is like comparing a 1990s car against a 1980s car. That's not to say the comparison is invalid but if (and only if) the goal is to have/make/evaluate a good car you should compare it to 2010s cars.
  - RivieraKid 13y ago
    I really enjoyed programming in Clojure, especially 4clojure.com, an amazingly fun way to learn a new language. But I think that I would be similarly productive in it (or perhaps less) than in Java even after let's say 1 year experience because of: * Worse readability (parens, less regular). That's the #1 problem of Clojure. * IDEs, including LightTable, are not even close to the usefulness of Eclipse or IDEA. * Imperative code is easier to write and more importantly more readable in Java. * Formattig code for readability is PITA. In Eclipse, I usually just press Ctrl+Shift+F to autoformat after every edit.
    - pron 13y ago
      I develop mostly in Java with quite a bit of Clojure. While my favorite IDE is NetBeans, when I work on a mixed Java/Clojure project I use IntelliJ IDEA with the Cursive[1] plugin. You can freely jump from a Clojure call to Java code, and when you rename a Java method, it refactors the Clojure code as well. [1]: http://cursiveclojure.com/ http://cursiveclojure.com/

RivieraKid 13y ago

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.

pron 13y ago
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.
- RivieraKid 13y ago
  Agree that Kotlin has slightly better interoperability and IDE support (but Ceylon is interoperable with Java too and has an Eclipse-based IDE). But I like Ceylon more because: * Union and intersection types. * I find the type system cleaner and more elegant. * It's an attempt to build a whole new platform with a new SDK. Kotlin is, in a way, just a syntax skin over the Java platform. * Reified generics. Kotlin got rid of them. * I personally find Ceylon's "String str" more readable than Kotlin's "str: String". * Type-safe metaprogramming. * Comprehensions (not 100% sure Kotlin doesn't have them). * It's compilable to JS. * Slightly more regular syntax, more readable generic declarations, better web documentation, currying, spread operator, etc.
  - timclark 13y ago
    Some of the smaller decisions the Ceylon team has made also seem nicer than the Kotlin equivalent. For example I prefer the Ceylon "if(exists x) {}" to the Kotlin "if(x != null)" - even though the Ceylon is further from the Java syntax.
  - pron 13y ago
    Kotlin also compiles to JS and has typesafe Groovy-style builders. I don't like the union and intersection types, and think Kotlin being "a syntax skin over the Java platform" is its main advantage. Thing is, neither Kotlin nor Ceylon (nor Scala, IMO) add something fundamentally necessary over what's available in Java (8). They mostly provide productivity enhancements. For me, added productivity is really nice, but it doesn't justify switching a language, unless it's a 10x productivity boost (Clojure is different; it provides a whole new way of thinking and managing state and data, which is very important for concurrency - this is big). So in that case, I'd rather give Java a facelift than change to something else altogether. Kotlin is just a Java facelift. It's trivial and transparent to mix Kotlin and Java classes, even in the same package.

Uchikoma 13y ago

Minor point: Nullable types and Maybe are two completely different things, which can be used for some overlapping use cases.

mhaymo 13y ago
I don't understand the difference, and a quick search turned up nothing. Care to educate?
- timclark 13y ago
  There is no major difference between a nullable type and a maybe - the big difference is between non-nullable types and maybe. If you have a maybe I in my ignorance can assign a null to it, if you have a non-nullable type the compiler will prevent me from assigning a null to it.
  - mhaymo 13y ago
    Ok, so in a default non-nullable type system, nullable types are equivalent to maybes.
    - pestaa 13y ago
      As far as I can tell, you are right, although in my view maybes are one step ahead: they form a monad. (Not saying there's anything stopping you from doing the same thing with nullables, but still they're a slightly different concept.)
gavinking 13y ago
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.

jeff303 13y ago

What does one do when Hibernate is “finished” and feature complete and one needs new challenges? Maybe implement this? :) https://hibernate.atlassian.net/browse/HHH-1050 https://hibernate.atlassian.net/browse/HHH-1050

kasey_junk 13y ago

Union & Intersection types are such a big deal that they alone are enough to make me want to play with Ceylon.

RivieraKid 13y ago
Agree, imho the killer feature of Ceylon.

lmm 13y ago

As a scala fan: 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.

jaxytee 13y ago
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.
- frowaway001 13y ago
  And it's not like one is stuck with Option either. I think the ability to choose which abstraction is the best for a specific use case (Option, Either, Validation, Future, etc.) is the major benefit over languages which just bake the handling into the language. Sure, those languages could just ship with additional classes which did that, but the problem is that they wouldn't be able to use the syntax sugar which is built-in for the special case of nulls as well as other language constructs like Scala's for-comprehensions which work for all types of a certain shape, not a single, built-in special-cased item.
  - gavinking 13y ago
    Again, nullable types are not "baked into" the language. They are syntax sugar for a union type. Also, Ceylon doesn't need Either, since that is just a workaround for not having union types. Seriously, union and intersection types are _really_ fundamental notions in set/type theory, and having them as basic constructs of the language makes the language _much_ more expressive. I seriously urge you to try it out. You'll love them, I guarantee it.

modersky 13y ago

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.

gavinking 13y ago
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 :-)