3 ms·

> I work predominantly with server-side, interpreted languages, and I just don't run into the bottlenecks and performance problems that Big O-knowledge seems t

by strlen 15y ago

> I work predominantly with server-side, interpreted languages, and I just don't run into the bottlenecks and performance problems that Big O-knowledge seems to mitigate. Algorithmic complexity isn't about performance, it's about scalability. A hand-written implementation in assembly that's O(N^2) will be slower than an implementation in Basic that's O(N) (or even O(N log N)) for a sufficiently large N. I suggest picking up Programming Pearls, they had an example of a BASIC program on C64 vs. a Fortran program on a mainframe (the book is from the 80s) demonstrating this. That said, if building basics web apps is all you want to do (e.g., internal enterprise applications) then you don't need this knowledge. However, the harder stuff (whether algorithmic, systems, etc...) like (but not limited to) what Palantir works is what I find more interesting.

glenjamin 15y ago
The problem with this is, in most cases you're not dealing with sufficiently large N - plus the high-level language of choice will already come with an efficient sorting algorithm for whatever lsit type it provides. Whenver you do start to approach values of N for which you need to fine tune, you're going to be researching and profiling and optimising the hot code anyway. I'm not saying you don't need to know algorithms, but you don't need to know the big O for every sorting algorithm / insertion cost to each type of tree off the top of your head. A rough idea of whats terribly inefficent is fine for most tasks.
- Thrymr 15y ago
  Maybe. But it is terribly easy in a high level language to use a built-in function that is O(N) and put in in a loop, and now you're at O(N^2). Maybe it works in reasonable time for N=10,000. Maybe you test it on small data sets to see that it works. Now turn it loose on an N=10^7 dataset. Oh.
yason 15y ago
That said, if building basics web apps is all you want to do (e.g., internal enterprise applications) then you don't need this knowledge. Watch it before deploying those big joins that worked so nicely on your development data set, then.

by strlen 15y ago

glenjamin 15y ago

The problem with this is, in most cases you're not dealing with sufficiently large N - plus the high-level language of choice will already come with an efficient sorting algorithm for whatever lsit type it provides. Whenver you do start to approach values of N for which you need to fine tune, you're going to be researching and profiling and optimising the hot code anyway. I'm not saying you don't need to know algorithms, but you don't need to know the big O for every sorting algorithm / insertion cost to each type of tree off the top of your head. A rough idea of whats terribly inefficent is fine for most tasks.

Thrymr 15y ago
Maybe. But it is terribly easy in a high level language to use a built-in function that is O(N) and put in in a loop, and now you're at O(N^2). Maybe it works in reasonable time for N=10,000. Maybe you test it on small data sets to see that it works. Now turn it loose on an N=10^7 dataset. Oh.

yason 15y ago

That said, if building basics web apps is all you want to do (e.g., internal enterprise applications) then you don't need this knowledge. Watch it before deploying those big joins that worked so nicely on your development data set, then.