This is from an important (to me) blog post. It introduces a useful way of thinking about my activities and approach to life, work, and everything.
How can we call a function that doesn’t exist? Well, it’s an exercise in imagination. As we’re writing
main, we can ask ourselves “What kind of function would we like to call here?” What name would make sense for it? Would it need to take any arguments? If so, what? Would it return any results? How many? What type? And so on.In fact, this is a good way to design such a function—and, by extension, the whole public API of our package: by using it.
There’s a Zen saying that applies here:
If you want to climb a mountain, begin at the top.
In other words, if we want to design a package, we should begin by pretending it already exists, and writing as code that uses it to solve our problem. When this code looks clear, simple, and readable, we probably have a nice design. The hard part is over: all we need to do now is actually implement that design.
Write packages, not programs
Apply this to today’s planned activities, and what do you get? The development of three universal introductory modules that will work until the underlying premises on which these ideas are built are altered. (I am constantly watching to see what Darth Vader does).
Packages vs programs. The illustration that crystallizes the idea is:
The biggest shift in our thinking, then, is from solving our very specific and parochial problem, to solving a general class of problems that includes ours. For example, instead of writing code to calculate the square root of 2, we write a package that calculates any square root, and then we apply it to the number 2.