Before we look at the important ideas that underpin each of the five parts, we must briefly consider one of the most important ideas that arch across the entire book: realistic-looking examples. With a realistic-looking example, the learner can leverage their intuition to aid their understanding of the technical. A reader who almost understands a concept, can have the last piece of the puzzle provided by their intuition; this is one of the primary reasons we use examples in the first place.

On the opposite side, the abstract $foo = "bar" style examples so frequent on the web provides nothing other than a hint about syntax.

The examples are also self-contained, meaning they are generally complete programs executable on their own. Despite that, they are kept relatively small. Sometimes this means the authors have glossed over details regarding e.g. encoding, or error handling, or other such things that are necessary in a real-world program.

The tutorial throws the user straight into the experience of using awk. There is no theoretical discussion first; there are no installation instructions; the first thing you see is an input example and a short program doing something with that input. They even get to the expected output on the very first page. I don’t think that’s an accident.⁵⁵ Short note on target audience: in k&r, they wait until the second page with showing this stuff, because that book has a different target audience; the readers of that book may need some soothing words before they enter the shocking world of computer programming. The awk readers are likely familiar with programming already.

This may not sound very special. Lots of things market themselves with a complete example up-front. However, when it comes to books about technologies, that’s more rare. You often see a whole chapter in the beginning devoted to explaining the philosophy behind the technology, rather than letting the user get a feel for the philosophy themselves, by doing. It also seems common these days to have users of programming languages start out by typing expression like 4+2 in a repl. I believe this is less satisfying and further removed from real programming than creating complete programs – even if they have to be very simple to start out!

Following the first example is a high-level explanation of how the program produces the expected output, just in case you didn’t guess that already. The authors then give you just enough information on general principles so that you can start experimenting with modifying that example. This is also where they write half a page on errors – because if you don’t create errors when you modify the example code, your tinkering is not bold enough. Testing the limits of the system – even with your minimal knowledge – should be part of the process.

The tutorial goes on to introduce slightly more complicated examples based on the same input data. Only one self-contained example at a time – and still very basic stuff, but enough to get you going. In the end, the tutorial has touched briefly on every aspect of awk, but not gone into detail with anything.

At this point, there has been nearly no discussion on syntax. The reader is expected to just accept the syntax and internalise it by copying and tweaking examples.

The second part, the complete description of awk, is a more systematic reference to the entire language, with both high-level descriptions and examples for most things. This is where the syntax is given in detail, as well as listings of special variables, arithmetic operations, built-in functions, control structures, evaluation rules and so on.⁶⁶ This is also where regular expressions are introduced. In the tutorial, text matching was limited to plain strings. The reader was encouraged to read ahead to learn about regexes, which “can be used to specify much more elaborate patterns”.

Although this is a systematic description of the full language, it still follows a logical progression: It starts with the core fundamentals of the language and ends with advanced, slightly niche features. In the middle is stuff that becomes useful when writing larger programs.

Once the reader is done with this chapter, they know everything there is to know about awk. Everything else in the book is literally just various strategies to combine what the reader knows into useful programs.

The third part contains a bunch of realistic-looking examples, exploring ways to use the concepts taught in the previous two parts. The examples are usually chosen to highlight the obvious things most users will want to try.

Most examples are self-contained and full programs, which helps the reader get a sense for the entire task of writing an awk program. Essentially, it gives some ideas on how the authors intend the users to write code in awk.

As a followup to the previous part, the authors also devote a few chapters to cover some more complicated, domain-specific examples. These are more complicated and the authors have given each example its own chapter. These chapters are split into sections roughly such that at the end of each section comes a point where you could leave off and have a functioning program.

I call these examples domain-specific, because they are. But that’s also slightly unfair, because they have selected very general domains: language processing, compilation, and relational data management. These are things that tend to be embedded into pretty much any larger system.

Last, but not least, is an appendix which is nothing but a compact listing serving as a language definition. This part continues to be highly useful for a long time after the reader has learned awk.