Live data from Hacker News

How Class-based Programming Sucks (2011)

loup-vaillant.fr

31–40 of 147 posts

Re: How Class-based Programming Sucks (2011)

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

Re: How Class-based Programming Sucks (2011)

#33
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…

I believe someone has solved the expression problem in Haskell and other languages.

Re: How Class-based Programming Sucks (2011)

#34
post #19

Earlier quoted context omitted.

It's a natural side-effect of using immutable structures. When you need to modify you allocate a new object with the mutation. This naturally has an impact on the GC because it needs to allocate and recover more garbage.

That's true, though it's also worth pointing out that immutability can make garbage collection easier.

Indeed, and many of the objects will be very short lived, therefore getting collected in generation 0.

Re: How Class-based Programming Sucks (2011)

#36
post #19

Earlier quoted context omitted.

It's a natural side-effect of using immutable structures. When you need to modify you allocate a new object with the mutation. This naturally has an impact on the GC because it needs to allocate and recover more garbage.

As an aside, my final year project for my CS degree included benchmarking different sets of SK combinators for efficiency as well as looking at different reduction algorithms. What I found out pretty quickly is that, especially as I was running my code on a mid 80s mini computer, I had to spend as much time on allocation and garbage collection strategies as anything else. Indeed, my only really "difficult" bug was ca…

> I was stumped for days and then I had a flash of insight from nowhere while sitting on a bus that fixed the problem

We're on tenterhooks here...

Re: How Class-based Programming Sucks (2011)

#37
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…

"it allows you to model a problem domain in real-world terms"

Which is exactly the kind of specious, guesswork solution one would expect from non-practising management types and committees. In most situations, the contortions and indirection involved in this kind of approach usually outweigh any real benefits.

Re: How Class-based Programming Sucks (2011)

#38
post #23
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…

"... 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 query engine, etc ad nauseam. Strings are not "real world" objects, but we use them in our code nonetheless. They're a great UI item that lets us interface with our users. "I need input from the user. Here, type some text in this field and I shall call it String." Now you can manipulate the String with operations (methods on the object) that make sense for Strings.

Point: OO is not about "modeling the real world," it's about code organization. Some people organize with OO. Some with other means.

Re: How Class-based Programming Sucks (2011)

#39

In case you don't know ML, you should. Also note that though OCaml is the most popular ML dialect right now, Standard ML is where it all started (PolyML is a good Standard ML implementation: http://www.polyml.org/ )

Or even F#, which is basically OCaml on the CLR. Very fast, fully supported IDE, great if you're stuck in SLAs for CLR code, complete interop with C# or VB.NET, it's the current hidden treasure of the .NET world.

.NET sucks. Microsoft sucks. Take your transparent Microsoft advocacy elsewhere please.

Re: How Class-based Programming Sucks (2011)

#40
post #12

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…

Most events humans care about happen in plain old classical physics, and no computer is moving at some large fraction of light-speed relative to any other computer. If you maintain synchronized clocks, everyone can agree on the exact same order of events (which would not be true in a relativistic situation).

Now it turns out to be difficult to maintain synchronized clocks, and Lamport timestamps and vector clocks are alternatives. The end result looks similar to a relativistic situation, but (and I'm not a physicist), it seems wrong to claim this situation is because of Special Relativity.

Thoughts?

Post reply on HN