Hacker News new | ask | show | jobs
by altcognito 4349 days ago
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.
1 comments
cowbell 4349 days ago
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.

link
altcognito 4349 days ago
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).

link