The Grand Challenge in Programming Languages

Appeared in Volume 8/4, November 1995

vanroy@dfki.uni-sb.de
Peter Van Roy
1st June 1995

The Grand Challenge in programming languages is to build a single simple and practical system with maximum expressiveness. There is no system that provides such useful notions as concurrency, constraints, full compositionality, lexical scoping, search, typing, distribution and persistence, while remaining simple. Is this Grand Challenge ludicrous? Well, no. Major progress has been made. But there is still much to do.

In logic programming, the concurrent constraint programming (CCP) community is tackling this problem head on and making amazing progress. We use the scientific method: isolate concepts one by one, reduce them to their essentials, and incorporate them. We exploit the power of formal models hand-in-hand with the experience of using practical systems.

The CCP community is having major successes. For example: the AKL project at SICS was the first to integrate the problem-solving power of constraint logic programming into a concurrent and reactive language, thus solving a central outstanding problem of the Japanese Fifth Generation Project. Another example: the Oz project at the DFKI has developed a fully-compositional generalization of CCP that gives first-class status to procedures, objects, and modules.

The CCP community is world-wide and growing. The developers of the languages AKL (SICS, Sweden), Oz (DFKI, Germany) and LIFE (PRL, France and SFU, Canada) have collaborated closely over the last three years in the Esprit project ACCLAIM. The AKL and Oz projects are converging. LIFE technology is being integrated into Oz. CCP work is going on in many other places including Xerox PARC. The ToonTalk system, a successor to Logo, has CCP at its heart.

The vision of Concurrent Constraint Programming is there and it is gaining momentum!

jwl@cs.bris.ac.uk
John Lloyd
5th June 1995

I believe this to be a thoroughly inappropriate Grand Challenge. There will never be such an ultimate language - simply because of the wide range of applications we have to cope with. A more sensible Grand Challenge would be to create 3 or 4 languages using different but related paradigms to cover the variety of applications - that is, we want to create an "ultimate family of languages".

For example, there is another class - the declarative languages - which will have a successor in this ultimate family of languages. This class currently includes Prolog, CLP(R), Prolog III, Alf, Babel, Goedel, Mercury, Escher, and others. (Actually, some of these are not all that declarative - but at least they try to be!) For a wide range of applications, the declarative family is more suitable than the CC family (as indeed there are many applications for which CC languages are more suitable than declarative ones).

It might be interesting to speculate on what other classes of languages will be represented in the ultimate family.

kff@dentex.electrum.kth.se
Karl-Filip Faxen
7th June 1995

I believe this to be a thoroughly appropriate Grand Challenge, at least if it is interpreted in the sense of constructing a multiparadigm language.

I believe that many large applications can make good use of several different programming language paradigms (e.g. imperative, functional, constraint solving, etc) which means that one has essentially three choices:

(1) Choose one language (paradigm) and code the entire system in terms of that paadigm. For instance, write the whole thing in C++.

(2) Code each part of the system in its own language. Then you have to use several compilers, etc. Also, data and control constructs must be mapped between the languages (suppose that a C function is called from Haskell with a list argument; what type will this list have in the C code?). The semantics of a C function is different from the semantics of a Haskell function which is different from the semantics of a Prolog predicate. This approach is most useful if the languages are of the same paradigm, e.g. C and Fortran.

(3) Use a multiparadigm language. This doesn't mean pouring a number of different languages together, but rather finding a semantic framework that can capture all of the paradigms and using this to glue them together in a natural way. For instance, imperative and fuctional programming can be combined by a linear type system which guarantees that the performance and space consumption of the imperative paradigm is combined with functional semantics. This option allows a much tighter integration between code written in the two styles.

Of course, this doesn't mean that all programs should be written in this language. For instance, it is not likely that it will be a good scripting language. Also, I think that most problem solving will be done using domain specific languages. By and large, I expect such a multiparadigm language to be used much as C or C++ is used today.

vanroy@dfki.uni-sb.de
Peter Van Roy
19th September 1995

It is quite possible to have a single underlying programming model support different styles of programming. Instead of an 'ultimate family of languages' we have a set of 'programming styles'. These styles are not at all in conflict, i.e., one can use them together with ease. Why? Because they address different concerns. For example, structuring a concurrent program is done with a style that expresses concurrent objects. The primitive operations of this program can be done with a style that expresses predicates or functions. This can work well together if both styles share a common underlying foundation.

A CC language can also be considered a declarative language. It has a declarative core that is a pure logic language. In addition, it brings operational aspects into visibility. Operational aspects are very important in practice, so why sweep them under the rug? CC languages give them as much attention as the declarative aspects. For example, consider the advantages of having a first-class top level in Prolog.