Gilad, as many know, was for years one of the gurus of the Java language design, delicately dancing on the infinitely thin edge between semantic integrity and linguistic flexibility. Until, that is, he got tired of the need to continually choose between poor alternatives and quit Sun last year. Since then his new blog, the cheerily named Room 101 (one of my must-reads), has been putting forth all kinds of evidence about his new venture.
It's clear that it's a startup, and that they're working on a new language. But what kind of language? And for what purpose?
Start with Gilad's previously-mentioned-here paper on Objects As Software Services. This paper discusses the possibilities of downloadable software objects -- with behavior and state -- that can provide offline functionality, transparent synchronization to the server when reconnected, and dynamic upgrade. He goes into some detail on the language properties these objects would benefit from -- specifically, reflective tracking of field accesses (via a mirror-based reflective mechanism), and a typing semantics that is flexible enough to allow code upgrade without entering classloader hell.
In more recent posts on Room 101, we've seen other pronouncements of what good languages look like. For one, his excellent recent post on why constructors are considered harmful, which is because they are far too tightly coupled to the specific class in which they're declared. Most of the time you want object creation to be a matter of policy, but constructors are pure mechanism -- all you get is the instance of the class you're specifying, which is totally inadequate in most cases (the majority of cases where you want an object that fulfills some interface, but you want the framework to pick the appropriate class, since it knows more about the classes involved than you do). The canonical solution here is factory methods, but Gilad considers most of the factory method idioms in, e.g., Java to have many of the same problems -- you can't override a static factory class, you can't extend or replace it. He suggests instead a mechanism for encapsulating object-creation methods within a parameterized class definition, allowing full virtualization of object creation without the overly tight coupling to the class itself. So Gilad's seeking a language that has the structural purity of Smalltalk, with some of the warts removed.
There's also his post on why tuples are good, which is relatively straightforward as Gilad's posts go. Again, tuples give you a single language mechanism that covers a variety of important uses. We're seeing a real focus here on The Right Thing. It must be a blast for Gilad to be working with a clean sheet of paper after a decade in the immensely constrained Java space.
Finally, there's his post on why message passing is good. This is not going to be any surprise to anyone who's enamored of message passing languages, such as Erlang and (at least at the distributed level) E. Pure message passing gives you a degree of isolation and security that more tightly coupled languages can't match. It also has a very real performance cost -- we don't yet know how to build an optimizer that can make a message-passing loop be as efficient as an inlined C++ function-call loop -- but Gilad's main concerns, as we've seen, are linguistic flexibility and expressiveness for use cases including distributed programming and dynamically upgradeable software objects, not achieving the maximum possible performance for typical modern architectures (which has always been one of Bjarne's key goals).
Also, Gilad recruited Peter Ahé away from Sun, and Peter's spilling some beans of his own.
So putting all this together, what do we have? Gilad is working on a new language that:
- is a pure message-passing language (a la Self)
- refines Smalltalk's metaclass structure to allow parameterized factories and basic constructors to be implemented as virtualizable instance methods
- supports a flexible enough typing structure to enable dynamic upgrade of the code of stateful objects
- has a mirror-based reflective mechanism suitable to allow, among other things, logging of all object field accesses for subsequent orthogonal synchronization
- has tuples :-)