[edw519]

There are too many non-trivial algorithms that you are just likely to not rediscover.

I agree, but would also (respectfully) ask, "So what?"

OP needs to learn to crawl, then walk, then run. And he seems like a great candidate to do all 3.

Even so, even if he works 30 years having a ball delivering great product to satisfied customers, he may never encounter "Fast Fourier Transform" or "stability of Gaussian elimination".

I think of "advanced" subjects like dynamic programming, functional programming, and even algorithms and low-level code like mountaineers think about Mount Fuji: A coward never climbs it. A fool climbs it more than once.

I haven't written a b-tree traversal in 10 years and hope I never do again. I'd rather stand on the shoulders of new giants and get other cool stuff done.

OP's not there yet. Give him time.

Also, he needs a reason to learn this stuff. "Because I need it for this project" is a better reason then "Because everybody else is doing it and I think I need to, too".

[Vivtek]

"Because I need it for this thing I'm doing" is the only motivation that ever works for me. That said, taking that weekend to read the book to know what might actually be available for that thing you're doing is also a good thing to do periodically.

[russell]

Let me echo VivTech. You dont need to memorize all the algorithms and variants, but you do need to know what is there, so that sometime later when you need a solution, you know where to look. Also you need to dive deeply into some aspect such as sort or lists so that you get a good feel for big O notation and analysis. You may never implement a sort or tree algorithm, but is good to know which one to pick when you need it.

I've never had to use FFT, but sorts, trees, and graph traversal are pretty common.

My introduction to algorithms oh so many moons ago was Sedgewick when it was a single volume in C(?). I found it easy to read and use.

[neutronicus]

The problem is that there are a lot of projects you can go into as a cargo cult programmer, do an OK job, and come out more or less still a cargo cult programmer - you can build a pretty good web site by iterating on tutorials and copy-and-pasted snippets.

If you follow the guidance of, say, SICP, there're "projects" geared to expand your abilities.

So, I agree, but look for the right project - don't learn a framework, learn to do something.

[cabalamat]

>> There are too many non-trivial algorithms that you are just likely to not rediscover.

> I agree, but would also (respectfully) ask, "So what?"

Well, if you're trying to sort big arrays with bubblesort, you may have to wait a long time...

[Jach]

http://warp.povusers.org/grrr/bubblesort_eng.html

>Teaching bubble sort as some kind of "basic sorting algorithm" has real-life negative consequences. This is a real-life example: this is a piece of code in the gnu flex program:

    /* We sort the states in sns so we
     * can compare it to oldsns quickly.
     * We use bubble because there probably
     * aren't very many states.
     */
    bubble (sns, numstates);

>There's absolutely no rational reason why bubble sort was used here instead of insertion sort. Bubble sort can only be slower, and it's not in any way easier to implement.

[cgoddard]

Actually for small values of n, an n^2 sort can be quicker than an nlogn sort, depending on how it is implemented.

[Jach]

Yeah, hence insertion sort (the best n^2 sorter) is used to speed up quick-sort. It's insane to think of using bubble sort for the same task. (And for n=2, you don't need a sorting algorithm.)