So far, the book has focused on quick-and-dirty scripting, in the service of larger analytics goals. The most in-depth I've gotten about code is how to do unit testing and work within the context of a conventional software engineering team.
This chapter will take a step back and get into some of the more abstract, theoretical aspects of programming languages. This is important to know for two reasons. First, these considerations will often dictate important decisions about what tools to use when. You don't want to lock yourself into using the wrong technology for a task, especially if you find yourself working to create a large software framework. Secondly, tools that are fundamentally different can take some getting used to; understanding the core concepts will ease the transition if you have to pick up a new tool that is profoundly different from what you're used to.
A “programming paradigm” is a conceptual way to think about the logical structure of a program and implement it in code. You can think of it as a sequence of instructions for how to perform the computation, a mathematical specification of what the output should look like, or a range of other options.
Before I get into the details, the first big thing you should know is that most modern high-level languages support all of these paradigms to one degree or another. This means that to a large degree you can mix and match paradigms depending on what ...