I assume you read the same Slashdot article ^[1] I did (with linked slides).

The short answer is that Scala already does everything that Ceylon is supposed to do except

• Focus on ease of learning
• Syntactic sugar for sequences
• Syntactic sugar for strings

It also does things that Ceylon does not (yet):

• Implicit conversions
• Trivially easy closure declarations
• Higher-kinded types
• Operators are just methods; use methods or operators in infix notation
• Syntactic sugar for pattern matching, collections, and XML
• It exists
• It has an extensive functionally-inspired collections library

These features allow Scala to implement as libraries (or modifications to libraries) things that usually require changes to the language (or a new library), and allow the programmer to express powerful concepts in a compact and still relatively clear way.

(Also, note that the features of Ceylon are rather similar to those of Gosu ^[2].)

As I read through the Ceylon presentations yesterday, I was astounded by how much Scala is already providing a solution for those issues which Ceylon claims to be addressing (with respect to shortcomings of Java).

In fact, I'd say that pretty much 95% of what Ceylon appears to be trying to accomplish, can already be done with Scala. (The obvious exception being union types).

So that means that the Ceylon designers, for a 5% feature difference, have decided to design a whole new language from scratch - an astonishing decision. As Daniel mentions above, getting scala to the stage where it's at now, with good IDE support and a number of useful frameworks providing library solutions to such areas as web-development and concurrency, has taken > 5 years. 5. YEARS.

If you add-in the most obvious concerns about Ceylon as a language:

• Java interop is going to suffer (no overloading, wildcards, reified generics, no null etc)
• Lack of academic grounding & conceptual simplicity
• Lack of implicits

For the extra 5% features you are sacrificing a lot of good stuff.

And for Gavin King to claim that it is conceptually simpler than Scala is breathtaking. From everything I've read so far, it looks a lot like a wish-list of minor functionality crammed awkwardly together, whereas Scala generates its power and scope from its simplicity.

In the comments on this blog post ^[1], Gavin mentions "extra features" as being more complex. But of course that is not necessarily true! Or rather, it depends stroingly upon your definition of an "extra feature". For example, you could argue that the ability to declare a value which is a type is an extra feature and therefore represents an addition of complexity. But, conversely, you could equally argue that treating types differently to values (i.e. disallowing them as values) is adding complexity (because it represents the "addition" of a feature, namely the special treatment conferred upon types). Similarly with higher-kinded types: why should a type parameter not also be allowed a type parameter? Why is that more complex?

EDIT - on additional comment is that Gavin King explicitly criticises Java because of its lack of declarative GUI tools. He has presented nothing to suggest at exactly how Ceylon addresses these issues, so I do wonder whether he's got something up his sleeve on this one. In fact, I strongly suspect that final judgement should probably be reserved for when a working prototype is available!

I haven't read anything about Ceylon yet, so let me comment on your check points.

Scala does better:

• Type inference via the "local" keyword

  Scala's very syntax was designed to make type annotations optional everywhere; it does require type annotations on method parameters and return value of recursive methods or methods that use return to break evaluation, but if a good type inference algorithm was designed to handle that, no modification would have to be made to the language's syntax.

• Straight-forward implementation of higher-order functions

  Scala provides higher kinded type inference as well, which is very important in a functional statically typed language.

Scala has:

• The overall vision: learn from Java's mistakes, keep the good, ditch the bad

  It is worth noting that Odersky, Scala's creator, co-designed Generic Java ^[1] -- which became Java 5's generics -- and Pizza -- a language created to mix functional aspects with Java. That means Scala is not only a result of that vision, but a result of previous iterations of that vision. See more about that history here ^[2].

• Static Typing (find errors at compile time, not run time)

• No “special” types, everything is an object
• Named and Optional parameters
• No need for explicit getter/setters until you are ready for them

• Nullable types

  Actually, nullable types are Optional types, just like Scala's Option. From Gavin's blog, they are similar to Haskell's Maybe, which is also the origin of Scala's Option. From InfoQ ^[3], there no null in Ceylon. This is a big advantage for people wanting reliability in their programs, but a major drawback for interoperability. One of Scala's goal was interoperability, which is the reason it has null.

Scala intended, but many people claim it hasn't achieved:

• The focus on readability

• Ease of learning/use

  Actually, I think it does pretty well on readability, once one has actually learned the language. The learning curve starts shallow too, but gets steep further on.

Not sure:

• Sequences (arrays) and their accompanying syntactic sugariness

  One can write things like Set(1, 2, 3), Array("a", "b") or val list = a :: b :: tail. This is not because Set, Array or List are given special treatment, but just syntactic sugar Scala allows any class.

EDIT

So, I have read about it. I think the ideas behind Ceylon are good -- in fact, they are pretty close to the ideas behind Scala.

The two most striking differences between Scala and Ceylon -- in my own opinion -- is the lack of implicits, and the syntax much closer to C++ than Scala (and even Java, I think).

The absence of implicits reduces complexity a lot, which is nothing to sneer at. By the same token, it makes the language less capable. Implicits makes libraries easier to use, increase the value of static typing, and helps the creation of DSL.

I personally prefer Scala syntax over Ceylon's -- it looks cleaner to me, but Ceylon will certainly be more familiar to Java and C++ programmers.

These are two very valid design decisions. I prefer Scala's choice for both, but taste is very much an individual matter.

I didn't see them crediting any other language, which gives the impression of being a blind effort, but that may not be the case at all. The lack of a running compiler and libraries is much more concerning to me -- Scala takes hell for being "IDE poor", even though it has probably the second best IDE support in the JVM space. I shudder to think how much effort they have ahead of them.

On the other hand, Gavin "Hibernate" King is behind Ceylon, so I expect the effort to have some success, at least.

Gavin King's motivation seems to be quite transparent.

Java frameworks suck big time for contemporary applications (mostly web+db). Java syntax is just not equipped to model these things concisely and elegantly. Java frameworks are constantly accused for being hideous looking. Some really deserve it; some don't - the author has explored everything he can to make it easy to read/write, but he's eventually constrained by the Java syntax.

Gavin yearned to tweak Java just enough so that his frameworks look elegant in the modified language.

I agree with this approach. Design a language to best solve contemporary problems. Very practical.

Update after seeing Gavin's blog ^[1] ( cached here ^[2]):

[...] the number one technical problem that we simply can't solve to our satisfaction in Java [...] is the problem of defining user interfaces and structured data using a typesafe, hierarchical syntax.

[...]

But much of our frustration is not even with the Java language itself. The extremely outdated class libraries that form the Java SE SDK are riddled with problems. Developing a great SDK is a top priority of the project.

I'm not sure about the 2nd one. It's easy to accuse, for example, that Java collections don't even have readonly interfaces. But it's unclear which design is best for practical use, unless they are tested in real world applications. Sometimes stupid and retarded design outshines smart designs in practice.

In any case, good luck. The amount of work is simply astonishing if they want to fix the language AND design a new SDK (AND a lots of other things too if a modern language wants to get some legs)

Ceylon seems to be more conservative (in some ways) and more Java-like than Scala.

However, they have decided not to be fully Java-interoperable. (I currently don't know details about Ceylon <-> Java interoperability.) It looks strangely.

There are some differences: * Ceylon seems to allow to name some subexpressions. It can be useful in a declarative UI: you can do it really straightforwardly. * While Java has nulls and Scala supports them mostly for backward-compatibility reasons (but Scala has also Option), Ceylon does not have nulls in traditional sense. It sounds great until you realize that this is a problem when interoperating eith Java. * Generics: Java has simple generics with type erasure. Scala has more complex generics with type erasure, but you can bypass the type erasure by implicits and Manifest. Ceylon will have some generics (I don't know how much advanced they are.), probably with no type erasure. This will be probably another Ceylon's interoperability issue in Ceylon. In Scala, you can do this probably without any serious issue.

In fact, I like Scala and I don't have many reasons to switch to Ceylon. But there are two positives:

• It can be great for GUI. (However, the feature can be probably implemented also in Scala if it hasn't been implemented yet.)
• If it succeeds, it can help to break problems with nulls on Java platform.

It looks like they are going to ditch Swing and go with a web GUI. In this day, this might be advisable. However, I would be curious how they are going to deal with Browser dependencies. The "new SDK" might have a lot of misfeatures/bloat for dealing with various browsers. What is Ceylon's plan?