# Of maths and optimality

### Pavel Morava ・2 min read

When dealing with coders, one can often run to two misconceptions, which I, personally, consider especially harmful:

- mathematics is not necessary,
- programming language doesn't matter.

Let me demonstrate the ways of how proponents of such claims think.

As for math, they never needed to use it, ergo, it is a waste of time. Note, this is not only about not using maths, this is about reinventing the wheel in the subpar manner.

Do you need a simple example? How would you calculate number of permutations of 10?

If you know Python and you don't know maths, you can write:

```
from itertools import permutations
%timeit -n 2 sum(1 for _ in permutations(range(10)))
```

*581 ms ± 11.3 ms per loop (mean ± std. dev. of 7 runs, 2 loops each)*

If you know math, you can simply calculate factorial of 10.

```
from math import factorial
%timeit -n 2 factorial(10)
```

*300 ns ± 225 ns per loop (mean ± std. dev. of 7 runs, 2 loops each)*

I can assure you that the first solution is slow like hell. And no matter what programming language I used, the math is always faster.

**Mathematics might have solved your problem faster and better! Use it.**

As for programming languages, they claim these are mere tools. The basic mantra they repeat sounds like: being Turing complete, it is fine and all the same. Oh geesh! Had I suggested to you to carve a spaceship with knives instead CNC machine, because both have blades (equivalent of the Turing completeness here), you would seriously question my sanity. So, what is the point here? Mere tools? Sure. And what? Cars are mere tools intended for transport; we generally buy cheaper cars because they are cheaper, not because we are not able to recognize the difference in quality and comfort.

The last argument I'd like to mention brings irresistible proof of nothing. They say that a language XY perfectly suits their need because they use this language for building complex systems. The logic fallacy lies in confusing the ability to do something somehow for the ability to do something optimally.

For instance, you can walk thirty kilometers by feet, still you can go by car faster. Or, if you decide today to make a new Egyptian pyramid, you would probably use more modern means than sledges. What would you think about someone arguing: there are loads of pyramids made by good old sledges, while none by heavy machinery? Thus, using sledges to pull stone blocks is perfectly fine! Cranes? What about cranes? The old Egyptian did not need them either.

**Possible doesn't equal optimal! Do not confuse them!**

Don't get me wrong. I can completely understand pragmatic answers like: Sure, the language X is undoubtedly designed better than language Y, but it lacks tooling, ecosystem, developers, and many other reasons, which may reflect your valid concerns. But the flaws in design do not disappear just because you use the language a lot. To admit them is the first step to avoid the danger.

As for math, arguably, most coders do not need it to make their job done. But I still do believe that knowing underlying principles is beneficial, anyway.

What is your opinion?

Or perhaps most programmers

alreadyuse it to get their job done.Math shows up in array manipulation (set theory), functional programming (lambda calculus, category theory), data structures (graph theory), expressions, conditionals, switch statements and relational databases (logic) and big-O notation / drawing circles (calculus).

It's just that programmers don't do their math in mathematical terms, but rather, by means of abstractions. By consuming, producing and composing pre-built elements (methods, functions, etc) which ultimately invoke some kind of mathematical operation, but from the outside, are mere abstractions.

For this reason, I think that the most important ability for programmers to have is

abstract thinking. Even though the work frequently invokes math, logic, language, strategy, design and countless other fields, it isn't essentially tied to any one of those fields. Rather it deals with them in terms of abstractions.The core is abstract thinking, everything else is peripheral.

Unless I was building software specifically targeting a mathematical field (and even then...) I would spend more time reading books on programming than books on math.

Thanks for your input.

I agree, I think alike. As for your last paragraph, it is actually the same: books on programming often supply their readers distilled version of mathematics, the pragmatic part.