The Cell Programming Language

Cell is a domain-specific programming language designed to integrate with your language of choice in order to provide a number of features that have no equivalent in more conventional languages.

It offers, among other things, a very flexible, entirely structural type system; deterministic, repeatable execution; support for reactive programming; the ability to use relations to store data; transactions and propagation of undefined values for error handling; and orthogonal persistence.

Cell's most important new language construct is automata, which come in two flavors: relational automata and reactive ones.

Relational automata are the most general type. They can be used to implement all sorts of stateful systems, but their support for an elegant version of the relational model, the ability to easily load and store their state from and to a file, their robust error handling mechanism based on transactions and the ability to replay their execution at a later time make them especially well-suited for managing persistent data in desktop, mobile and embedded applications. Compared to an embedded SQL database, they provide a much better data model and type system, are faster and fully programmable, have a small memory footprint, allow more control over how the data is stored, and interface smoothly with the host language, with no need to do any object/relational mapping. To learn more about them start with this introductory example.

Reactive automata on the other hand are a more focused tool, specifically designed for software that needs to deal with multiple asynchronous data or event sources that trigger a cascade of changes throughout the application every time they activate, change their state or emit a value. Examples can be user input events, readings from a GPS sensor or an accelerometer, or data coming from remove computers or external hardware devices. But these data streams may also originate inside the application: internal events in many video games for example pose similar issues.

These signals vary asynchronously and independently of one another. An update can be triggered by any of them at any time, and it affects all the parts of the application state that depend on them, either directly or indirectly. This often involves propagating these changes through several layers of software, and usually that has to be done in a very specific and hard-to-get-right order to ensure that the various components of the application never read stale values. Just as importantly, sometimes updates have to be triggered by the lack of change or activity, when some signals have been idle or some conditions have been true for a certain amount of time.

Systems like these are difficult to fit into the rigid, sequential execution model of imperative languages. The traditional way to implement them involves the use of threads, observers, callbacks and timers. The resulting code is typically error prone, brittle and unnecessarily complex. Reactive automata on the other hand allow the developer to specify declaratively only the dependencies between the signals, with the compiler taking care of everything else. The reactive automata page provides a comprehensive introduction.

Although Cell is, in and of itself, a general-purpose language, that can be used to write entire applications (the Cell compiler, for example, is entirely written in Cell), that's not what it is designed for. It is, instead, meant to be used as a domain-specific language, that complements your primary language, instead of replacing it. Compiling a Cell codebase produces a set of classes in your language of choice, which can be easily integrated into an existing project. Code generators for C++, Java and C# are already available, and other languages will follow.

The long term goal of the Cell project is to define and implement a programming model that can be used to write client/server software so as to have the compiler generate code for both client and server (in different languages if need be) and automatically take care of all aspect of network programming that can be abstracted away (things like communication between client and server, error handling and persistence) and to minimize the developer intervention when dealing with those issues (mainly concurrency) that cannot be completely hidden by the language and the network infrastructure. Such programming model will depend heavily on the unconventional capabilities of Cell, like orthogonal persistence and the ability to replay and rewind the execution of a program. You can read more about it here.

If you have any question, there's the cell-lang Google Group. For announcements, there's cell_lang on Twitter.

The Cell compiler is free and open source software, and all source code is available on github.


06 Sep 2018: Version 0.2 of Cell ➞ Java compiler released.

25 Apr 2018: Version 0.1 of Cell ➞ Java compiler released.

26 Feb 2018: Version 0.1 of Cell ➞ C# compiler released.