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

How Class-based Programming Sucks (2011)

loup-vaillant.fr

Post reply on HN
Print view View original

81–90 of 147 posts

Re: How Class-based Programming Sucks (2011)

#81

Post by emn13 »

delinka wrote: post #38
zeteo wrote: post #23

Earlier quoted context omitted.

>The thing about [OOP] is that it allows you to model a problem domain in real-world terms. That's only true on a superficial level. Sure, in CS 101 it's easy to explain how to make a Point object and add a Move() method to it. But dive into any real-world code base and you're more likely to meet RectangleCollectionColorPickerFactory instead. Let's face it, writing a large program is an exercise in abstract symbol ma…

"... RectangleCollectionColorPickerFactory ..." Sounds like you're blaming the OO world for Java's problems. But I digress... Trying to make code correspond to real world objects is annoying because after you've modeled your Car with Wheels that support Tires, and an Engine with EngineParts attached ... you then have to write a adaptation layer to make all that fit into your storage engine, your user interface, your…

It's not just java - any good OO platform has those problems. If you don't have that problem, it's worse: that tends to mean you failed to abstract away critical concepts like factories, and that you will have a hard time elsewhere, for example in testing (this is what you often see in C#, for instance) or with global state (a common issue in ruby code).

There is of course an alternative: use a function rather than a factory; but that's kind of the point of this discussion :-).

(Before we start a flame war: This isn't a criticsm of ruby or C# specifically, it's just something I've seen a lot in those code bases. Both languages allow writing factories or using lambdas.)

Re: How Class-based Programming Sucks (2011)

#82

Post by drharris »

Paradigma11 wrote: post #79
drharris wrote: post #58

Earlier quoted context omitted.

>> Immutable state can be a huge pain in the ass. A common mistake FP beginners, and even "experienced" developers, make is the creation of this complex jungle of entangled functions . See what I did there.

The analogy would be that those functions are mutually recursive and while mutual recursive functions can be an elegant solution to several problems (state machine, some algorithms)overuse is not a mistake i have seen very often. FP does coerce, or at least very strongly suggests, a very simple program structure. This makes it hard to model some more complex relationships that are easy in OO. Anyway, my point is that…

My main point was that bad code exists in all paradigms. If there were a perfect language or paradigm, everybody would be using it and there would be no such debate. Immutability is not necessarily good or bad, same for mutability. We should all do a better job at explaining to beginning programmers how to use all paradigms appropriately, and how to choose among them. And of course, to use vi.

Re: How Class-based Programming Sucks (2011)

#83

Post by willismichael »

jonahx wrote: post #67
zeteo wrote: post #23

Earlier quoted context omitted.

>The thing about [OOP] is that it allows you to model a problem domain in real-world terms. That's only true on a superficial level. Sure, in CS 101 it's easy to explain how to make a Point object and add a Move() method to it. But dive into any real-world code base and you're more likely to meet RectangleCollectionColorPickerFactory instead. Let's face it, writing a large program is an exercise in abstract symbol ma…

OOP is not fundamentally about mapping your code to physical real-world objects, but about mapping it to natural, intuitive concepts . Those concepts can, and in many cases should, be as abstract as you like: eg, an "Algorithm" object. Something like "RectangleCollectionColorPickerFactory" is obviously a confusing and ridiculous concept, and exemplifies a failed application of OOP, not a failure of OOP itself. One co…

Of course no true Scotsman would write a class like RectangleCollectionColorPickerFactory.

Re: How Class-based Programming Sucks (2011)

#84

Post by davexunit »

evanspa wrote: post #56
choult wrote: post #2

The thing about "Class based Programming" - or Object Orientated Programming - is that it allows you to model a problem domain in real-world terms. No one approach is ever going to be perfect; OO being mutable makes it perhaps less founded (on the face of things) on formal principles, but for a lot of large codebases it can have a great beneficial effect on readability and maintainability - cognitive overhead is, per…

I love Hal Abelson's opening of this SICP lecture[1], in which he acknowledges that OO (with mutable state) is born from the idea of modeling computer programs the way we perceive the world. But then he goes on to say that the reason why OO can be so complicated (because of having to deal with the can-of-worms that is mutable state) is because maybe we have the wrong view of reality. He then proceeds to launch his pi…

What a great lecture. Thank you for sharing. I own and have read a good portion of SICP and these lectures are a great supplement to that.

Re: How Class-based Programming Sucks (2011)

#85

Post by mcphilip »

zeteo wrote: post #23
choult wrote: post #2

The thing about "Class based Programming" - or Object Orientated Programming - is that it allows you to model a problem domain in real-world terms. No one approach is ever going to be perfect; OO being mutable makes it perhaps less founded (on the face of things) on formal principles, but for a lot of large codebases it can have a great beneficial effect on readability and maintainability - cognitive overhead is, per…

>The thing about [OOP] is that it allows you to model a problem domain in real-world terms. That's only true on a superficial level. Sure, in CS 101 it's easy to explain how to make a Point object and add a Move() method to it. But dive into any real-world code base and you're more likely to meet RectangleCollectionColorPickerFactory instead. Let's face it, writing a large program is an exercise in abstract symbol ma…

The inability to comprehend why a mashup of nouns into a long class name might be useful is one of the most annoying memes on HN. Is it just that programmers are slow typist or something? Surely any competent programmer should be able to string together what the individual terms mean in your example (Rectangle, Collection, Color Picker, Factory), and easily grok what the class is intended to be used for.

Re: How Class-based Programming Sucks (2011)

#86

Post by xerophtye »

barrkel wrote: post #77
seanmcdirmid wrote: post #70

Earlier quoted context omitted.

PL designer here with extensive experience writing compilers in C#, Java, and Scala. Pattern matching is nice but OO will get you most of the way and filling the matching gap is simple. The expression problem is much safer solved using virtual classes (using traits and type members) in scala than with case matching. There are so many OO solutions to this problem it's not funny; I think I had a small argument with Wad…

I've written compilers in C, C++, C#, Delphi, Java, ML and Lisp; targeting x86, x64, JVM and MSIL. I was maintainer of the Delphi front end at Borland / Embarcadero. Pattern matching isn't just nice; you end up with substantially better typechecking, and doesn't need ugly patterns like visitors with their inverted callback control flow, if you want to decouple e.g. type checking or code generation from your AST class…

Wow. Don't mind us mere mortals please continue your discussion, it seems really fascinating even though i hardly understand a word of it.

Re: How Class-based Programming Sucks (2011)

#87

Post by protomyth »

barrkel wrote: post #27

Class-based programming works great for GUI toolkits. In most other contexts, the suitability is variable. OO is a horrible match for compilers, for example. The article is chasing down the wrong tree when he tries to build an Option type in C++, though. The normal OO way to handle the same class of functionality as ADT sum types is to use separate subclasses. What he's not acknowledging is that OO and functional+ADT…

"Class-based programming works great for GUI toolkits."

I've programmed with 3 approaches to UI: every things a subclass, instance of class, and prototype-based objects. I enjoyed programming UI on the Newton because of the prototype-based programming. It felt natural. NeXT / Apple's instance of a class works very well too.

Every time I see "every things a subclass", I wince and know its going to be a pain in the butt.

Re: How Class-based Programming Sucks (2011)

#88

Post by MartinCron »

jonahx wrote: post #67
zeteo wrote: post #23

Earlier quoted context omitted.

>The thing about [OOP] is that it allows you to model a problem domain in real-world terms. That's only true on a superficial level. Sure, in CS 101 it's easy to explain how to make a Point object and add a Move() method to it. But dive into any real-world code base and you're more likely to meet RectangleCollectionColorPickerFactory instead. Let's face it, writing a large program is an exercise in abstract symbol ma…

OOP is not fundamentally about mapping your code to physical real-world objects, but about mapping it to natural, intuitive concepts . Those concepts can, and in many cases should, be as abstract as you like: eg, an "Algorithm" object. Something like "RectangleCollectionColorPickerFactory" is obviously a confusing and ridiculous concept, and exemplifies a failed application of OOP, not a failure of OOP itself. One co…

Those concepts can, and in many cases should, be as abstract as you like: eg, an "Algorithm" object.

I only really "got" design patterns when I realized that the strategy pattern was just treating an algorithm/implementation as an object and stopped thinking that OO was exclusively about mapping things to real world objects.

Re: How Class-based Programming Sucks (2011)

#89

Post by MartinCron »

ocharles wrote: post #66
fhd2 wrote: post #31

Earlier quoted context omitted.

> Class-based programming works great for GUI toolkits. That and games (and I'd wager simulations in general). The only two domains I'm familiar with which I cannot imagine without OO. From what I've seen, even UIs and games written in languages without support for OO still use something very close to OO. GTK for instance takes it quite far with GObject.

I spent some time writing Asteroids in netwire - a functional reactive programming library in Haskell - in my free time over a few evenings. I blogged about this at http://ocharles.org.uk/blog/posts/2013-08-18-asteroids-in-ne... - and I don't think it pretends to be OO. It was a radically different style, and I left feeling fairly convinced that FRP is a fantastic model for realtime interactions

Thank you for sharing. I really enjoyed your netwire Asteroids post. I used Asteroids for teaching myself OO concepts many years ago. It's good to know that it's still a valuable teaching tool.

Re: How Class-based Programming Sucks (2011)

#90

Post by rurban »

swah wrote: post #35

Relevant recent tweet by the creator of the Io Language, Steve Dekorte: https://twitter.com/stevedekorte/status/411045428361056256 I suppose most folks here disagree?

Of course I agree with Dekorte. Having written compilers written in perl, C and LISP - the ones in perl in pure OO, and the ones in C and LISP without, I conclude that I rather add classes and methods to my compilers than trying to improve it without. In the one written in C, classes are supported by the intermediate VM though (dynamically typed, very similar to Io), which is still better than having to write it in horrible C++.
Post reply on HN