Thursday 13 November 2014

Prior to launching into the main topics in this book, 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 discussions—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 book (or, perhaps, on the date that the book 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.”* 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 because 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)† is that it makes the mistake of thinking that “worse” and “better” are predicates denoting properties that adhere to entities directly.‡ Put more simply, these discussions assume that you can talk about a language being good or bad in a vacuum, or in some absolute fashion.

Download

0 comments:

Post a Comment