4 ms·
It's not about knowing the complexity of every possible sort function. It's about having a good base to stand on, a nicely sized toolbox. If you're working on
by vinkelhake 13y ago
It's not about knowing the complexity of every possible sort function. It's about having a good base to stand on, a nicely sized toolbox.
If you're working on a solution to an actual problem, it's a pretty damn good to have an idea about the complexity of it. You don't need to be an expert, but developing some kind of intuition for it is very helpful.
If your attitude towards these things is "I'll just Google it" then you're not going to be quite as useful when it comes to discussions. Your toolbox needs to be bigger than that.
- mattmanser 13y agoAgain, what's the point of having a tool you never use? I have had to implement a sort once in 10 years of professional programming, it was in IE6's painfully slow js to fix a slow table sort. More than most. I didn't do a CS degree, the people around me with CS degrees didn't know the answer. I googled it. After the 15 minutes it took to find and implement it I mentioned it to one of the CS people, he promptly reeled off the definition to me, but couldn't see how it solved the problem. Give me someone who never cuts and pastes over someone who know algos any day.
- ahomescu1 13y agoIt'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.
- mattmanser 13y agoIt'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.
- fayyazkl 13y agoDepending 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.
- mattmanser 13y agoHigh 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.
- fayyazkl 13y agoI 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?
- cunac 13y agoit 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.
- ahomescu1 13y agoI 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.
- mattmanser 13y agoNo. 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.