It's not about "sorting" or any particular algorithm, it's about whether you're actually considering the costs and tradeoffs of the code you're writing (which is actually a big part of software engineering), and are equipped to handle those. Now, one cost is execution time, another is memory usage, another is development time, another is maintenance effort and so on. These costs are spread across different domains, but it's important that a programmer considers them.

It's really not a big part (apart from the rare times when it is).

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.

> 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.

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.

Reducing the round trips to the DB or doing calculations when you need them need no knowledge AT ALL of algos.

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.

Depending upon what sort of industry and scale you write code for, very often, it is a HUGE part.

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.

High level language? I haven't heard that kind of condescension in years. Whatever you're working on isn't as hard as you think it is. Most experienced programmers could probably do it as well as you in a couple of months.

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.

I never tried stating it was hard, or making it look like it is main stream. I just said that depending upon the domain you work in, Algorithms and data structures might be more important and you might encounter them more often then in web or desktop, than an average programmer does.

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?

it seems to me that people with 10+ years of experience have more empirical evidence what is actually needed/useful. Your comment and other similar ones sound to me as textbook material which is abstract and correct in principle but not exactly how it is when you spend some time in industry.

I have my own empirical evidence as an user: a lot of software I use is slow or uses too much memory, or has memory leaks. As a programmer, I keep wondering if those could have been averted if the programmers working on that code would have used better/more efficient algorithms, instead of just going with the simplest solution.

No. It's not. It simply inexperienced programmers. I bet they even have CS or EE degrees.

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.