Ceylon - A new language running in the JVM

Hey everyone!

I recently came across Ceylon which is a new open source programming language which runs, just like java, in the JVM (Java Virtual Machine). What I want to tell you is what is so cool about it and why I think it's a good alternative for java.

Before we start, I want to say that Ceylon is still in Beta, so things might change until it's first full release. Also, I'm not an expert in Ceylon nor Java thus I might make mistakes or miss something so please bear with me.


To start off, lets first take a look at the things that both Java and Ceylon have in common. They really aren't that different when you first look at it which makes it not really hard to understand when you already know Java, however, the devil lies in the detail. Like I already mentioned, Ceylon also runs in the JVM, which makes it platform independent and thus may tie on Javas success. What you'll also notice that the syntax is similar, but not completely the same (I'll go over the differences later), curly brakes for blocks or arrays, brakets for methods and so on. Ceylon is also object-oriented so you will find classes, inheritance, polymorphism and all the other things that everyone knows and loves. It is statically typed, which can be good or bad, it's up to you. Generic types are also possible in Ceylon, however they are a bit different which I will cover later. Your will also separate your source classes in different packages just like you do in Java. There are of cause some more things but they are too small to actually cover.


Now the probably more interesting part: What's different? I will not only tell the differences objectively but also add my own opinion on certain aspects which was unnecessary when showing the similarities. Ceylon does not only run in the Java Virtual Machine, but also in JavaScript Virtual Machine which I find quit interesting but nothing I would really need. It also has a maven-like repo built in. Since I'm using maven a lot and many other people do that too, they will probably like it, as much as I do. However, people who are not familiar with this might need some time to get used to it. To further extend on this system, Ceylon applications are composed out of modules and you have to define version and name of your module inside your application. Not only do you have to declare your module, you also have to declare you packages with the twist that you can define whether or not you are allowed to access them from outside or not.

Speaking of access restrictions, Ceylons does not have as many modifiers and they are named differently are work a bit different. You know modifiers like abstract, private, final and such from Java, but there are no modifiers in Ceylon. But hold on, Ceylon doesn't lack this functionality, it does this with annotations. However, like I mentioned, not all Java modifiers have an equivalent in Ceylon. There's no protected modifier and no final. The protected principle simple does not exist in Ceylon, see here why. Yes, also no final. Members are final by default and can be made "variable" to allow change, however I think this only applies for member variables not variables inside methods but I might be wrong. You will also search for "public" without success, in Ceylon it's "shared". But there's something interesting to it. In Java when you don't put a modifier it's neither public nor private or protected. When you don't specify "shared" in Ceylon it's considered private automatically. I haven't read anything about an equivalent to Javas default modifier but I guess it doesn't exist nor do I know something about the volatile modifier.

Continuing, imports are also a bit different. In Java if you only want to import specific parts of a package, you'd need to do one import for each class. In Ceylon you can import the package and supply the classes as an array and does not require a semicolon (so

Code:

import ceylon.language { actual, array }

). In my opinion, this is way better than in Java. You can also import static functions and static values with this. This also opens up the ability for import aliases. So for example you can say that the Map class should be imported as a JavaMap or whatever (e.g.

Code:

import java.util { JavaMap = Map }

). And yes, you did see correct, you can import Java classes and use them inside Ceylon (Me like!). However, Ceylon didn't get rid of the import wildcard but it's also different. Instead of package.* it's package { ... } .

What do you do when you create a new application? Probably create a new class which shows us the next difference. You don't declare constructors but provide constructor parameters directly at the class declaration (e.g. class Test(String name, String other) { ... } ). Don't panic yet, let me explain! First, these parameters are actually class members without you needing to declare them. This makes sure you don't forget to assign a value in the constructor (Nice, however I don't like this when I for example have parameters which shouldn't be members of the class and I just need for instantiation). You can of cause still apply "modifiers" to those parameters like shared or variable. Second, the code that you might still want to execute inside a constructor can be put directly inside the class and thus get's executed when the class is instantiated (Which could let the code appear dirty in my eyes). Lastly, you might want to create different constructors with different parameters.... Well, bad news again, there's no overloading in Ceylon. But it would be shame if there isn't a different approach (And that approach I really like a lot and missed such functionality in Java). They keys are default values and variadic. What I often do is I create a method with one parameter which calls the method with two parameters which calls the method with three parameters. Every parameter that is missing will get a default value. E.g. :

Code:

public void test(int i)
{
    test(i, 1);
}
 
public void test(int i, int j)
{
    test(i, j, 1);
}
 
public void test(int i, int j, int k)
{
    ...
}

In Ceylon now you can give (for this example) j and k a default value.

Code:

shared void test(Integer i, Integer j = 1, Integer k = 1)
{
    ...
}

Which makes it way cleaner in my eyes. I also mentioned something called "variadic" what is this? In Java when you want to be able to an undefined amount of parameters with specified type you'd do "method(Type... name)" and Ceylon it's handled a bit better. You can now tell, just like in for example RegEx, if it either has to at least one or more (using "+") or zero or more ("*") parameters of that type (so

Code:

shared void method(String+ args)

or

Code:

shared void method(String* args)

). But there's one more thing, what about when you have a method with one parameter and get's overloaded with a parameter of a different type? There's something really nice in Ceylon, it's called union types. You can tell a variable to be either this OR that type, so for example a variable x can either be an Integer or a String (e.g. :

Code:

Integer|String x = ... ;

). The opposite would be intersection meaning that a value must be of type this AND that (which can only be done with interfaces) (e.g. :

Code:

List<String>&Identifyable x = ... ;

). I really missed the intersection sometimes when I was programming and I'm glad that it exists here.

As you might've noticed, I didn't used primitives in my Ceylon examples. That's because there are not primitives in Ceylon, everything is a class. This has his pros and cons so you have to decide for yourself here. When you were working with primitives you never needed to care a not initializing them because they had their default value. Well, you don't need to worry about an NPE in Ceylon! In Ceylon you have to either give the variable a value directly or have to explicitly say that this value might be null. This is in my eyes especially good for beginners but will also help keeping errors to a minimum, however, it brings a bit more complexity as you have to directly state that a variable might be null. To tell the compiler that the variable might be null, you just add a question mark at the end of the type.

Code:

String name = ""; //here it can never be null
String? name2 = null; //this might be null

In fact, null is also just an instance of the Null class so the question mark is just an abbreviation for Type|Null .

Coming back to my question what you'd start with when creating an application, you'd probably also want to create a main function. In Ceylon if would just be a plain "void run()" method.

Seme things I want to touch on as well:
You can do properties like you can in C# with their respective getter and setter. In Java you'd need to have a variable, the getter and the setter, but Ceylon combines the variable with the getter and the setter.
And Ceylon forces you to have uppercase class names, lowercase class members and methods (you can get around this though).


There are way more things like "satisfies" instead of "implements" or different handling of documentation, but this post is getting way too long if I'd include everything. If you want to know more about the specification take a look here.


I hope I covered the biggest part and I wasn't too excited about it (trust me, this language will probably be my #1 choice in the future and I was getting happier the more I read the specification until I almost couldn't keep myself from freaking out). Even though I'm not an expert, you are welcome to ask me any questions you have and I'll try to answer them as good as I possibly can.

So if you are interested, head over to http://ceylon-lang.org to take a look at it!




So far, I hope you have a lot of fun with this!
~kumpelblase2.

 

Now hoping someone will make a plugin implementation of this so we can have ceylon plugins

 

 ferrybig That's exactly what I thought! And it doesn't really seem to be impossible to do. I looked how the ceylon code gets compiled and it seems like bukkit should be able to load it properly. However, I haven't been able figure out how to add a jar dependency yet, which would let it work.

 

ferrybig after I spent some time trying it out, I still think it's possible, but it takes way too much effort. For example, you can't add the plugin.yml automatically, you'd need to extract the car (ceylon archive), add the yml and lastly re-archive to a jar. Now you'd need to load all the ceylon classes into the runtime out of the ceylon repository. I will continue trying it out later, but it will take some time.

 

It almost seems like PHP running on a JVM...

 

1Achmed1 I don't really see that they have that much in common o.o I would rather say c# or java. Especially because PHP is dynamically typed I don't really see why you would say that. I mean sure the default parameter values look familiar but I guess that's really it...

 

1Achmed1 You and I see php very diffrent...

 

There is more than just Ceylon, there is also groovy. Which has some amazing features, like beeing able to inject methods in the runtime. For example it is possible to make it that putting a class file in a specific folder automatically lets it inherit from an class.

I know it from a web framework, called grails which is awesome (looking at the php folks here)

 

MTN There are way more things, languages or frameworks out there, that we haven't even heard of, but for this, I only wanted to tell about ceylon.

 

So is there no way to use this with bukkit?

 

Ultimate_n00b I have succeeded in creating a listener which should also be able to get registered, but I haven't been able to create a main java plugin class in ceylon yet. You should, however, be able to use created ceylon classes inside your plugin.

 

Since the release of ceylon 1.0 I took a look at it again and tried to make a running plugin with ceylon but I haven't succeeded yet.

However, I found one thing which I find makes it even better: Type aliases. They allow you to declare a specific type under a different name, thus making an alias. This is really nice when you have something like this:

Code:

Map<Class<? extends LivingEntity>, List<Map<Integer, Entity>>> map = ...;

(There's probably no reason to do it like this but whatever, you get the idea)
and you could then just make an alias for it and use that alias instead of this giant thing.

Code:

interface EntityClassMap => Map<Class<? extends LivingEntity>, List<Map<Integer, Entity>>>;

From now on, instead of always having to use the initializer of this long map, you can just use 'EntityClassMap' instead and it will work fine. 'EntityClassMap' will be the same as the big map an vice versa, so this is completely correct:

Code:

Map<Class<? extends LivingEntity>, List<Map<Integer, Entity>>>? map = null;
EntityClassMap? map2 = map;
Map<Class<? extends LivingEntity>, List<Map<Integer, Entity>>>? map3 = map2;

I think this is a really nice feature and it makes Ceylon even more interesting for me.
Have a nice day!

 

Looks like Scala.
If this run on the Java VM, you should be able to access any Bukkit classes from Ceylon by importing them.
No need to re-invent the wheel.

 

aredherring It seems so easy right? But some principles just seem to prevent that from happening.

 

kumpelblase2 I don't got your idea, why using Ceylon instead of java. We can use both, thats why this thread is senseless

 

He's introducing people to it, not saying we should use it instead of java.

 

^ This.
WhatAaCow
Even though from some things I've said you could interpret that I would like to use ceylon instead of java. In fact, I would like to use ceylon instead of java because of the many -in my opinion- advantages it has over java and I'll probably prefer ceylon in any future project which doesn't rely on framework written in a different language, such as bukkit for example.

 

Ultimate_n00b kumpelblase2 Ok, got it

 

Two more things where I now feel stupid for forgetting them in the first place (because lets face it, they're awesome).

Higher-Order functions (or functions higher order
In java this principle doesn't exist at all which I didn't like once I tried out java. The idea is that you can give functions as parameters to methods. Why is this so nice? Because it's way easier to work with instead of providing an interface and you'd need to create your own class for it.
So for example:

Code:

void each(void run(String inElement))
{
    for(i in 1..20)
    {
        run(value[i]);
    }
}

(I know this code doesn't really make that much sense)
And you could easy call it like this:

Code:

void whatever(String inObject)
{
    print(inObject);
}
 
each(whatever);

See how easy that is? Moreover, this may also give you way more flexibility because you can chose at runtime which method should be called. Just to make this even more awesome, you cannot only pass in your own functions, but also member methods (I can see how many one-liners there will be).

The second thing is that you can create collections like you'd do arrays in java. This is a pain in the ass for me all the time when wanting to add more than one value to a collection.
In java you'd either do one of these:

Code:

List<String> strings = new ArrayList<String>(Arrays.asList(new String[] { "Bob", "Josh", "Marley" }));
 
// OR
 
List<String> strings = new ArrayList<String>();
strings.add("Bob");
strings.add("Josh");
strings.add("Marley");

This is fine when you only have one thing to add but just gets ridiculous when more are involved. Ceylon to the rescue!

Code:

List strings = LinkedList { "Bob", "Josh", "Marley" };

This is what I wished for! Don't you see how nice this is? And even better, this doesn't not only work for lists or sets but also for maps!

Thanks for reading and have a nice day!
~kumpelblase2

Also a small update on the ceylon bukkit plugin: I got it to compile! It was not an issue of the language itself that it didn't work until now rather than the eclipse plugin preventing me from compiling, however, it works via the console. However, that doesn't mean it will run, but at least this gets me a step further to this goal and maybe we see the first ever ceylon plugin for bukkit today.

EDIT: Alright, strike that. Until ceylon 1.1 we won't be able to load ceylon classes when the main application is a normal java application. This is due to the fact that ceylon needs to control the class loader in order to make things work. So, until that happens, there won't be a ceylon plugin for bukkit.

EDIT by Moderator: merged posts, please use the edit button instead of double posting.

 

kumpelblase2
Looking forward to seeing this in action (I really wanna mess around with it )

This might be a fix to your eclipse compiling issue http://ceylon-lang.org/documentation/ide/

 

Minnymin3 I'm using that already. The compiles issues only came up when I used bukkit and seem to be fine when I run the compile in the console while referencing the default maven repo.

 

kumpelblase2
Whats the error?

 

Minnymin3 Lots of them. First of it can't look up the bukkit classes then something to do with the visibility of the plugin class inheriting the javaplugin and whatnot.

 

kumpelblase2

Is there an update? This seems interesting.

 

nichiatu If you want updates in the language, you're probably better off looking at their page.

Otherwise for the plugin:

 

I meant the plugin. Thanks