Live data from Hacker News

How Class-based Programming Sucks (2011)

loup-vaillant.fr

131–140 of 147 posts

Re: How Class-based Programming Sucks (2011)

#131
post #42

> You may even have to inherit a base class or implement an interface. Subtype polymorphism is a very poor substitute for closures. This is why C++ algorithm library is unusable. Does anybody understand what the author means by this? STL's algorithm library does not use class hierarchies for anything. And they often take functions (be they free functions, lambdas, or functors) as arguments.

Before C++11, if you wanted to pass a function with closure-like behavior to an STL algorithm, you had to write a little class with operator() overloaded. It was a huge pain in the ass, lots of boilerplate code. Most programmers didn't bother and wrote plain loops.

Now with C++11 lambdas, std::algorithm is much nicer to use.

Re: How Class-based Programming Sucks (2011)

#132
post #7

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.

"everything is a process" To me that's as bad as saying "everything is an object". I'd rather try and understand where each approach is best rather than picking a single approach and dogmatically applying it in every scenario.

I think his point is that the real world is concurrent states, not context switching. To loosely paraphrase Joe Armstrong, in the real world, data isnt shared, it's communicated. In this sense, the process as a fundamental abstraction more correctly models "the real world."

Re: How Class-based Programming Sucks (2011)

#133

Earlier quoted context omitted.

OK, I have no idea what point you are trying to make then. Please forgive my ignorance on your social conventions.

The point was simply that what you wrote is how a very bad argument starts. I took care to point out I wasn't accusing you of that but you have reacted defensively anyway. It's my fault for trying to engage an HN-er in a form of discourse other than debate.

If its a meta comment, just say so directly. It is a bit difficult to decode these comments sometimes, especially when defending OOP.

Re: How Class-based Programming Sucks (2011)

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

We can think the state of the world is immutable. When the state changes, it's a different world.

If space-time is discontinuous, then we can think any change of state, like motion, as a set of discrete changes. If we think the motion of a particle from one energy bin to another is immediate (meaning the particle cannot be found on the border between the bins, or one moment the particle is in Bin A, next it is in Bin B) then we can think the particle was destroyed in Bin A and another one was created at Bin B. And this is what we call motion from A -> B.

Re: How Class-based Programming Sucks (2011)

#135
post #46

Earlier quoted context omitted.

Pity that Microsoft pushes it more for library code and not so much for full applications. But if it gets more use in the mainstream that way, then so be it.

The only difference between a "library" and a "full application" is that the "full application" has an entry point where execution begins, whereas a "library" does not. Many large applications are implemented as a thin user interface (GUI, web, services/APIs) which glues together a bunch of libraries (which is where all of the real functionality is implemented). This doesn't only apply to F#, but C#, Java, Python, et…

I do understand the reasoning behind it, just as a ML fan would like to see the possibility of proper support for GUI/Web for pure F# applications.

But I fully understand it, on my enterprise world JVM == Java and .NET == C#, except when doing small prototypes. It is very hard to use alternative languages, as managers always look for coding drones.

Re: How Class-based Programming Sucks (2011)

#136
post #80
post #41

Earlier quoted context omitted.

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

You can have OO without classes.

I just meant OO in general, not classes specifically.

Re: How Class-based Programming Sucks (2011)

#137

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.

A criminal tells the arresting police officer: - You're wrong, officer. It was yesterday-me who committed the crime but you are trying to arrest now-me. How wrong are you! I bet the authorities around the world don't like your time-inclusive-dimenstion view much.

You do realize that there's a difference between an object with identity (ddd names it entity) and the one without it (ddd names it value object).

No matter what you do, identity does not change. You commiting a crime yesterday was an event that included you as an object with identity and today you have the same identtiy so you are clearly responsible for what you did yesterday.

GUARDS! :P

Re: How Class-based Programming Sucks (2011)

#138

A language can't suck just because it isn't Haskell or ML.

It's funny how people blame the language when they are the ones who made a mess. :)

On the other hand, there are languages that make it easier for you to screw it up and the ones that try to prevent that.

But there's no bullet proof language.

Re: How Class-based Programming Sucks (2011)

#139
post #5

This is a very good article. The point about mutable state is key. Class based programming encourages you to treat objects as little bags of mutable state, instead of as values, and everything goes downhill from there. Its one thing to not go all the way to disallowing mutation. Its another to encourage it to be used pervasively.

Prorgramming without mutating state is honestly just bizarre to me. Mutating state is all a program does, literally.

Re: How Class-based Programming Sucks (2011)

#140

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

It's more that Java is hard because naming things is hard and Java forces developers to name lots of things.
Post reply on HN