4 ms·
> Having never needed to build my own sorting algorithm in 14 years of coding, Neither have I. What I have had to do is recognize when I could do what I needed
by saulrh 8y ago
> Having never needed to build my own sorting algorithm in 14 years of coding,
Neither have I. What I have had to do is recognize when I could do what I needed to do without sorting the array, understand various requirements when I'm writing comparison functions, understand why std::list::sort exists when std::sort is right there, debug a stalling mapreduce job, recognize when a library I'm using has done a stupid and written an intrusive data structure that sorts in N^2, etc. Are you seriously claiming that you'd be able to do any of that if you didn't know how sorting algorithms worked? If those things aren't in the documentation, or if you run into the intersection of that thing and some other issue, you're hosed unless you know the math.
For that matter, why are you so focused on sorting? You know what I have to write all the time? Tree and graph traversals. Why does it matter if I use a stack or a queue if my traversal will visit every node anyway? Why can I get away without maintaining a set of visited nodes in one case or the other? Hell, I have to implement something very much like a toplogical sort once a year or so. That's not something you'll ever learn by groveling over for loops in fifty languages.
I agree that you rarely need an explicit "algorithm". What you do need, regularly and consistently and on a basic level to write correct code that is usable in the real world, is knowledge of algorithms. In a perfect world everyone would know from reading the docs and from staring at stack frames that their code gets slow when they use particular data structures and libraries. We do not live in a perfect world. The engineer that cannot write a single sorting algorithm is not the one that just uses library functions for everything and is fine in the end. The engineer that cannot write a sorting algorithm is the one that writes a jumble of for loops and you improve runtime from eight minutes to eight seconds by replacing it all with hashes. The engineer that cannot write a sorting algorithm is the one that designs an API that fundamentally requires server-side session state that grinds to a halt at ten QPS. These are people that I have worked with. In every case the fundamental issue was that they had "started learning about the applications of the syntax" and never studied formal CS theory.
- hesarenu 8y agoDepending on you work you don't need to use it again. I have not used it for a decade. I somewhat remember the theory. For interview i can just memorize it.
- webmaven 8y ago> The engineer that cannot write a sorting algorithm is the one that designs an API that fundamentally requires server-side session state that grinds to a halt at ten QPS I've come cross more than a few "can write a sorting algorithm" engineers that nevertheless design APIs requiring server-side session state, or that have gone ahead and implemented a sorting algorithm embedded in the server-side HTML template. Knowledge of algorithms is not a panacea.
- saulrh 8y agoOf course it's not sufficient. I don't even think it's necessary. But, generally speaking and in my experience, formal algorithms knowledge is incredibly useful, and you are at a significant disadvantage if you do not have it in your toolbox.
- webmaven 8y agoOf course knowledge of algorithms is useful. I was pointing out that a specific correlation you mentioned wasn't particularly robust, and certainly didn't amount to the causation you were implying. Perhaps I should have made my point more explicit by noting the existence of counterexamples - engineers that design and implement good APIs without any particular knowledge of CS or the implementation of sorting algorithms. You actually are conceding my point when you admit that knowledge of algorithms isn't even necessary.