Being able to change large systems quickly and safely is a critical business need.
All software is written with certain assumptions about the environment in which
it will operate, but real world environments change. Some changes can be
anticipated and prepared for, but prediction is never perfect. 

For example, Linux is huge in datacenters because it provides a very efficient
networking stack. However, the nature of Internet traffic changes all the time,
and it's desirable to change the networking code to adjust to these changes.
Yet changing C programs in C is hard and prone to crashing, especially for the kernel.

The industry's answer to this was eBPF, which allowed junior programmers to make
small changes to the Linux kernel quickly and safely, without the fear of crashing:

https://www.brendangregg.com/blog/2019-12-02/bpf-a-new-type-of-software.html

eBPF is a combination of innovation in both operating systems (a system of hooks
inside the Linux kernel) and programming languages (a new language, with its own
virtual machine, bytecode, and verifier). Some call it the future of networking and
security:
           https://cilium.io/blog/2020/11/10/ebpf-future-of-networking/
(Caveat: this comes from a business built on eBPF; however, it's a good introduction
that goes way beyond the marketing claims.)

This problem is very old. Consider Alan Perlis' Foreword to SICP (the end of page 16
though page 18 in the PDF edition). Back then (in early 1980s) Pascal was the exemplar of
imperative languages; today we'd use C++ and Java as examples of the same approach.

"""
Pascal is for building pyramids—imposing, breathtaking, static structures built by
armies pushing heavy blocks into place. Lisp is for building organisms—--imposing,
breathtaking, dynamic structures built by squads fitting fluctuating myriads of simpler
organisms into place.

The organizing principles used are the same in both cases, except for one extraordinarily
important difference: the discretionary exportable functionality entrusted to the
individual Lisp programmer is more than an order of magnitude greater than that to be
found within Pascal enterprises. Lisp programs inflate libraries with functions whose
utility transcends the application that produced them. the list, Lisp’s native data
structure, is largely responsible for such growth of utility. The simple structure and
natural applicability of lists are reflected in functions that are amazingly
nonidiosyncratic. In Pascal the plethora of declarable data structures induces a
specialization within functions that inhibits and penalizes casual cooperation. It is
better to have 100 functions operate on one data structure than to have 10 functions
operate on 10 data structures. As a result the pyramid must stand unchanged for a
millennium; the organism must evolve or perish.
"""

All of these themes are still in play, even though functional programming (which Lisp and
Scheme exemplified) has gone through _another_ revolution: the introduction of algebraic
types and strongly typed functional programming languages (Haskell, Scala, OCaml, etc.)

We will keep talking about these themes in the course.