[Trey-Jackson]

IMO, 99.9% of the time you don't need the more obscure data structures. And I speak from experience working in companies on software requiring high performance (runs taking 6 hours to two days are not uncommon).

That said, I was disappointed nobody had added the corner stitched data structure - I found that to be a very intriguing idea (and in my world, it turned out to be very useful).

[ominous_prime]

> IMO, 99.9% of the time you don't need the more obscure data structures

Absolutely, and familiarity with these data structures is what's required to prevent these mistakes. I think a good understanding of these is more likely to prevent one from using them, or in some cases, "inventing" them.

[earino]

huge point. Nothing like seeing someone hand-implement (poorly) a balanced tree.. and usually be very proud of it.

[Trey-Jackson]

That's a fair point.

Though another way to avoid making the mistakes is to not invent data structures. That's what libraries are for, and anyone not using a library data structure should be able to defend why they're not. Odds are, they've got no chance of writing something better than what the libraries provide (or they'd be a library writer and already know these things).

[cpeterso]

I've heard someone joke that "real world" software uses just two data structures: arrays and hash tables.

1. An array can implement a stack or queue and is often cache-friendlier than a linked list of nodes scattered throughout the heap.

2. A hash table can implement a map or set for fast lookups of unordered data.