scope, there’s much that can be done now—there are a number of purely artificial
overheads inherent in our current tools.
The Static Language Build Cycle
Using traditional static languages, there is an unavoidable overhead in moving from
coded programs to working systems: compile and link steps add a built-in delay to the
development process. In some environments, it’s common to spend many hours each
week just waiting for a static language application’s build cycle to finish. Given that
modern development practice involves an iterative process of building, testing, and
rebuilding, such delays can be expensive and demoralizing (if not physically painful).
Of course, this varies from shop to shop, and in some domains the demand for per-
formance justifies build-cycle delays. But I’ve worked in C++ environments where
programmers joked about having to go to lunch whenever they recompiled their sys-
tems. Except they weren’t really joking.
Artificial Complexities
With many traditional programming tools, you can easily lose focus: the very act of
programming becomes so complex that the real-world goal of the program is obscured.
Traditional languages divert valuable attention to syntactic issues and development of
bookkeeping code. Obviously, complexity isn’t an end in itself; it must be clearly war-
ranted. Yet some of our current tools are so complex that the language itself makes the
task harder and lengthens the development process.
One Language Does Not Fit All
Many traditional languages implicitly encourage homogeneous, single-language sys-
tems. By making integration complex, they impede the use of multiple-language tools.
As a result, instead of being able to select the right tool for the task at hand, developers
are often compelled to use the same language for every component of an application.
Since no language is good at everything, this constraint inevitably sacrifices both prod-
uct functionality and programmer productivity.
Until our machines are as clever at taking directions as we are (arguably, not the most
rational of goals), the task of programming won’t go away. But for the time being, we
can make substantial progress by making the mechanics of that task easier. This topic
is what I want to talk about now.
1546 | Chapter 21: Conclusion: Python and the Development Cycle