
Mathematics I Use (2012) - pmarin
http://pub.gajendra.net/2012/10/mathematics_i_use
======
motohagiography
I would say almost half the performance problems I have seen developers and
devops managers run into over the last 5-6 years could have been avoided with
a bit of front loaded queueing theory.

When you are doing microservice orchestrations, using an enterprise service
bus or a pubsub, or doing multiple asynchronous operations, small delays
multiply through the system. Spending a day to model your solution as a queue
will give you some ballpark tolerances for lag, queue size, and in particular,
RTT through the service.

Doing microservice architectures takes a lot of the logic of the problems
solved decades ago on the network layer and reinstantiates them at application
service layers without those solutions. Request TTL, state, queue flushing,
retransmission, shortest path, service availability, 'ping', 'traceroute',
etc.

If one service crashes, and requests start piling up, you need to clear that
queue, and oftentimes your solution isn't built to clear that queue while more
requests are coming in and your cache overflows because "keeping state is a
next order complexity problem that wasn't specified in the user story." There
is an assumption you can just horizontally scale your way out, which has
significant compute and administrative costs. I suspect AWS makes a lot of its
money as a direct result of those assumptions.

Not saying someone needs to be doing new proofs, but some forethought using a
handwavy abstraction might provide some insight into the needs of the system
under load.

~~~
hackermailman
There's a good book for this if anybody is interested
[http://www.cs.cmu.edu/~harchol/PerformanceModeling/book.html](http://www.cs.cmu.edu/~harchol/PerformanceModeling/book.html)

~~~
raister
Good book? Are you sure? This is a terrible book on performance... It begins
with the classic: "this book will make readers pass the first chapter, because
it contains simple explanations for performance phenomena..." \--> then, by
chapter 2 _everybody_ is completely lost about the subject... again.........
:(

Edit: this book is currently sitting on my shelf collecting random particles
of dust (for 4 years...).

~~~
hackermailman
There's many other books[1] on queuing theory if you want, I liked the
Harchol-Balter book because of the exercises
[1][https://web2.uwindsor.ca/math/hlynka/qbook.html](https://web2.uwindsor.ca/math/hlynka/qbook.html)

------
OskarS
I feel like you have to know a little bit about a lot of things. Like, yeah,
you have to have a basic understanding of SOME graph theory when programming
computers, but you don't really need anything too advanced. Yes, I guess you
need to understand SOME category theory to be able to use advanced typing
systems effectively, but it's a very surface level understanding of a very
deep field. Same thing with most of the other fields mentioned.

One thing that wasn't mentioned: if you're doing any kind of graphics
programming, you use a huge amount of basic linear algebra every day. Vectors,
matrices, dot/cross products, affine transforms, spaces and subspaces, that
kind of thing. If you're doing more advanced stuff, a working knowledge of how
to solve large linear systems (i.e. things like Gauss-Seidel/Jacobi methods)
and the physics of light transmission is also useful. If you're doing physics
simulations, obviously you need a working familiarity with calculus.

Again, though, all of these things are massively deep fields that people
dedicate their lives to understanding, but as a programmer you just need to
skim the surface, generally speaking.

~~~
hinkley
And yet I’m constantly surprised by people knowing nothing of set theory.
Occasionally someone who doesn’t know logic (evidenced by nasty, over-
complicated Boolean logic)

Or my current favorite: a very senior and very optimistic person who
apparently doesn’t believe in decidability, the halting problem, or NP
completeness.

~~~
andrewflnr
Like, they think computers are just invincible problem solvers, or can't even
really comprehend the question? I can't grok what it means to not believe in
NP completeness.

~~~
hinkley
That developers can do anything if we stop complaining and get to work.

No, in fact we've proven there are a lot of things we can't do, and oceans of
things that are theoretically possible but completely impractical to do
(another class of people mistake intractable for impossible, but for small
enough N sometimes it is both possible and worthwhile).

------
glancast
You don't need much mathematical knowledge to _merely_ be productive, but his
points are valid.

1) The more math I learn, the more I realize how much I'm already doing it
(via poor heuristics) without realizing it.

2) Mathematical training comes with many tools I would never think to Google
without prior introduction. For instance, I sometimes use Karnaugh maps to
simplify complex boolean logic. I'm sure there are many areas where I re-
invent the wheel, miss simpler solutions, and generally produce less quality
because I'm ignorant of the surrounding mathematical context.

~~~
Ari_Ugwu
This. I believe we are ripe for another leap in math education, or at least
computer science education. A new approach to teaching that in a generation
will make current methods looks like rhetorical algebra.

I think this is a great example: [https://github.com/Jam3/math-as-
code](https://github.com/Jam3/math-as-code)

That page is a sort of rosetta stone for me after years of learning to code
while also struggling with math notation. I find a similar fog lifts when I
look at set theory through the lens of SQL and relation databases.

It amazes me that we still can't clearly demonstrate to children why math is
important and instantly and universally instill a love and curiosity. Instead
we have unforgiving educational models that are "well, you either get it or
you don't."

It angers me to think of all the potentially _effective_ programmers who get
their dreams squashed because they can't pass Calculus II (or other prereq.),
and thus are literally not allowed to enroll in a programming course.

I didn't know about Karnaugh Maps but I use truth tables constantly in the
design phase of tasks. Thank you very much for this. If you've found other
tools like this please share. Not really related but for requirements I find
gap and SWOT analysis to be vital tools as well as weighted pairwise
comparisons. Throw in some UML diagrams and I start feeling good about things.
These things impress far more people than they should.

</rant>

------
maroonblazer
As someone who has spent most of his adult life recovering from a math phobia
(due largely to poor teachers in middle and high school) and enjoys
programming as a hobby, had I read this article when I was exploring whether
or not I had the aptitude/background for programming this would have turned me
off entirely.

I agree with the others that this article seems to overstate the requirements.

~~~
norealidea
So, are you still afraid of math?

~~~
maroonblazer
No. Post-college, I didn't need it for my job and I discovered programming -
at least at the level that I was enjoying it - was as much, if not more, about
logic and breaking problems into pieces. Despite that my lack of math ability
felt increasingly like an albatross around my neck. In the same way that one
might feel they're missing out by not studying history.

It was only after coming across a quote from Charles Darwin where he mentioned
that one of his regrets was that he didn't study math more thoroughly. And
that because of that there were entire "conversations" he was missing out on.
For some reason I found that both liberating and motivating.

"Me and Charles Darwin, we're not so different you and I." ;-)

------
thanatropism
This is a very well written post, in the sense that much of what he mentions
is central to programming. But there's also a Zadeh's principle to mathematics
-- when you have measure theory suddenly everything is a change of measure.

And I mean, this is great. "Diversity in tech" should be more like "people who
are into analysis, topology" versus "people who are into algebra and cat
theory" etc. There are many different ways to skin problem spaces into mental
models and coding styles.

------
mooneater
A good programmer may use many of these types of math without even knowing the
formal names.

Sometimes knowing the formalism helps a lot, sometimes it doesn't add much.
Some people overly obsess with formalisms and some people are overly adverse
to them.

I do find people who need to over-formalize everything to be annoyingly
pedantic.

------
norrius
For whatever reason, the link does not work for me. Google's cache doesn't
seem to provide a copy, so here's one from the Wayback Machine:

[https://web.archive.org/web/20180420113021/http://pub.gajend...](https://web.archive.org/web/20180420113021/http://pub.gajendra.net/2012/10/mathematics_i_use)

To the topic, I think this quote from the article is very important to note
here: _“Of course, I do not do all of this every day, but I have done all of
it at one time or another and most of it regularly.”_

It is nice to have an idea of how you write a parser for a language, but I do
not believe the author advocates for being able to write one of the top of
your head. Same with most other points.

------
jfv
I think if you're a programmer wondering what math will help you in your
career, which is the question this article is trying to answer, this article
is misleading.

Most working programmers won't have to know any math beyond arithmetic.

For instance,

"Also, how does one distribute a large computation across globally distributed
data centers? You have to understand some physics to do this well: at Internet
scale, the speed of light starts to be a bottleneck. Heat dissipation, density
of electrical current draw per unit area, etc, are all real world
considerations that go into what programmers do"

Come on, let's be real. In grade school we learned that light goes around the
earth 8 times a second. That means 1/16 of a second (63ms) to go around to the
other side of the world. That doesn't set a useful lower bound since this is
the ballpark of latency within a country anyway. You're just going to ping
between the two servers and measure the latency.

That being said, programming could in theory require _any_ kind of math. If
you're doing machine learning, you'll need to understand statistics. If you're
doing graphics programming, you'll need to understand trigonometry, linear
algebra, etc.

If you're writing software for the medical industry you'll presumably have to
understand a little bit about how that industry works, but I wouldn't suggest
programmers go learn that just for the sake of improving their "general"
programming skills.

Here's a more realistic take:

1) Learn math as necessary for a field you're interested in

2) Know binary and hexadecimal representations of numbers.

3) If you're going to use a lower-level language, understand how
signed/unsigned arithmetic works, boolean algebra, and some basics of the
floating point representation (in a nutshell, don't assume that computations
are exact, so don't rely on equality (==)).

4) Understand time and space complexity. For most programmers, this is going
to be simple: don't nest too many for-loops. I'm guessing 90% of programmers
will never have to construct an algorithm whose complexity involves a
logarithmic function, except for maybe binary search. Even then, most
programmers will rely on libraries to do those things.

5) Be able to do back of the envelope calculations, and understand that order
of magnitude is more important than exact numbers. Try to do them in your head
so you can quickly evaluate possibilities.

6) Increasingly, statistics and machine learning are becoming important for
programmers to know. Learn some basic statistics and it will make you much
more desirable. Play around with R or Octave or numpy and don't make the
mistake of applying too much statistics without thinking, unless you're in the
marketing department.

~~~
jerf
Programmers use tons of math, they just don't recognize it. Partially because
you can still come out of even a bachelor's program in computer science and
still think "math is just about numbers", but some of it is also just
excessive familiarity and not realizing the easy things that you're doing that
are actually mathematical because school trained you that Math must be Hard
and you have to be Sitting There and Thinking Very Hard or you're not Doing
Math.

Every day I'm using mathematical reasoning such as "I reached this line of
code, and since this is a structured program I am guaranteed that this
variable was initialized by the time I got here", "this function can only
return either a non-empty string XOR an error and has nowhere it can throw an
exception so if I handle those two cases I have fully handled everything this
function can do", "the error string has the username in it, and values like
that must come from somewhere, so even though I've been looking for an hour
and can't find it, mathematically the thing generating the error message must
have access to the username", "if I construct this as a pure function that
does no IO, on the flip side, no users of this function will have to worry
about what errors could arise during IO, reducing the mathematical cognitive
load of using this function for users".

Then you start stringing together those steps by the dozens and hundreds and
thousands and millions (and you get qualitative differences there too, but
those don't fit into a little post like this anywhere near as well), and you
can build software.

You don't have to realize you're reasoning mathematically (proof: look
around), but you're leaving useful tools in the toolchest if you don't. Even
if you won't believe me about building systems this way, I can assure you
those magical stories about people who can _debug_ systems at a glance that
have defeated others for hours or days comes back to someone who either
formally or by experience has a fairly mathematical understanding of the
system in question and was able to apply some sort of logic, even if only
intuitively, to arrive at that conclusion.

~~~
oreganoz
But that's mostly logic, at best mathematical logic. I don't think anyone
formally reasons when writing code anyway, we mostly rely on intuition. Maths
isn't about numbers but it's not about intuition neither.

Programmers doing actual math would be modeling problems and creating proofs
for their solutions. Usually we clasify those problems based on the field of
math we use to model them.

Saying we do tons of math implies we use a lot of knowledge from a lot of
those fields. But most of the time, programmers use only the introductory
notions of those fields. We are usually guided by a domain expert anyway so
that the math part is correct.

Programmers don't use a ton of math. They use some math.

~~~
jerf
I think most modern mathematicians would be taken aback if you told them logic
is not math. You might be surprised what some logicians have gotten up to.

And sure, if you define what I talked about as not math, then you don't use
math. If you don't want to use the tools of mathematical thought, be my guest.
It's one of my competitive advantages in the marketplace.

But I think Dijkstra would be pretty surprised to hear that structured
programming wasn't math, and you might be interested in budgeting six months
or so to play with Coq or something like it, where you'll learn that the
difference between proving code and what you do in just trying to make code
work and debug code is much more a quantitative difference than the
qualitative difference you think. There's no magic in how code proofs work...
it's the same processes you use all the time if you code at any scale beyond a
single screen of code, just taken to their logical conclusion.

~~~
oreganoz
Propositional logic / zeroth-order logic is like arithmetic. You didn't
consider numbers (by which I gathered you meant arithmetic) as math, and I'm
the same in saying this type of logic is not math.

Logic is a VAST field, and most programmers don't get to use most of it, that
was my point.

I already played with Coq (that feels weird to say :)) ). It is a very
specialized tool useful in very specific cases. I don't think it will ever be
adopted as the standard way of programming since it's really unproductive.

Just because you use math that is really heavy does not mean you understand
the math behind completely. We can view a ball throw as a complex quantum-
mechanical physical process but we don't call ourselves theoretical physicists
for being able to throw a ball.

------
kriro
I you find yourself wondering how math heavy programming is before diving
in...just start programming and ignore the math. You'll get by just fine.
There's libraries for everything. Yes int theory you need to know some math to
know when to use what but we live in an age where you can search for things
like "I want to do X, tell me how" for most programming problems and get a
reasonable high level "practical" answer of use library/function X and btw.
here's the docs.

That being said (basic) logic, applied probability theory (no and some vector
and matrix stuff are probably the most useful (for ML/DL). The more into
algorithms you get, the more mathy it gets. Most programmers do this rarely in
their day to day life unless they are rather specialized.

tl;dr: Don't worry about math, start writing code right now. It's fun. The
rest will come once you get interested in certain things.

------
vignesh_m
I'm very skeptical about the applicability of group theory to computer science
- outside of the usual applications to counting/combinatorics and
crypto/number theory.

------
richardwhiuk
[2012]

