Top Ceylon language features I wish we had in Java

http://blog.jooq.org/2013/12/03/top-10-ceylon-language-features-i-wish-we-had-in-java/

by lukaseder • 13 years ago

35 86 13 years ago

blog.jooq.org

quarterto• 13 years 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• 13 years ago

As far as I can tell, that Ceylon feature is actually equivalent to `type` in Haskell, not `newtype`.

Uchikoma2• 13 years ago

And Scala as another JVM language.

yareally3• 13 years 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/

finnw• 13 years 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).as...

pepve• 13 years ago

I think that's a sarcastic stab at Java, not a real question by the author.

StefanKarpinski• 13 years 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-alias...

terranstyler2• 13 years ago

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

timclark4• 13 years ago

Would that be clojure?

terranstyler2• 13 years 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.

RivieraKid11• 13 years 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.

pron5• 13 years 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.

RivieraKid11• 13 years 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.

timclark4• 13 years ago

Kotlin is a very nice replacement for Java but I really like the ambition and thought being shown by the Ceylon development team. I sure do hope that they get an IntelliJ plugin completed sometime in the future.

lmm5• 13 years ago

I thought Kotlin didn't have existential types? Which means it won't be able to offer full compatibility with Java generic types like Scala does.

gavinking22• 13 years ago

Also, Kotlin already has kickass IDE support.

_Please_ try Ceylon IDE, and let us know where it's nonasskicking. We've worked very, very hard on it, and we think we have something really useful and usable, but of course we very much welcome feedback.

FTR, I personally pushed almost 240 klocs to this project over the past two years.

codygman3• 13 years ago

Best available is a pretty bold claim, how does it compare to the likes of Haskell in regards to static typing, type safety, and readability?

RivieraKid11• 13 years ago

I have very little experience with Haskell, I didn't really like it, it didn't seem to have strong focus on peoductivity, my view is that:

* Imperative programming is more straightforward in Ceylon.

* The same holds for functions with side-effects.

* Type safety is similar, Ceylon currently doesn't have type classes and generalized algebraic data types but will be probably added according to the FAQ.

* Ceylon is less type-inferred, which makes it more readable IMHO (1. regular syntax 2. type annotations are not just for the compiler, but for documentation too). Also - less confusing compiler errors.

* In general, Ceylon feels pragmatic, Haskell academic.

Uchikoma2• 13 years ago

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

mhaymo3• 13 years ago

I don't understand the difference, and a quick search turned up nothing. Care to educate?

timclark4• 13 years 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.

gavinking22• 13 years 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• 13 years 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

kasey_junk• 13 years ago

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

RivieraKid11• 13 years ago

Agree, imho the killer feature of Ceylon.

lmm5• 13 years 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• 13 years 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.

frowaway0016• 13 years 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.

gavinking22• 13 years ago

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.

Sorry, but Option is just not better. One advantage of using a union type is that if I have a List<String?>, I just have a List<String|Null> (which maps to a plain List<String> at the JVM level) not a whole list of wrapper objects in a List<Option<String>>.

And of course Ceylon has sufficient syntax sugar so that you can write things like:

   print(nameOrNull else "Gavin);

You definitely don't have to do an "if (exists...)" every time you encounter a null value.

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.

WDYM?! I strongly beg to differ. Have you seriously tried out Ceylon's IDE? Or are you just speculating?

gavinking22• 13 years ago

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.

barkmadley3• 13 years ago

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

From the docs:

A nonempty iterable is an iterable object which always produces at least one value. A nonempty iterabe type is written {String+}. Distingushing nonempty streams of values lets us correctly express the type of functions like max():
{Float+} oneOrMore = .... ;
{Float*} zeroOrMore = .... ;
Float maxOfOneOrMore = max(oneOrMore); //never null
Float? maxOfZeroOrMore = max(zeroOrMore); //might be null

While this is interesting, is it enforced by the compiler? i.e. is the following a runtime, or compile time error?:

    Float maxOfOneOrMore = max(zeroOrMore);

lmm5• 13 years ago

Management of versioned dependencies between libraries and components developed by different teams. This is absolutely central to what software engineering is all about.

Let me put it this way: I develop in Java (and Scala) using maven, without ever touching OSGi. What is the problem I'm supposed to be having that OSGi would be solving? Because I've never seen it.

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.

You're right, the short syntax put me off (it's something I worry about in scala too).

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.

I tried to do that, but it looks like you don't have an equivalent to javadoc/scaladoc with the standard library docs publicly available? Either that or google can't find them.

(And I'd still like to hear whether you can do something as general as scalaz's sequence. It's a function that takes F[G[A]] to G[F[A]] for any F and G with suitable typeclasses (Traverse and Applicative, IIRC), so the same function works for Set[Future] or List[Validation] or Vector[MyMonad]) - I don't think you can do that without higher kinded types. And it appears as an extension method on the F[G[A]]).

Does scala have toplevel functions? I thought they always had to be nested inside some object?

Point, but I find it hard to care. You can stick them in a package object if you really need to emulate one at toplevel.

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.

It's a bit rubbish yeah, I agree. Shapeless 2 makes it painless to treat tuples as HLists (using implicit macros - a concept which admittedly would have utterly horrified me six months ago) which means you can work around it in practice.

frowaway0016• 13 years ago

Modules? Meh. The OSGi thing has always struck me as hideously overengineered

One of the next versions of Java will ship with a module system. This will likely be good enough and not worth the hassle of having to deal with two competing module systems.

Sure. You should see the crazily cool stuff we can do with stuff like the signature of max(). You'll be impressed, I promise!

I have looked it, and maybe I'm not seeing it, but it looks like Ceylon is repeating all the things which have been wrong with Comparable in the first place. Given that Ceylon had a clean sheet to start with, I'm surprised that no better solution has been found.

The signature is intimidating and basically combines the non-extensibility of Comparable with the declaration-site boilerplate of Comparable—with none of its benefits.

- If your type was written by someone who didn't care to implement Comparable, bad luck! - If the type has a Comparable implementation which differs from what you need, bad luck, too! - You need the type to be comparable in multiple ways? Again, bad luck!

If any of this use cases came up, it would mean adding a new method which takes an Comparator to all APIs working with Comparable. Leading to more boilerplate and all the pain usually associated with defining Comparators.

Scala has things to complain about, but I think it's hard to claim that they haven't nailed this case down perfectly.

Consider:

  case class Person(firstName: String,
                    lastName: String,
                    age: Int) extends Ordered[Person] {
    def compare(that: Person): Int =
      this.lastName compare that.lastName
  }

  val persons =
    Person("Ann", "Miller", 32) :: Person("Bob", "Smith", 17) ::
    Person("Charlie", "Miller", 71) :: Nil

  val personsSortedByFirstName = persons.sorted 

  // Person doesn't implement Ordered (Comparable)
  // or we want to use a different Ordering?
  val orderByAge = Ordering.by[Person, Int](_.age)
  val personsSortedByAge = persons.sorted(orderByAge)

None of the drawbacks, all of the benefits! Additionally, the signature of the sorted method would be much simpler and more readable in Scala, too:

  def sorted[T : Ordering] = ...

Compare that to:

  shared Element[] sort<Element>({Element*} elements)
      given Element satisfies Comparable<Element> => ...

But I guess messing with Comparable as an upper bound is the best thing one can do without typeclasses. :-/

Instead you have F, F1, F2, F3 ... F22 and Tuple2, Tuple3, ... Tuple22. That to me is just rubbish.

Looking at what you did with Tuples (basically a linked list), I'm not sure that there is a large difference. Scala's approach seems to be more in line of YAGNI (if you need that 523-Tuple, you should think a bit about your data model) and performance (no pointer chasing, all values are just a method call away).

Anyway, if one wanted tuples-as-linked-lists, one could just use Shapeless' HList library, which has a few benefits over Ceylon's tuples, too, as far as I see:

  val hlist = 1 :: "str" :: 42.31 :: 'sym :: HNil
  val str: String = hlist(1) // Not possible in Ceylon, afaik

modersky• 13 years 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.

gavinking22• 13 years 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 :-)

Top Ceylon language features I wish we had in Java

Related Stories