How Class-based Programming Sucks (2011) • Hacker News Board

Re: How Class-based Programming Sucks (2011)

#71

Post by seanmcdirmid » Fri, Dec 13, 2013, 3:03 PM UTC

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

FRP is great until you need to be interactive or switch over collections, then it becomes quite ugly. It can work for small games, like the ones in Courtney's dissertation. But over that? Not until a complete physics engine can be joined with a FRP library.

Re: How Class-based Programming Sucks (2011)

#72

Post by collyw » Fri, Dec 13, 2013, 3:03 PM UTC

nailer wrote: post #22

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 "Class based Programming" - or Object Orientated Programming You can have OOP without classes - prototypal inheritance for example. In JS, you just clone an exemplar with Object.create() for example. That said, the article author does the same thing.

Having used Angular for a month or so in summer, I find prototypal inheritance horrible and unpredictable. I am never 100% sure if the data is coming from or updating the parent object or the current object. Class based inheritance seems a lot more predicable to me.

Re: How Class-based Programming Sucks (2011)

#73

Post by seanmcdirmid » Fri, Dec 13, 2013, 3:07 PM UTC

rayiner wrote: post #61

qznc wrote: post #45

Earlier quoted context omitted.

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…

Scala, use traits and type variables, the problem is really easy to solve through what I call an open class pattern. See "new age components for old fashioned java" OOPSLA 2001, note I'm using Flatt's term "extensibility problem" which is the same as Wadler's "expression problem" term.

But if you want your control flow to be in place, then a 10,000 line case match ala scalac should be right up your alley. Frankly, I'd rather divide and conquer, which is what OOP is good at.

Re: How Class-based Programming Sucks (2011)

#74

Post by pjmlp » Fri, Dec 13, 2013, 3:08 PM UTC

astrobe_ wrote: post #68

pjmlp wrote: post #43

Earlier quoted context omitted.

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.

Kind of, yes.

You can map instance methods to normal methods in Smalltalk. And static methods to class methods in Smalltalk.

Of course, you don't have the dynamism of sending messages, instead of invoking method calls.

However given that Smalltalk is the originator of OO and everything is an object, OO critics would feel in prison most likely. :)

Re: How Class-based Programming Sucks (2011)

#75

Post by platz » Fri, Dec 13, 2013, 3:12 PM UTC

xcthulhu wrote: post #59

Okay, for one: 1. Dynamically Typed Languages (LISP, Erlang, Smalltalk, Python, Ruby, and Javascript) are all easier than Haskell, JAVA, C++ or any other typed language for working with ADTs. Whether the language is OO or not isn't really relevant. On the other hand, you loose type-safety/efficient representations. But life is filled with choices, different tools are good for different things at different times. 2. Y…

At this point, it's probably easier to name the languages that don't have closures as opposed to those that do

Re: How Class-based Programming Sucks (2011)

#76

Post by nailer » Fri, Dec 13, 2013, 3:12 PM UTC

collyw wrote: post #72

nailer wrote: post #22

Earlier quoted context omitted.

> The thing about "Class based Programming" - or Object Orientated Programming You can have OOP without classes - prototypal inheritance for example. In JS, you just clone an exemplar with Object.create() for example. That said, the article author does the same thing.

Having used Angular for a month or so in summer, I find prototypal inheritance horrible and unpredictable. I am never 100% sure if the data is coming from or updating the parent object or the current object. Class based inheritance seems a lot more predicable to me.

If Angular is your only experience of JS, I'm surprised you don't think JavaScript is the most complicated language in existence.

Re: How Class-based Programming Sucks (2011)

#77

Post by barrkel » Fri, Dec 13, 2013, 3:22 PM UTC

seanmcdirmid wrote: post #70

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 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 classes. Visitors are implicitly closed to extension unless you create very abstract visitors (and I've gone down that path, it's not pleasant) - you lose a big chunk of the extensibility objects give you over ADTs. (I'd prefer to use multimethods, but they are rarely available.)

I think persistent collections, along with nice syntax for updating immutable objects (i.e. cloning with a subset of changed attributes) are more practical than having undo available. Immutable data types remove the burden of worrying about who's going to modify the data type from under you, so it lets you share subgraphs more freely. You don't need to worry as much about coupling, because the things you give your state to can't modify it. A possible alternative is mutable collections with snapshots or freezing, but I think persistent collections are a better approach.

Re: How Class-based Programming Sucks (2011)

#78

Post by al2o3cr » Fri, Dec 13, 2013, 3:22 PM UTC

"The obvious conclusion is that ML simply dominates Java (and C#) as a language. Time to switch."

The obvious conclusion is that any statement that contains the phrase "the obvious conclusion is" is 100% BS, including this one.

Re: How Class-based Programming Sucks (2011)

#79

Post by Paradigma11 » Fri, Dec 13, 2013, 3:25 PM UTC

drharris wrote: post #58

kitsune_ wrote: post #9

Earlier quoted context omitted.

Mutable state can be a huge pain in the ass. A common mistake OOP beginners, and even "experienced" developers, make is the creation of this complex jungle of entangled objects that all directly or indirectly manipulate each other's internal states. If you've ever had to work with such a code base for a prolonged amount of time you are pretty quickly ripe for a year-long sabbatical. There is simply no way to reason a…

>> 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 FP is indeed different in this regard compared to OO.

Re: How Class-based Programming Sucks (2011)

#80

Post by emn13 » Fri, Dec 13, 2013, 3:30 PM UTC

pjmlp wrote: post #41

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…

> OO is a horrible match for compilers, for example. Actually it is a very good way to create ASTs if you need them to be extendable. Which is exactly the use case where algebraic data types fail short.

You want some way of specifying an interface - that doesn't necessarily imply classes. Also, class-based inheritance tends to be a poor fit for interfaces; note for example that C#/Java have their own special-purpose interface mechanics, and even C++ which allows multiple inheritance tends to use implicit template-based interface implementation instead.

Discriminated unions on the other hand are - the name says it - intended for cases where you want to discriminate between multiple possible values. They're by design not intended to hide differences behind an interface; they don't address the same problem at all.

All in all, I think that neither classes nor discriminated unions solve the interface problem (nor were they ever really designed to do so) - that's a different problem.