When doing software design, a common question is how much “advanced” functionality to build in, and how much to let the users create themselves using a simple set of tools. For example, a reporting module could have many canned reports, or could have a tool which allows users to build reports themselves (or both). Often the canned reports can do things more efficiently or elegantly than user-built reports, because they have access to the full internal workings of their environment. Designers of programming languages face a similar problem – how much should be included in the language, and how much should be left to users to build. In the latest of Scott Rosenberg’s Code Reads Guy Steel shows how the ideas of the open source movement influenced the designers of Java to think in terms of growing a language to avoid this dilemma.
Guy Steele starts by exploring how a language can be large, with lots of primitive words, or small, with only a few. Large languages are difficult to learn, and often easy to misuse. Small languages are easy to learn, but require a lot of wheels to be reinvented. By providing definitions before he uses any words longer than one syllable, Guy Steele shows us how a small language can be very restricting (and also provides a great illustration for non-programmers of the job of programming). But he makes a strong case that large languages are problematic as well.
More than just libraries
Instead of getting stuck in this way of thinking about things, the designers of Java skillfully found a new way of looking at the issue. The approach was to make a language that was neither small nor large, but rather one that cloud grow well. And following the ideas of “The Cathedral and the Bazaar” by Eric S Raymond, the set out out to design Java so that a community of contributors could add to the language – and most importantly, do so in such a way that their contributions became a seamless part of the language. This goes beyond just creating libraries, which I admit, at first was all I thought he was talking about. But there is more – it mean thinking about user contributions from the ground up, and not trying to solve all the problems at the outset.
Does this mean, then, that it is of no use to design? Not at all. But in stead of designing a thing, you need to design a way of doing. And this way of doing must make some choices now but leave other choices to a later time.
So even though Java was not (until recently) open-source in the full sense, by thinking this way the designers of Java made it possible for the best contributions from the community to be incorporated. And more importantly, it was possible for those contributions to feel like part of the original design instead of roughly bolted-on additions, and to evolve harmoniously. What has emerged is the Java Community Process, which is now the central driver of additions to the Java language. For example, one of the most important things Guy Steele wanted to add to Java, generic classes, came directly from the Java community process.
But Java is not a free for all.
We should not make the Java programming language a cathedral, but a plain bazaar might be too loose. What we need is more like a shopping mall, where there are not quite as many choices but most of the goods are well designed and sellers stand up and back what they sell.
Indeed, most open source projects are not bazaars. There is often a benevolent dictator, or editor/designer-in-chief, whose role it is to decide which contributions are the best, which are relevant to a large enough audience, then blesses those contributions as part of the canon.
If you look at the Java programming language by itself, without the standard libraries, it is just another attempt to add objects to a C-like language, one flavor of many attempts. I doubt that the particular choice of language features alone would have brought Java to its current prominence. Instead it was the ease of seamlessly integrating new functionality into the existing body of libraries and tools which made Java such a success. And this is due to a language designed for growth.
