victor___

It seems like the debate boils down to "should subclasses be able to override behaviour in ways the base class doesn't anticipate?".

Pro: sometimes it lets you extend classes in useful ways that the original author didn't anticipate. Con: it makes it difficult or impossible to reason about invariants in the base class.

Seems like it's a trade-off between hack-ability and robustness.

I interned at Facebook a while back (pre-IPO). On the first day of onboarding my neighbor was struggling to follow the instructions - it turned out he'd never used bash or any Unix-like system before.

Anyway, I guess he figured it out since he did well enough to get a return offer.

Apparently things have changed a bit.

I agree. Turns out being able to understand, evaluate and communicate about multiple perspectives on abstract concepts is a generally useful skill.

I think it depends on the individual and the class. With several philosophy classes I saw scores on weekly papers go from around 9/10 to around 5/10 if I tried to wing it and do it at the last minute.

I don't think pulling out the number 6 separately from the constant factor results in an apples-to-apples comparison with other operations with logarithmic complexity.

The 32-way tree operations have asymptomic complexity 6 * C_1 * log(n) = C_2 * log(n)

Operations on a balanced binary tree have asymptotic complexity C_3 * log(n) = 6 * C_4 * log(n).

The only difference between the two data structures is the actual values of the constants.

I think the Scala people have a valid point that logarithmic complexity may be as good (or nearly as good) as constant-time in practice. The precise way the claim is formulated is wrong and abuses big-O analysis.

A more correct argument is to choose a practical upper bound on log(n). E.g. maybe 64. Then multiply that by the constant factor (not playing any tricks with splitting out 6 *). If that number is always good enough if practice, then you don't need to worry about your operation being logarithmic.