[rpedroso]

I primarily write python web-based APIs for a web application + 2 mobile apps. Just the other day, I was dealing with an endpoint that had to update hierarchical data (i.e. a collection of trees).

Due to the circumstances, normalization wasn't an efficient option. I ended up throwing together a barebones tree with a 5-line DFS implementation to traverse it. It handled inserts, updates and deletions (for my use-case) in linear time.

The details aren't so important as the fact that adding a dependency would have been overkill for my needs. This isn't to say that efficient graph implementation libraries should not exist or be used, but I was able to produce this code faster by having that basic CS knowledge.

[lordCarbonFiber]

And because your code was implemented in python (rather than use prebuilt libraries that call back to C) it was 100x slower than it should have been. Im all for knowing the fundamentals but there is a strong argument for knowing the right tool for the job.

[joshuamorton]

And because it was attached to a web api, it was likely still io bound, so it didn't matter.

Context and knowing the right tool for the job is important indeed.

[fencepost]

re: the debate between Python being slower and C faster, it all depends on context. If the context is "this is going to be called multiple times for every transaction" then yeah, look into recoding it. If the context is "this is going to be called for this particular edge case and may execute 10 times a week and take an extra 3 seconds each time" then there are more productive places to put your energy.

At the level of programming that the grandparent is talking about, I'd accept the judgement of the programmer working on it as to the appropriate solution.