Main Page

Welcome to the Delta Project!

This is about making software more reliable. ''Just imagine: A world where software developers can confidently guarantee relevant properties of their software. Where users (including developers) are able to rely on such guarantees.''

The plan
The basis is a programming language that's good for both programming and working with program guarantees.

Since no such language exists, the first step is to make one.

After that, it's libraries. Tons of them. From data structures to GUI layout managers. Programming reliable software should be as easy as what's available today, else the whole project wouldn't be worth doing.

Fortunately, it's all very much doable.

Contracts
Delta functions come with a contract. That is, a set of assertions that delimit what the function can and cannot do.

Those assertions are normal boolean expressions. It's easy to write an assertion on the square function that its result will never be negative, or one on the square root function that its parameter must not be negative.

What's unusual is that the assertions can deal with things that are more than just values inside the program; you can specify parameter and result types, what data a function is allowed to modify, constraints on CPU and memory usage, or anything else you care to write primitives for.

Assertions can be checked at run-time, but the plan is to make the compiler check the vast majority of them.

That's easier than it sounds. Assertions that need to deal with infinities can be dealt with a framework of type checking functions (that's much of what type systems are about, anyway); most loops that people write simply iterate over a data structure, and that machinery can be placed in a library function; everything else is trivial (in the sense that a program can check it).

There might be the odd unusual loop - but in that case, the programmer would want to make sure that the loop indeed terminates, and that "making sure" is easy to write down in the form of assertions.

Exceptions
For those assertions that cannot be checked at compile time, we'll have run-time checking.

A failed assertion means that the function fails. This also means that its caller fails, and the caller's caller, up the call chain until there's a function that has an assertion like either succeed this call, or report an error. (In large software, one could have strategy functions that try algorithm A first, and if that fails, algorithm B, and only if that fails as well, throw another exception. Or if unreliable hardware is involved, it could retry a few times before giving up.)

Other goals
Simple syntax, to make the language easy to learn.

Simple semantics. It should be easy to find out what each element of a Delta program does.

Expressivity. Short pieces of code can do a lot.

Readability. Even short code that does a lot is easy to read. This requires easy-to-use abstraction facilities. Side effects that can escape the local context prevent that, so most Delta code will prefer immutable data.

Context transparency. The same semantics can often be applied in different ways: a function may be executed now or provided as a recipe for execution later, some piece of code may be executed locally or on a remote computer, one step after the other or in parallel on many CPUs, reexecuting on each call or caching results. All Delta code is context-transparent by default. Of course, /some/ parts of the code need to set up the context. But moving code from one context into another does not require modifying it.

Ease of creating a domain-specific language: A few function definitions, a few precedences, and it's done.

Current status
A parser (written in Java) exists.

The interpreter is being started.

Also, a git repository is underway.

A few more things need to be done before true collaboration can happen: - a mailing list

- a way to feed the website from the repository.

Contributing and Collaboration
[mailto:jo@delta-project.org Contact me] if this is something you'd like to participate in.