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

61–70 of 147 posts

Re: How Class-based Programming Sucks (2011)

#61

Post by rayiner »

qznc wrote: post #45
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…

What is so bad about OO for compilers? An AST can naturally be modeled as a class hierarchy. Visitor pattern for AST transformations.

> What is so bad about OO for compilers?

See my comment about the expression problem in another thread: https://news.ycombinator.com/item?id=6783075, as well as this response: https://news.ycombinator.com/item?id=6784057.

A compiler is a program that consists of lots of different algorithms (operations) that operates on a pretty well-defined set of data (an AST or an IR). Changes to the data representation are rare compared to changes to the operations on that data.

What OO does in a compiler is totally obscure the control flow of each algorithm by spreading the logic out over dozens of classes. You can look at an AST node and see at a glance how it participates in constant folding or code generation, but if you're trying to optimize the constant folding algorithm or the code generator, you've got to follow control flow across dozens of different classes.

Using visitor pattern mitigates this somewhat, because you can have ConstFolder::visitBinaryOperation, ConstFolder::visitFunctionCall, etc, all in one file, but note that visitor pattern is just a really verbose, roundabout way of writing a switch statement! If you add a new type of AST node, you have to add a visitNewAstNode call to the visitor interface, and then go update every class that implements the visitor interface. This is no easier, and a lot more verbose, than simply adding a new variant to an AST ADT then fixing up all the places where the compiler complains that your pattern match is no longer exhaustive.

For a good example, look at how LLVM does instruction simplification: http://llvm.org/docs/doxygen/html/InstructionSimplify_8cpp_s.... A good old switch statement, no "simplify" method in the "Instruction" class nor visitor pattern.

Re: How Class-based Programming Sucks (2011)

#62

Post by alkonaut »

I agree, mostly, with the conclusions. "Classes" as a method of code re-use is dead. However, his conclusion that ML would dominate C# and Java as a language, I highly contest.

The most important thing in my opinion is tools and platform support. Show me a fast, good looking IDE with good autocomplete/intellisense/integrated debugger and UI tools for ML. See?

Is there an abundance of libraries and api wrappers available (that doesn't require you to do straight C-interop)? See?

Also: the design of a language should be done with the tools in mind. While there is not much difference between norm(vec) and vec.norm() the latter is the form that supports autocomplete. So even for functional languages, being able to use member properties and member functions is an absolute reqirement to support the tooling that we expect.

You could say that F# dominates C#. It has almost the same tool and library support, while having the features you expect from an ML type language.

Re: How Class-based Programming Sucks (2011)

#63

Post by evanspa »

theseoafs wrote: post #8
danenania wrote: post #6

Earlier quoted context omitted.

OOP actually doesn't model the real world well at all. It seems to on the surface, but it completely ignores time. In the real world, everything is a process. Nothing ever stays the same or stands still. No object is the same object from one millisecond to the next. Immutable state isn't just a formal exercise--it's a more authentic model of the world.

I'm sorry, are you arguing that immutability models the world more well than OO because no object in the real world ever stays the same ?

Check out the first 20 minutes or so of this SICP lecture. In it, Abelson specifically mentions special relativity as a way for us humans to "model" the real world as immutable values over the continuum of time (in contrast to a mutable world that fits with OO).

http://ocw.mit.edu/courses/electrical-engineering-and-comput...

Re: How Class-based Programming Sucks (2011)

#64

Post by gizzlon »

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

Exactly. I had forgot that I learned OOP by modelling a CD collection. When thinking about it now, "mapping" a program into real-world models and terms seems totally backwards.

What's the point of thinking in real-world models unless you program actually manipulates real-world objects? Of course there are properties that are useful to carry over, but why limit your program to real-world models?

Re: How Class-based Programming Sucks (2011)

#65

Post by eloff »

tomp wrote: post #12
theseoafs wrote: post #8

Earlier quoted context omitted.

I'm sorry, are you arguing that immutability models the world more well than OO because no object in the real world ever stays the same ?

Yes. Due to Special Relativity, different observers perceive events (changes to object state) at different moments, the state of the whole universe is not consistent. Therefore, we model the universe using a sequence of immutable universe snapshots, with different computational agents independently moving through the (branching) timeline of snapshots, so that each and every one of them views the universe consistently…

So what you're saying is the universe is mapped COW, and everytime there's a new observer, UniverseOS runs it with fork().

Re: How Class-based Programming Sucks (2011)

#66

Post by ocharles »

fhd2 wrote: post #31
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. 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

Re: How Class-based Programming Sucks (2011)

#67

Post by jonahx »

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…

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 could invent equally absurd demonstrations of functional programming, or indeed of any other paradigm.

Re: How Class-based Programming Sucks (2011)

#68

Post by astrobe_ »

pjmlp wrote: post #43
rowanseymour wrote: post #4

Best (and most humorous) argument against Java's object oriented obession that I've ever read is: http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom...

The funny thing is that many like to bash Java's OO model, and in the process forget that Smalltalk, Eiffel, C# and many others offer a similar model.

What's really funny is to claim that the Java/C++ model is similar to the Smalltalk model.

Re: How Class-based Programming Sucks (2011)

#69

Post by collyw »

danenania wrote: post #6
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…

OOP actually doesn't model the real world well at all. It seems to on the surface, but it completely ignores time. In the real world, everything is a process. Nothing ever stays the same or stands still. No object is the same object from one millisecond to the next. Immutable state isn't just a formal exercise--it's a more authentic model of the world.

"OOP actually doesn't model the real world well at all."

Surely that is in part due to the developer. Poor developers will choose the wrong abstractions, and have a poor OOP model as a result. Better developers will choose the correct abstractions, and have better models. Obviously the domain you are modeling will make it easier or harder to model things, and in some cases OPP may not be a good choice at all.

In my day to day work I use Django. I start with a data model - based on an ER diagram. I code that in the Django model classes. Is that OOP modeling or ER modeling? I don't know. I don't really care too much. It works fairly well for most things I am doing.

Re: How Class-based Programming Sucks (2011)

#70

Post by seanmcdirmid »

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…

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 Wadler over this back in 2001 or 2.

As for persistent collection types, observable collections with undoable operations are just as good, if not better because they can still support mutability while persistent collections cannot.

Post reply on HN