Firstly you're almost always wrong about what you think will be slow. Add to that it's rare you actually know how a programm will really be used.
Secondly most programs never get stressed so it was a complete waste of time.
Third, you just made the program complex for no actual good reason, just inexperience and flawed logic.
So all that knowledge, those tools, is useless and we know it is. You could fill volumes about the cock ups and bad code caused by premature optimisations.
A for each. That's what you'll use 80% of the time, a for 20% and your algos 0%, for all intents and purposes.
If you don't have a good idea of what is likely to be slow, we have a problem. It's usually I/O, especially synchronous network I/O.
During initial development, maybe you don't know how a program will be used, but maintenance is usually a bigger phase than initial development, so you should have some idea of how things are used.
> Secondly most programs never get stressed so it was a complete waste of time.
What are you working on? Everything I've worked on that has users could go faster. It doesn't take that much complexity to get something that takes 100 ms; and making that take 50 ms instead is an easily perceptible difference.
> So all that knowledge, those tools, is useless and we know it is. You could fill volumes about the cock ups and bad code caused by premature optimisations.
You could fill volumes about the cock ups and bad code caused by completely garbage performance because people didn't stop to think about how to do things right. Simple things like reducing the number of round trips to the database, or avoiding calculations until you know you need them could be called premature optimizations or just doing the job right. Having knowledge of algorithms (and knowing what algorithms are likely to underly the abstraction layers you're using) helps you avoid writing code that will blow up.
Saying it's "I/O" is so abstract and ultimately useless. A simple SQL query could hold a dark secret of a missing index on a table with a billion rows. Yes, that's technically I/O, but for today's programming that's so obtusely abstract it's pointless calling it that. It's a couple of lines of code that all the algo knowledge in the world won't have stopped the problem happening.
It's simply common sense. This is what we're trying to tell you. This is what we're trying to explain to you. Performance problems are almost always unintended consequences rather than "I'll suck it and see". Knowing how to implement the sort yourself won't save you, you have to spot the problem first, which is the hard part.
Basic multiplication is not algos. Knowing that a 100 loops of a thousand loops of a 1ms method is bad doesn't require magical knowledge. Algorithms was always a smoke and mirror trick, the ones you need are usually already in your language written much better than you could and the rest simply hides the truth that performance is mainly down to unexpected I/O bottlenecks usually buried under many layers of abstraction (SQL) or the occasional loop within a loop hidden in a long call stack.
I accept the point that over optimizing is the root of all evil and the rest of the philosophy along those lines. But knowing algorithms and data structures inside out, because where and when you have to choose what - i doubt one can be called a programmer without all that.
And i would say again, i am yet to find some body renowned, who has made their mark as a programmer, and doesn't regard all of this stuff high enough.
Having said all that, if you work in a high level language and develop client facing / application layer desktop/web related stuff - and not involving too much scaling, you won't need these things most of the times. But if not, you can't live with out these.
Lastly, since college and probably since learning to program, the best of the breed usually were the guys who went on to acm and top coder kinda stuff. It is true that building products is not synonymous, but it definitely plays an undeniable part albeit i must agree that it is slightly over valued, nothing else.
And who is renowned in this industry? Game programmers. Not Sass, enterprise or consumer web programmers, who make up the vast majority of working programmers. No, one of the tiny subsets of programmers who do need algos.
You're stuck in your own bubble thinking it's bigger than it is (and seemingly thinking it's "proper" programming). So you're wrong because your premise is flawed. 95% of programmers do "high level language and develop client facing / application layer desktop/web related stuff". Simply open a job website and search for "developer". Add them up by SASS/Enterprise/Consumer Web and then everything else. The first category will be much bigger, 20-30 times bigger.
So the whole line of reasoning is irrational to me. Never tried saying systems programming is more main stream then web or desktop or enterprise.
Talking about renowned, Yes people who have written kernels, operating systems, network stacks / protocols - there is huge list of renowned ones. Do you want me to spell the names out starting with Torvalds or Stallman?
One of the biggest culprits of truely awful programs are graphics card makers. I bet they all know algos, the problem is that they think they know how to program when they're little more than amateurs or hobbyists.