Code as total algebra

having a variable mindset in computer programming
2025-05-14 12:00 // updated 2025-05-14 12:06

Algebra might sound like a subject that most people don't touch after high school mathematics. Or, at best, algebra belongs in the comfy confines of academia, untouched by the outside world. However, algebra actually disguises itself as computer programming when things move beyond the classroom. With computer programs, an algebraic mindset allows for less friction when changes need to happen.

Computer programming as applied algebra

The idea of calculations involving variable values should come to mind. Instead of something like this in mathematics:

z = x + y

... we might have something like this in programming (e.g. JavaScript):

const total = subtotal + tax

The symbols change but the underlying idea of our tasks stay essentially the same!

Also, the ideas of summation (using that Greek letter Σ or sigma symbol) appear as a loop (whether a while or a for) in computer programming. Only its notation might go from something like this:

and in code (again, using JavaScript as an example) would look something like this:

const sum = 0
for (let k = 0; k <= 5; k++) {
  sum += k
}

So, we can see now that mathematics and computer programming have the same "flow" but simply "spell things differently".

Magic values and variables

We call magic numbers (or, more broadly, magic values) the part of code that cannot change without changing the code itself. We want the values of variables to be supplied by someone else, rather than entered by a programmer. As the supplier of data is often not the programmer, the programmer must ensure that the variables can change by external sources and forces. (The programmer should not have to do data entry!)

How algebraically abstract do we want to get in computer programming? When we write code, we should try to have as many variables as possible. The more uncertainty that a piece of code has, the more we should use variables and not hard-coded magic values! From the start, however, this may not always be that convenient. There will be a transition period when a programmer will have to enter in the values. If necessary, then, the programmer should list all these variables in one part of the code as "configuration variables".

Take this pseudocode for example where the programmer needs to input the tax rate manually:

taxrate = 15
price = 100

// do some stuff with the taxrate and price

There we have two variables, tax and price, which the programmer has to enter some magic values based on the whims of the government (tax) and the merchant or client (price). However, imagine a program with more complicated tax rates and thousands of prices! That would make maintaining the code much more impossible!

Shifting the responsibility of entering "magic values"

So, if the programmer could find a way to grab the tax and price from somewhere else, then we would have a pseudocode like this:

taxrate = (get this from an online government source)
price = (get this from the client)

// do some stuff with the taxrate and price(s)

For both the tax and the price, we shift the responsibility of changing their values to the ones who have better knowledge of them:

  • The government (a functioning one, at least) should have some website that divulges its tax rates in a format from which one could retrieve
  • The client would also have a database console where they can enter the price of something, without touching the code

The idea lies in ensuring that things get updated with as little friction as possible. Algebra and arithmetic are both considered "math". However, to write a good program that allows change, we have to think not arithmetically, but algebraically. (So, the kid who thinks we don't need algebra in life is a stupid head!)

When "magic values" are necessary

All that said, we sometimes need hard-coded numbers, such as -1, 0, 1 and 100.

For example, if we need to calculate the total cost of a product, we can do this:

taxrate = (get this from an online government source)
price = (get this from the client)

cost = price * (1 + (taxrate / 100))

The "1" and the "100" in the cost formula are not actually "magic values". Rather, they are the laws of mathematics at work, using the basic concepts of percentages when adding tax to a price to find cost. Since those numbers will never change, it is okay to use those numbers!

Oftentimes, these numbers will be 0, 1 and -1 but sometimes, we might have exceptional circumstances such as using 32, 5 and 9 to convert temperatures from Fahrenheit to Celsius. Since those numbers will never change, we can safely use them:

tempInF = 86
tempInC = (tempInF - 32) * (5/9)

TLDR

  • We should try to use variables where possible to allow for change
  • If we need to change values to variables, we should gather these configurational variables together in one part of the program for easy access
  • It is okay to hard-code (i.e. type numbers in by digits and not variable names) "magic values" as long as they do not change during the lifetime of the code
    • Otherwise, we should leave the responsibility of changing these values to someone else who has the most knowledge of them!
⬅️ older (in uncoding)
😀 Different lifestyles of web developers
⬅️ older (in code)
😀 Different lifestyles of web developers