Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Classes Considered Harmful [pdf]

web.cecs.pdx.edu

Post reply on HN
Print view View original

111–120 of 129 posts

Re: Classes Considered Harmful [pdf]

#111

Post by naasking »

hifier wrote: post #96
wyager wrote: post #63

Earlier quoted context omitted.

Superior composability with simpler semantics and sounder type systems. Class hierarchies are inherently unfriendly to strong, sound type systems. Interface composition isn't. Composing interfaces is clean and straightforward. Composing classes isn't, and you run into things like the diamond problem.

Classes do not imply inheritance. Classes are a means of defining an interface, albeit a heavy one. The statement that it is better to separate data and behavior is far from self-evident IMO, and I would be very interested to understand why this is such a deeply held belief. Seriously, why?

> The statement that it is better to separate data and behavior is far from self-evident IMO, and I would be very interested to understand why this is such a deeply held belief. Seriously, why?

Data is and always has been more valuable and more important than behaviour. It's not unheard of to preserve accounting data that's decades old, even though the accounting system itself changed completely many times. The converse, preserving old programs to run on brand new data is much more rare.

The whole hoopla around big data should make it clear where the real value is. Behaviour is merely a way of transforming data, and coupling the two rarely works well in the long run. The only times it's actually advantageous is to preserve invariants that ensure input or output data is well formed. For instance, data structures that ensure or preserve orderings, etc.

Re: Classes Considered Harmful [pdf]

#112

Post by jaredklewis »

non_repro_blue wrote: post #83

The 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, in…

I feel this counter meme (programming languages/language features/paradigms aren't bad, developers are) also get's thrown around a lot, but I don't understand the argument.

Are all languages really equally good? Is C really no more productive than assembly? Is Swift really no more productive than Objective-C? For many higher level applications is Java really no more productive than C? Doesn't using something higher level like Python make certain kinds of tasks easier than the same task in Java?

Since the inception of programming languages, there has been continuous improvement of the existing languages as well creation of new languages, both of which have introduced new paradigms and features to programming. These new features and paradigms often replace older features and paradigms. Not everything works, but much of the time the new features and paradigms have made writing and maintaining good programs much easier.

Unless you believe our current tools are already completely optimal, it seems only natural to try to improve upon them.

So is your argument that programming languages in a generation will be equal productive/un-productive as what we have now? That seems too pessimistic to me. I think our tools will be much better, just as I feel our tools now are better than they were in 2000 or 1990.

If the argument is that functional programming is not an improvement, that's fine, how do you see languages improving? What's the direction they should take?

Re: Classes Considered Harmful [pdf]

#113

Post by mjevans »

cousin_it wrote: post #75
biocomputation wrote: post #71

Earlier quoted context omitted.

>> but also provide implementation inheritance, which is bad. Inheritance isn't bad. Abusing inheritance is bad. For the record, you can also abuse composition, polymorphism, operator overloading, free functions, interfaces, records, and abstract data types. I've abused them all and seen them abused as well. Inheritance is just another tool. Like all tools, we are expected to use them wisely.

Do you know any situations where implementation inheritance is the best tool?

I mentioned one such example about 6 hours before your post.

As the other reply stated, when you mostly want to keep the base class but over-ride a small specific subset of what it does.

E.G.

The base class uses class member functions to do save/load records from a store.

You want to implement a variant of that class which instead works well with a database engine you like.

You can then derive a class and define JUST the storage and recall functions, and inherit everything else.

Re: Classes Considered Harmful [pdf]

#114

Post by non_repro_blue »

jaredklewis wrote: post #112
non_repro_blue wrote: post #83

The 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, in…

I feel this counter meme (programming languages/language features/paradigms aren't bad, developers are) also get's thrown around a lot, but I don't understand the argument. Are all languages really equally good? Is C really no more productive than assembly? Is Swift really no more productive than Objective-C? For many higher level applications is Java really no more productive than C? Doesn't using something higher l…

Turing tarpits aside, people speak very highly of C, just as they may do the same for assembly, but depending on context.

Languages fill a niche, and outside of their area of utility it's easy to notice weaknesses.

But arguments in favor of functions are similar to those in favor of objects. They both joust for the award of being adept at doing more with less code, in terms of mythical-man-month project scalability.

I've experienced that problem with huge OOP code trees, and I still don't foresee Pure Functional programming supplying a cure for that problem. Maybe I'm just not one of the lucky ones yet. I don't know.

But when I read Pure Functional code, even though it's tighter, with less boiler plate, it doesn't feel like honest improvement. It's like Coke or Pepsi, McDonalds or Burger King.

OOP might yeild thousands of source files and hundreds of lines per some files, but if a Pure Functional project does the same thing with fewer lines of code in fewer files, it's still doing the same thing.

So in a decade you'll probably find the same complaints, in the same places, but at least people will have different hair styles.

Re: Classes Considered Harmful [pdf]

#115

Post by codr4life »

recursive wrote: post #90
codr4life wrote: post #49

Earlier quoted context omitted.

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.

Generics and OOP are orthogonal, one does not depend on the other. So let's say you declare your vtbl struct with a generic parameter, what's the difference?

Re: Classes Considered Harmful [pdf]

#116

Post by codr4life »

ktRolster wrote: post #99
codr4life wrote: post #44

Earlier quoted context omitted.

Why do we need inheritance? Embedding and delegating can handle any task but the silly ISA pretend game.

It is a convenient extra piece of flexibility. When you want to extend code in the future, inheritance can make it easier.

Sorry, not buying that one. There's nothing in inheritance that makes extending code easier. You either design for extension or not, has nothing to do with OOP.

Re: Classes Considered Harmful [pdf]

#117

Post by codr4life »

keithnz wrote: post #89
codr4life wrote: post #73

"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.

Those are clearly exceptions to the rule, though. You can write sort of Haskell in any language, OOP is still bullshit.

Re: Classes Considered Harmful [pdf]

#118

Post by euyyn »

codr4life wrote: post #49
recursive wrote: post #47

Earlier 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.

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

Or let the compiler do it for you? It's like saying I shouldn't use first-class closures, because they're also trivial to implement manually where I actually need them.

Re: Classes Considered Harmful [pdf]

#119

Post by cousin_it »

mjevans wrote: post #113
cousin_it wrote: post #75

Earlier quoted context omitted.

Do you know any situations where implementation inheritance is the best tool?

I mentioned one such example about 6 hours before your post. As the other reply stated, when you mostly want to keep the base class but over-ride a small specific subset of what it does. E.G. The base class uses class member functions to do save/load records from a store. You want to implement a variant of that class which instead works well with a database engine you like. You can then derive a class and define JUST…

Interfaces are a better tool for that case IMO. One small utility interface (save/load) and two implementations would be easier to test in isolation and wouldn't suffer from the fragile base class problem.

Re: Classes Considered Harmful [pdf]

#120

Post by bjourne »

I like Factors (http://factorcode.org/) approach to classes. In that language, a class is a category and not a "mold" from which objects are created. E.g, I can say the following:

    33 number?
    t
    33 integer?
    t
    integer number class
The last two lines demonstrates a little of the class algebra possible. It says that if an object is an instance of the integer class, then it also an instance of the number class and of the object class. That is, the set of objects that are integers is a subset of the set of objects that are numbers which is a subset of all objects.

I can add new classes which refines categories of existing objects:

    PREDICATE: positive  ;
    PREDICATE: prime-number
Note that both real and integer values can be "positive" which means that "positive" isn't a strict subset of either class. That kind of refinement isn't possible in most oo languages.
Post reply on HN