Paper neglects to discuss CLOS approach: generic functions instead of methods, etc.
The claim that classes don't do object creation because some operator like "new" actually does that is jaw-droppingly stupid.
Classes Considered Harmful [pdf]
81–90 of 129 posts
Re: Classes Considered Harmful [pdf]
#82Computer science gets a lot of papers with arguments for a certain way of doing things. Very few with controlled experiments to find out if a way of doing things is better than another. Every time I mention this, people say that it is hard to do such experiments. Yes, it is hard to actually know things. while it is very easy to make plausible arguments, for almost anything.
Just challenge the promoter to rewrite a c++ base program in their new favorite method, paradigm. For example, the author of this paper can try to rewrite the google chrome browser - a huge C++ project in the "non-Harmful" way.
[deleted]
Re: Classes Considered Harmful [pdf]
#83The meme is becoming lame.
Talentless developers who fight and argue are the only real hazard in the world of programming.
Mature trends and languages have attracted decades of developers good and bad, and because they're widely used, they have the misfortune of also providing a home to the largest corpus of terrible code.
Mark my words: in a generation, functional programming will accumulate just as much garbage, inadequately programmed by just as many careless and/or passive-aggressive developers desperately clinging to their jobs throughout the next wave of whatever becomes the next Steve Ballmer stack ranking code review process.
It doesn't matter how many words or ideas you throw at this circumstance. Terrible developers will still manage to commit garbage.
Life finds a way.
Re: Classes Considered Harmful [pdf]
#84The practical usefulness of classes in C++ comes not from an "object-orientedness" that they supposedly give the language. It comes from the fact that they are merely a mechanism that can be used to create abstract data types, thereby providing a better encapsulation, and do many other things, rather than a policy saying that every object must be an instance of a class. So, one has to be careful when talking about cl…
The fact that C++ offers classes for building abstractions, does not imply that classes are the best (or even a good) way to do that. Also, it does not mean that the particular C++ implementation of classes is any good.
It's a good thing GP didn't imply any such thing, then.
Re: Classes Considered Harmful [pdf]
#85so, the argument is it's harmful because it's a premature optimization? the evidence being simply alternatives to classes?
It seems like the paper doesn't present a good case for why classes are harmful. Seems the whole premise if flawed based on a glib quote from Knuth
Premature optimization ( if that is what classes are ) doesn't mean the optimization is harmful. It could actually be really good.
The quote means, when you find some evil, and track it back, you'd find premature optimization. You can also find awesome code, track it back, and also find premature optimization.
So, you need to prove classes are evil, and then track it back to premature optimization. This paper fails to do that and therefore fails to make the case for harm
Re: Classes Considered Harmful [pdf]
#86The paper was a good read. I was kind of dreading it'd be another tired rehash of attacking straw men from someone who thinks having used Java or C++ makes them expert on OOP. In the early history of smalltalk Alan Kay talks about how he was never entirely satisfied with inheritance, and having inheritance in the language (quoting in full, hard to link to): A word about inheritance. Simula-I had neither classes as ob…
I was kind of dreading it'd be another tired rehash of attacking straw men from someone who thinks having used Java or C++ makes them expert on OOP.
It squarely looks like that to me. I'm not fooled by the transparent ruse of dropping a few names like Smalltalk to appear informed.
Re: Classes Considered Harmful [pdf]
#87Even in OO languages (such as Java and C#) people are routinely advised to favor composition over inheritance whenever given half a chance. Classes definitely smell (or rather reek) of the infamous 90s that inflicted such atrocities on humanity as the Rational Rose "products" and the UML "methodologies". It also goes to show why the "typescript" Microsoft strategy is ill thought. Unless of course it's simply (as I think it is) the Mother of all Embrace Extend Extinguish strategies in which case it is very cleverly thought. Sadly ECMAScript has also jumped on the OO bandwagon by offering "classes" syntactic sugar but at least it is left to the developer to use it or not, whereas in the Microsoft-land of "typescript" you get classes rammed down your throat.
Re: Classes Considered Harmful [pdf]
#88Earlier quoted context omitted.
You say traits are a rough analogue for C++ base classes with virtual methods. What are the fundamental differences?
I'm not familiar enough with the internals of how Rust handles v-tables and the like in light of its other features to answer that competently. In practice, one defines an interface in C++ by having a (hopefully) stateless class with pure virtual method declarations, and then classes derived from this class must implement these methods (in order to instantiate them anyway). In Rust one defines a data structure (eithe…
The big difference is that when you have a trait object in Rust, it's a double pointer: a pointer to the vtable, and a pointer to the data. In C++, in my understanding, you'd have a single pointer to both the vtable and data laid out next to each other.
Re: Classes Considered Harmful [pdf]
#89"I find OOP methodologically wrong. It starts with classes. It is as if mathematicians would start with axioms. You do not start with axioms - you start with proofs. Only when you have found a bunch of related proofs, can you come up with axioms. You end with axioms. The same thing is true in programming: you have to start with interesting algorithms. Only when you understand them well, can you come up with an interf…
I think this is more based on the early methodology advice for developing OO software. But the methodology is independent of the constructs (though often limited by it).
In practice these days often the most effective way when developing OO code is working the "proofs" till you have a set of classes.
Also, some people go for very FP inspired OO code.
Re: Classes Considered Harmful [pdf]
#90Earlier quoted context omitted.
Embedding and delegating don't deal very well with virtual dispatch afaik. Declaring different implementations for arbitrary sub-classes seems harder and less elegant without inheritance.
But virtual dispatch is trivial to add where you actually need it, a bunch of function pointers in a struct and you're good to go. And once you stop viewing the world through the OOP filter there aren't that many real hierarchies and interfaces left to deal with. The curse of OOP is that it turns problem solving into day dreaming, with expected results.
OOP isn't the solution to every problem. Your proposed replacement to inheritance would would work nicely in some cases. As far as I can tell, it doesn't address the use case of generic classes at all, at least in a type-safe way.