An Introduction to Java - Java: The Good Parts - page 1

Chapter 1. An Introduction to Java
Prior to launching into the main topics in this topic, let's step back and think about some of
the core assumptions of a work that calls itself Java: The Good Parts . As a colleague of mine
was wont to say, “good” is such a value-laden term that it is proper to first think about what
we mean when we say that a programming language, or part of a programming language, is
good.
What makes a programming language good, and what parts of a language contribute to the
goodness of the language, is generally a debate best undertaken late at night with the aid
of considerable chemistry. Such debates—and they are always debates, never simple discus-
sions—have a certain nonterminating nature to them, much like debates over the best editor,
the proper way to format code, or open source licenses. In an attempt to keep my mailbox
from overflowing on the date of publication of this topic (or, perhaps, on the date that the topic
is first read), it may be worthwhile to look for a moment at the notion of “best” or “good” with
regard to a programming language.
The most famous (or infamous) seed for such discussions is Richard Gabriel's essay The Rise
of “Worse is Better.” [ 2 ] In this essay, Gabriel gives a convincing argument that Lisp was (and
is) a better language than C, but that C won anyway because of all sorts of factors that had
nothing to do with the goodness of the languages. In fact, according to the essay, it was be-
cause C and Unix were worse than their alternatives (Lisp and Multix) that those languages
were able to come to dominate programming.
The main problem with the argument (which I've pointed out before) [ 3 ] is that it makes the
mistake of thinking that “worse” and “better” are predicates denoting properties that adhere
to entities directly. [ 4 ] Put more simply, these discussions assume that you can talk about a lan-
guage being good or bad in a vacuum, or in some absolute fashion. But that's the wrong way
to think about these notions, especially when applying them to things that are means to some
other end. One shouldn't argue or even assert that programming language x is better than pro-
gramming language y , because “better than” requires a third term. We need to know what you
are trying to do with the programming languages before you can talk about which one is better
than the other. Likewise, if you want to talk about a language being worse or better, you have
to say what you are using them for. A language is worse or better at doing some things, and
for different things, you may get a different answer on which language is worse or better.