[cowbell]

Learning a programming language is a lot like learning a human language, but understanding math is how you learn efficient programming.

If you don't use mathematical reasoning, then you'll produce O(n^3) when you could have produced O(n). Any hack can throw together a script that will hobble along with 4 rows of data. Throw a million rows at the same script and it might terminate properly in a few years. Or maybe it just runs out of memory half way through.

Another problem is winding inefficient boolean branching. If you don't understand boolean algebra, you either over specify cases which makes code cluttered and disorganized, or you under specify and some cases are not considered at all... The result in either case is always buggy code that crashes. It becomes like a virus. Other lesser programmers are afraid to fix it, because it's so complicated. Instead, they just tweak the mess to accomplish their own goals, adding more bad boolean logic along the way. It infects everything it touches.

Finally, certain fields of programming, like machine learning, are almost entirely math and statistics. So, yeah, you don't need math to (poorly) do programming (in certain fields).

[altcognito]

You don't need mathematical reasoning to realize that loops within loops generate slowness.

And as far as under-specifying versus over-specifying, I find that understanding the domain problem is better inoculation against horribly written code than understanding "inefficient" boolean branching.

> lesser programmers are afraid to fix it

Red flag.

[cowbell]

It isn't just loops. It's everything.

http://highscalability.com/numbers-everyone-should-know

If you just had to say "avoid nested loops" there would be no problem. Programming a solution that works at scale requires math and understanding where you will have bottlenecks before you write a single line of code.

>understanding the domain problem is better inoculation

How does one understand a problem without understanding boolean algebra?

Example. You have good/bad credit, car/motorcycle, new/used, drivers license yes/no. Which combinations allow testDrive()? Now add condition 'ok' to credit, moped and 18 wheeler to vehicles, and commercial to driver's license, because the boss forgot about those. Now how many combinations? Who is allowed to do what? How do you arrange the code so you don't spend time evaluating methods when driver's license of 'no' can short circuit the entire operation? (oh, except for moped, in certain states)

That's entirely boolean logic. If a person is not good at that, they suck at programming AND understanding domain problems.

[altcognito]

I'd be more worried about making the code readable and easy to modify than high performance. You realize this is at best 5-10 OPS right?

Because in 12 months, nobody is going to know that you saved 2 operations by cleverly "arranging" your code.

I'm not saying you shouldn't arrange your code as best you can, but performance in this situation would absolutely be secondary to readability.

The link you give has nothing to do with the topic of math. It's mostly about knowing how your application is interacting with the system and a basic pragmatic approach to lock contention (also not math).