One of the single best attributes of the Camel Mark III, as I like to shorthandedly refer to this book, is the authors' conversational style of writing, in which they generally use basic jargon-free English and when they do use technical terms (as they of course must since they're dealing with a technical topic) they explain the terms very straighforwardly. An example: "A variable is just a handy place to keep something, a place with a name, so you know where to find your special something when you come back looking for it later. As in real life, there are various kinds of places to store things, some of them are rather private, and some of them out in public. Some places are temporary, and other places are more permanent. Computer scientists love to talk about the "scope" of variables, but that's all they mean by it." Beautiful! How a book written by multiple authors can produce prose like this is amazing to me.

This chapter spends a few pages explaining how Perl handles variables. Something called the "principle of least surprise" is mentioned in terms of what happens when your code uses a variable that has not previously been assigned a value. Perl automatically assigns a default value of null, which can be "" for a string or 0 for a number. This is far superior to many programming languages where in this scenario you just get a random value out of memory if you use an undeclared variable. It is one less source of bugs to worry about.

The authors do frequently mention in passing rather esoteric concepts from the theory of designing programming languages. For example: "As is typical of your typical imperative computer language, many of the verbs in Perl are commands:". I'm fairly fuzzy on what defines an imperative computer language, and I imagine there are at least a few others in the same boat. Fortunately, you can understand the syntax and usage of the language without having to clear up some of these background concepts. It does give you an idea of what to look for if you want to get into the hard core of computer science, I suppose.

Update: In this chapter, Perl's operators are explained. Given that there are any number of heavily overloaded operators in Perl, I found the design choice by Wall to define (.) as a separate operator for string concatenation from (+)(the operator for numeric addition) to be surprising. It seems to me that pretty much any programmer would have no problem differentiating the use of (+) for numeric addition versus the use of it for string concatenation when looking at code. Perhaps this design choice was mandated by broader considerations in designing Perl. If someone can shed light on that, I'd be interested to find out.

Also helpful for me was the reminder in this chapter that one should "remember that = means 'gets set to' rather than 'equals'". Likewise, the section on logical operators was quite enlightening for me. The authors state that "Logical operators ...allow the program to make decisions based on multiple criteria without using nested if statements." I had not thought of logical operators in those terms before. They give an example which is the typical do X or die; usage; obviously I've seen that all the time but I had never thought that much about the alternative usage along the lines of:

do x<br>
      if x fails then<br>
        throw error
[download]

which at least takes more code to accomplish the same thing. To sum up this section of my discussion of chapter 1, I would say it's tempting to just skim it because you might say "Oh, this is just about operators, control structures, lists, how different can that be? I've used all that a million times in language X." Resist the temptation! There's plenty of important detail in here; in fact I've got lots more I'd like to say about this chapter but I've got to call it a night:)