How much effort do you put into understanding them? As with everything, the more complicated something is (or the further away things are from what you're familiar with) the more you have to put into it.
If you're interested in understanding them, I recommend finding another source for the explanation, like Wikipedia. The ones on stackoverflow can be a little short for an adequate explanation.
Also, there's a limit to how much you can understand by just reading something. Try drawing it out.
And in the end, I'm not sure how much understanding this stuff relates to your need for developers, depending on what you're doing. Most web programming involves getting cogs to fit with other cogs, not advanced algorithms. Obscure data structures are generally obscure for a reason; they're more an intellectual curiosity than anything else ^-^.
> Obscure data structures are generally obscure for a reason; they're more an intellectual curiosity than anything else ^-^.
I don't think that's necessarily true, the problem is that there are so many of them.
Consider woodworking. A good woodworker has an absolutely enormous array of tools, and all a woodworker does, if you think about it with the mindset of a non-woodworker is remove bits of wood from other bits of wood and put them back together again.
Algorithms are the tools in the toolbox of the programmer, all we do is transform series of bits in to other series of bits. But the number of algorithms is huge compared to the number of tools a woodworker uses, and it is impossible to remember all of them, to pick the one that is 'most appropriate' for the problem at hand.
So we may end up using a sub-optimal solution quite a few times when one of the 'obscure' algorithms would have been more appropriate, just because computers are for the most part fast enough to cover for the inefficiencies.
To extend your analogy though, obscure algorithms could be like the techniques that allow master craftsmen to build beautiful, solid furniture using only careful joins and maybe light wood glue. On the other hand, what most people want is something quickly and cheaply assembled from standard parts from IKEA.
The most practical lesser known types for my day to day programming are:
- element trees (etrees), partiocularly lxml implementation. Simple insert and append operations at xpaths (eg /body/html/table/tr[3]/td[7]), iterating over children, accessing element properties as object properties.
- dependency graphs (aka graphs). I have no idea why they're called graphs (I did business, not CS) but anywhere you have dependencies to store and work out (say for a project management app, or a packaging tool) these are the best fit.
That's why every time I look at the un-hyped kind of work I do on a daily basis writing system level C++ applications and bootloaders and begin to get depressed, I just have to think about how much fun and how mentally stimulating it really is and I get a smile on my face :)
Behind every website there is hopefully something new and exciting that is fun and interesting to build. The front-end part and all the glue layers not so much.
Comments
Nothing makes me want to hire developers like reading lists of algorithms and discovering I don't understand them.
How much effort do you put into understanding them? As with everything, the more complicated something is (or the further away things are from what you're familiar with) the more you have to put into it.
If you're interested in understanding them, I recommend finding another source for the explanation, like Wikipedia. The ones on stackoverflow can be a little short for an adequate explanation.
Also, there's a limit to how much you can understand by just reading something. Try drawing it out.
And in the end, I'm not sure how much understanding this stuff relates to your need for developers, depending on what you're doing. Most web programming involves getting cogs to fit with other cogs, not advanced algorithms. Obscure data structures are generally obscure for a reason; they're more an intellectual curiosity than anything else ^-^.
> Obscure data structures are generally obscure for a reason; they're more an intellectual curiosity than anything else ^-^.
I don't think that's necessarily true, the problem is that there are so many of them.
Consider woodworking. A good woodworker has an absolutely enormous array of tools, and all a woodworker does, if you think about it with the mindset of a non-woodworker is remove bits of wood from other bits of wood and put them back together again.
Algorithms are the tools in the toolbox of the programmer, all we do is transform series of bits in to other series of bits. But the number of algorithms is huge compared to the number of tools a woodworker uses, and it is impossible to remember all of them, to pick the one that is 'most appropriate' for the problem at hand.
So we may end up using a sub-optimal solution quite a few times when one of the 'obscure' algorithms would have been more appropriate, just because computers are for the most part fast enough to cover for the inefficiencies.
To extend your analogy though, obscure algorithms could be like the techniques that allow master craftsmen to build beautiful, solid furniture using only careful joins and maybe light wood glue. On the other hand, what most people want is something quickly and cheaply assembled from standard parts from IKEA.
That's a good way of putting it.
Toolmaking is one of the nicest forms of programming that I know of anyway.
If only the daily grind of programming would require interesting algorithms more often. Certainly not the case for web development :-(
The most practical lesser known types for my day to day programming are:
- element trees (etrees), partiocularly lxml implementation. Simple insert and append operations at xpaths (eg /body/html/table/tr[3]/td[7]), iterating over children, accessing element properties as object properties.
- dependency graphs (aka graphs). I have no idea why they're called graphs (I did business, not CS) but anywhere you have dependencies to store and work out (say for a project management app, or a packaging tool) these are the best fit.
That's why every time I look at the un-hyped kind of work I do on a daily basis writing system level C++ applications and bootloaders and begin to get depressed, I just have to think about how much fun and how mentally stimulating it really is and I get a smile on my face :)
Behind every website there is hopefully something new and exciting that is fun and interesting to build. The front-end part and all the glue layers not so much.
(pet peeve: browser incompatibilities :( ).