Programming expert Bartosz Milewski presents an example of how to design

and implement a small program (a command-line symbolic calculator) using

many of the techniques applicable in more large-scale software development.
When you write a program, you don't ask, "How can I use a particular
language feature?" You ask, "What language feature will help me solve my
problem?"

Programmers are rarely totally satisfied with their code. After I wrote the
program for my article on polymorphisma simple parser-calculatorI
immediately noticed that I could have done it better. I felt that the top-level
view of the program was not very clear. The nodes of the parsing tree needed
access to components such as the Store (the calculator's "memory"), the
symbol table (to print meaningful error messages), and maybe even to the
function table (to evaluate built-in functions). I could have made all these
objects global and thus known to everybody, or passed references to them to
all the nodes of the tree.

The order of construction of these objects was important, so I felt that maybe
they should be combined into one high-level object, the Calculator. The
temptation to redesign and rewrite the whole program was strong. Maybe
after the nth iteration I could come up with something close to the ideal?

Then I decided that I shouldn't do it. Part of making a program is coming up

with not-so-good solutions and then improving on them. I would have cheated
if I had come up with the best, and then reverse-engineered it to fit the topdown design and implementation process. So here it isthe actual, real-life
process of creating a program