I'm trying our blog system:

• looks decent
• can't wait for comments
• thanks Emmanuel :)

The website is shaping up rapidly.

I need your feedback on:

• the infrastructure
• the structure

The website is available at <git@github.com:ceylon/ceylon-lang.org.git> To build the site, check out README.md

The infrastructure

As I said initially, the side is a static website built using Awestruct. I need you to have a look at it and play with it for real to see if you will be able to live with in in the coming months. In particular, write pages, (both md and haml files), write blogs, write events. I think Markdown files (.md) will be sufficient for 90% of the pages but everything requiring custom CSS id / class are better handled with .haml files.

I'm quite pleased with what is present even if that's not perfect by any means and if parsing errors can be quite hard to track. It's probable that at some point in the future, Awestruct won't be sufficient and that we will need better tools for specialized content (like blog, wiki etc). But I would never have been able to achieve what I did alone in such a short time without it.

The structure

The Play Framework site is very well done and I've shamelessly copied the structure. We of course have much less to show so many areas are different.

Home

The home page. That's the area I worked the less on, Somebody will have to step up and decide what we put in.

Learn it

That's everything doc related:

• the Ceylon tour (a shorter version of Gavin's introduction) - not finished btw
• FAQs: this will need to be filled with complier how to s when M1 hits the road. In the mean time, we need to populate it with something.
• Roadmap (I copied the wiki's page)

Download

Not much to see here, I point to the roadmap

Community

Pointers to the forum, mailing list and the list of events (conferences etc)

Code

Not much to see but that will contain:

• pointers to the Git repos
• how to build
• a link to the bug tracking system
• some hand holding for contributors

Blog

This is not a full featured blogging system yet but one can already write blogs in Markdown, tag them. A feed is generated from this. I put some examples.

TODOs

For me:

• integrate Disq.us comment system for the blog entries and possibly some other pages
• integrate a forum using an embedded Nabble forum. Btw, do we want a forum before we release some code?
• make the blog system generate per author pages (low priority)
• improve the top nav system (using some ruby code instead of copy paste)
• think about a way to generate the 2nd level nav system. Today that's manual per section.

For you:

• try the system by writing docs and see what you can do
• write documentation or pages where you feel things are missing
• help port the Ceylon introduction to the Tour format (ie getting rid of the whys and detailed explanations to focus on showing the features)

We are at a stage where the website starts to look decent content wise.

I have recently added the notion of upcoming talks which is built based on the data in _data/events_.

I have also added the blog system:

In blog, create a file YYYY-MM-DD-some-title.md and add the following metadata

---
title: We now have a blog system and decent structure
author: Emmanuel Bernard
layout: blog
tags: [site, blog]
---

Then write down your blog post in Markdown.

Note that unfortunately, the index page is not generated when a blog entry is added. You need to rm -f _site and restart Awestruct.

Built-in support for modularity is a major goal of the Ceylon project, but what am I really talking about when I use this word? Well, I suppose there's multiple layers to this:

1. Language-level support for a unit of visibility that is bigger than a package, but smaller than "all packages".
2. A module descriptor format that expresses dependencies between specific versions of modules.
3. A built-in module archive format and module repository layout that is understood by all tools written for the language, from the compiler, to the IDE, to the runtime.
4. A runtime that features a peer-to-peer classloading (one classloader per module) and the ability to manage multiple versions of the same module.
5. An ecosystem of remote module repositories where folks can share code with others.

I'm not going to get into a whole lot of fine detail of this, partly because what I have written down in the language spec today will probably change by the time you actually get to use any of this stuff, but let me give you a taste of the overall architecture proposed.

Module-level visibility

A package in Ceylon may be shared or unshared. An unshared package (the default) is visible only to the module which contains the package. We can make the package |shared| by providing a package descriptor:

Package package { 
    name = 'org.hibernate.query'; 
    shared = true; 
    doc = "The typesafe query API."; 
}

(Note: The package descriptor syntax has since changed

(Alert readers will notice that this is just a snippet of Ceylon code, using the "declarative" object builder syntax.)

A shared package defines part of the "public" API of the module. Other modules can directly access shared declarations in a shared package.

Module descriptors

A module must explicitly specify the other modules on which it depends. This is accomplished via a module descriptor:

Module module { 
    name = 'org.hibernate'; 
    version = '3.0.0.beta'; 
    doc = "The best-ever ORM solution!"; 
    license = 'http://www.gnu.org/licenses/lgpl.html'; 
    Import {
        name = 'ceylon.language'; 
        version = '1.0.1'; 
        export = true;
    }, 
    Import {
        name = 'java.sql'; 
        version = '4.0';
    }
}

(Note: The module descriptor syntax has since changed

A module may be runnable. A runnable module must specify a |run()| method in the module descriptor:

Module module { 
    name = 'org.hibernate.test'; 
    version = '3.0.0.beta'; 
    doc = "The test suite for Hibernate";
    license = 'http://www.gnu.org/licenses/lgpl.html'; 
    void run() {
        TestSuite().run();
    } 
    Import {
        name = 'org.hibernate'; version = '3.0.0.beta';
    }
}

(Note: The module descriptor syntax has since changed

Module archives and module repositories

A module archive packages together compiled |.class| files, package descriptors, and module descriptors into a Java-style jar archive with the extension car. The Ceylon compiler doesn't usually produce individual |.class| files in a directory. Instead, it directly produces module archives.

Module archives live in module repositories. A module repository is a well-defined directory structure with a well-defined location for each module. A module repository may be either local (on the filesystem) or remote (on the Internet). Given a list of module repositories, the Ceylon compiler can automatically locate dependencies mentioned in the module descriptor of the module it is compiling. And when it finishes compiling the module, it puts the resulting module archive in the right place in a local module repository.

(The architecture also includes support for source directories, source archives, and module documentation directories, but I'm not going to cover all that today.)

Module runtime

Ceylon's module runtime is based on JBoss Modules, a technology that also exists at the very core of JBoss 7. Given a list of module repositories, the runtime automatically locates a module archive and its versioned dependencies in the repositories, even downloading module archives from remote repositories if necessary.

Normally, the Ceylon runtime is invoked by specifying the name of a runnable module at the command line.

Module repository ecosystem

One of the nice advantages of this architecture is that it's possible to run a module "straight off the internet", just by typing, for example:

ceylon run org.jboss.ceylon.demo -rep http://jboss.org/ceylon/modules

(Note: The command line tools have since changed, and the above command would now be ceylon run org.jboss.ceylon.demo --rep=http://jboss.org/ceylon/modules)

And all required dependencies get automatically downloaded as needed.

Red Hat will maintain a central public module repository where the community can contribute reusable modules. Of course, the module repository format will be an open standard, so any organization can maintain its own public module repository.

Hrm, I notice it's been just over three months since I semi-accidentally announced the existence of the Ceylon project , and I guess I feel like you folks deserve some kind of progress report! At the time, I very much regretted the fact that the project became public knowledge before I was really prepared to socialize it, but in retrospect it was the best thing ever for us. That's where we got Stef and Tako and Sergej and Ben from, along with the other folks who are signing up to get involved in development. Unfortunately, we're still working in a private github repo, which is certainly not ideal, but it's helping keep us focused on getting actual code written.

So here's what we have so far:

• a 125 page language specification (with some open issues and vague sections),
• a parser and typesafe syntax tree for the whole language,
• a compiler frontend (type checker/analyzer) for about 85% of the language,
• a compiler backend that integrates the frontend with |javac|'s bytecode generation for perhaps 40% of the language, and
• the skeleton of a "model loader" that builds a metamodel of precompiled .class files (essential for incremental compilation and interoperation with Java).

The frontend of the compiler (the bit that analyzes the semantics of the code, assigns types to things, and reports programming errors) is basically done already. Certainly all the "hard" bits are finished, including stuff like generics, covariance, subtyping, refinement, member types, union types, definite assignment and definite return checking, type argument inference, etc. The few missing features could be finished off pretty quickly if there were any real urgency, but we may as well wait for the backend to catch up.

Development of the backend and model loader is now completely in the hands of volunteers from the community, and, frankly, it's going really well so far. We'll do an initial "alpha"-quality release of the compiler when we're happy that the backend is in a usable form.

I'm not going to promise any exact date for the first release, nor even the exact feature set - but I'm guessing it will happen within the next three months, and that it will include a really decent slab of the language defined by the specification. At that point, we'll hopefully be able to start putting some resources into the SDK and IDE.