Principles that guide this project
I've been trying to figure out how to explain what it is we're trying to achieve in the Ceylon language, and where Ceylon has a somewhat different emphasis to other similar languages. The following aren't language features as such, rather, they're principles that will guide the design of the whole platform. They're what we think are important in a language meant for writing large programs in teams.
We spend much more time reading other people's code than writing our own, so readability is the most important thing in a language meant for teams. A programming language is partly for communication between humans. Verbosity can sometimes contribute to readability, and it can sometimes harm it. Neither verbosity nor brevity is a goal in and of itself. What matters is striking a balance that makes difficult code understandable. The value of readability increases as the size of a team increases.
The programmer should be able to reproduce the reasoning of the compiler according to intuitive rules. Errors produced by the compiler should be understandable to the programmer, and they should ideally identify the true cause of the problem. Therefore, given the complexity of today's modern statically-typed languages, it's important to fight really hard to keep the number of special cases, corner cases, and interactions between intersecting features under control. Too many corner causes result in more bugs and, just as bad or worse, more "perceived" bugs, from the perspective of the user. Predictability sometimes means sacrificing potentially useful features that exhibit unintuitive behavior in the context of the rest of the language.
Most programmers are much more productive with the help of an IDE, especially when working with libraries or frameworks. And so anything that makes code more difficult for tools to understand (dynamic typing, XML, template technologies that mix multiple languages in a single file, etc) makes us dramatically less productive. A statically typed language is a language designed for tools. (From this point of view, a command-line compiler is just an IDE with a very primitive user interface.) The value of tooling increases as the size of a program and its dependencies increases.
If modularity isn't built into the language and its toolset, you wind up with a mess of competing module systems that don't work together properly and that naturally grow into overcomplex monsters because they can't depend upon a simple uniform model. Modularity is also a critical concern for client-side computing, where a bloated SDK has a direct negative impact on usability. The value of modularity increases as a software ecosystem grows.
Metaprogramming is the ability to write code that operates upon other code. It's the foundation of sophisticated frameworks and libraries. Undisciplined metaprogramming can be harmful, so ideally a language would expose facilities for metaprogramming in a disciplined, typesafe way.
Obviously, these aren't the only criteria we take into account when we design functionality for Ceylon, but they are things we're trying to especially emphasize. Of course, there's a further overriding value that's more important than any of these: Ceylon should be a language that makes it easy to get real work done.