Academics should stick to pure computer science

Every time the academics try to wet their flaccid noodle in the soft, warm crevices of actual programming, they prematurely squirt all over it, and don't get any of their gooey information inside. I'm coming at this from the context of compilers, but I'm sure it applies to most areas. I don't think that anyone could disagree that tomes such as TAoCP are anything less than holy scripture and should be read by anyone who thinks to call them-self a programmer, but beyond that, it's done nothing but waste time. For instance, pure functional programming. Like most academic things, it promises beauty and simplicity and millions of optimizations that can be done. Where are these optimizations? In the math of course. Problem is, most of them never bother to implement them, and on the rare occasion that they do, it's some toy that only shows that particular optimization on a particular instance on a particular program.

The damage comes in when legions of pseudo-intellectuals argue for the style used on the basis that it can merely be shown to allow these optimizations. The rate at which such things actually occur are probably less than one or two percent. Besides looking particularly ``mathy'' in syntax, the result is usually purposeless and never delivers one any of the promises that were theoretically possible.

>>21

Subclassing errors, OOP style and practically checkable to prevent them

Oh, I missed that. I don't find it impressive at all: all operations always produce objects of the base type and you have to manually cast it back to the derived type every time (constructing a new object, and that's the only place where customization can happen). It doesn't look as stupid as it actually is only because it's pre-C++11, now try to write some code manipulating sets accidentally using auto and see what happens. I mean, the only good thing about this approach I can see is that it makes any inheritance retarded, which also covers inheriting Set from Bag.

As for his second example with an abstract base class, I totally don't see anything that would prevent me from making an abstract IBag, then implementing it with concrete CBag and CSet and hitting the original problem again.

I think that you guys don't see the forest for the trees here. It boils to this: you decide that you want to pass a Set object to a function that takes Bags, either you can do that or you can't. If you can (and I don't care how, use higher-order functions for all you want) then you have a bug because you shouldn't have done that. If you can't then nobody will use your toy language because you have to cut out everything useful to forbid yourself from doing that.

Also for your information ``unityped'' is a valid, actual term used in type theory.

I know, that's what I meant by brain damage.