1 Making programs safer

Programming is a dangerous activity. If you’re a hobbyist programmer, you may be surprised to read this. You probably thought you were safe sitting in front of your screen and keyboard. You might think that you don’t risk much more than some back pain from sitting too long, some vision problems from reading tiny characters onscreen, or even some wrist tendonitis if you happen to type too furiously. But if you’re (or want to be) a professional programmer, the reality is much worse than this.

The main danger is the bugs that are lurking in your programs. Bugs can cost a lot if they manifest at the wrong time. Remember the Y2K bug? Many programs written between 1960 and 1990 used only two digits to represent the year in dates because the programmers didn’t expect their programs would last until the next century. Many of these programs that were still in use in the 1990s would have handled the year 2000 as 1900. The estimated cost of that bug, actualized in 2017 US dollars, was $417 billion.¹ 

1.1 Programming traps

1.1.1 Safely handling effects

1.1.2 Making programs safer with referential transparency

1.2 The benefits of safe programming

1.2.1 Using the substitution model to reason about programs

1.2.2 Applying safe principles to a simple example

1.2.3 Pushing abstraction to the limit

Summary