Programming is very different from and far more useful than what they call "math" in school, but basically any analysis of your program or of possible improvements is going to involve methods and knowledge that people called "mathematicians" and "computer scientists" happen to be very familiar with.

I think about this very often and was thinking to write an article about this for years, and today too. Good that someone beat me to it, now I don't have to.

I was repeatedly told in school that math is a very important skill to possess as a programmer even though the teachers never wrote a line of code in their lives. This would be one of its main points. Where the hell do people get this idea from?

The article claims you can figure out the almost correct answer to the Monty Hall problem by running simulations hundreds of times instead of doing the maths (and the same for coin flips).

My problem is that it still relies on some mathematical intuition - that large sample sizes approximate the true distribution. Similarly bad intuition (like the gambler's fallacy) could easily be coded.

I agree that formally calculating the probabilities isn't necessary if you have the right intuition. But I believe getting good intuition is the result of training on problems (and then you can learn how to formalise it - which is the easier part).

Edit: Being good at mental arithmetic isn't necessary for programming, but being good at mental arithmetic isn't necessary for working as a mathematician either.

Being a good programmer requires thinking about things that, whether you realize it or not, are math problems. Things like managing complexity, or analyzing a program to understand what it even does. You can get pretty far just with a strong intuition, but stripped of all the syntax and culture around programming, what you're dealing with is, like, graph theory, and combinatorics, and stuff. If you recognize the concepts then you can reason about systems at a higher level and save yourself a lot of trial and error.

Or: You don't necessarily have to take math classes to be a good programmer, but the skills that differentiate a good software engineer from an LLM (previously 'code monkey') happen to correspond to things that mathemeticians would recognize and could give you a word for. This CoRecursive episode comes to mind: https://corecursive.com/050-sam-ritchie-portal-abstractions-...

This never made any sense to me. Why are so many programmers math phobic? You'd think an interest in math and an interest in programming would go hand in hand, especially since they aid and abet one another so beautifully. My programming got way better the better at math I got, and vice versa.

Math in programming is not about math, it's about careful reasoning.

Yeah, sometimes it helps to actually know math, but even when it doesn't there are some concepts that come from math and are super useful, for example: commutativity, associativity and idempotency are really useful for building robust distributed or parallel systems.

Building robust code by construction from properties of earlier code, like a proof is a great skill to have.

Making things that compose well... there are a million examples.

I mean, yeah, you can be a mediocre programmer without math but I wouldn't brag about it.

The huge problem that I have with this post is that they are trying to use math to disprove math, but badly. Also, they are using a programming language, python or any language for that matter, to prove their point, which is ALSO math. When you program you are working in an axiomatic system to achieve some goal. This goes all the way back to Haskell Curry and Alonzo Church which WAS also math. Working with math is a way of thinking and working on problems, even in probabilistic realms that errant post suggests.

I worked a bit on formalizing math using assisted theorem provers, and found that good theorems are basically well coded functions. I think both the perspectives complement each other well. The added advantage of knowing math allows one to write provably correct functions, finding their runtimes etc. In this age of LLMs spewing code, this probably is the best trick a programmer can have up their sleeves.