HN user
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.