Programming Python, Second Edition

Doing the Right Thing

Of course, the Gilligan factor is a exaggeration, added for comic effect. But few would argue that the bottleneck between ideas and working systems has disappeared completely. Even today, the cost of developing software far exceeds the cost of computer hardware. Why must programming be so complex?

Let’s consider the situation carefully. By and large, the root of the complexity in developing software isn’t related to the role it’s supposed to perform -- usually this is a well-defined real-world process. Rather, it stems from the mapping of real-world tasks onto computer-executable models. And this mapping is performed in the context of programming languages and tools.

The path toward easing the software bottleneck must therefore lie, at least partially, in optimizing the act of programming itself by deploying the right tools. Given this realistic 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 ...