Looking back at this chapter and what we’ve made so far, it’s helpful to summarize what we don’t have yet and how we’ll get there in the second part of the book:
- In chapter 3, you’ll learn about functions and subroutines, and refactor some of the calculations in our simulator as reusable procedures.
- In chapter 4, you’ll use Fortran modules to reorganize our app, and you’ll implement more realistic physics.
- In chapter 5, you’ll learn all about arrays and whole-array arithmetic.
- In chapter 6, we’ll dive deeper into input and output, and you’ll learn how to output your data in a portable way, format it, and write it to files on disk.
Beyond that, in part 3 of this book we’ll explore parallel computing with coarrays, as well as advanced data structures and procedures.
As we work through this book, we’ll come across new layers of abstraction in each chapter. Here, an abstraction is a programming mechanism that aims to black-box the internal implementation away from the programmer. For example, in the next chapter, functions and subroutines are an abstraction over explicit, imperative code. In chapter 8, you’ll learn about derived types, which can contain any number of variables and procedures attached to them, and this is yet another layer of abstraction.
Each layer of abstraction introduces a benefit and a cost. The benefit usually boils down to having to write less boilerplate code, especially when programming repetitive tasks. The cost is that abstractions hide not only the implementation details, but also meaning and side effects if they’re not used conservatively and with care. I’ll warn you each time we come across a new abstraction in this book. Consider each abstraction carefully, and use them only if the benefits outweigh the perceived costs.