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

41–50 of 147 posts

Re: How Class-based Programming Sucks (2011)

#41

Post by pjmlp »

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.

Re: How Class-based Programming Sucks (2011)

#42

Post by pbsd »

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

Re: How Class-based Programming Sucks (2011)

#43

Post by pjmlp »

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.

Re: How Class-based Programming Sucks (2011)

#44

Post by toolslive »

louthy wrote: post #19
toolslive wrote: post #18

Earlier quoted context omitted.

any evidence for the 'even more' statement ?

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.

so, no real evidence except anecdotes. Anyway, I was not claiming anything about functional programming being better. I was merely saying Object-Oriented is not necessarily data-centric. That being said, Lisp & OCaml programmers will argue the statement that FP implies immutability. OCaml strings ARE mutable, (so are OCaml arrays) and you have the keyword 'mutable'. Lisp has setq ... IMO FP does imply that you treat mutation & side effects with the respect they deserve.

Re: How Class-based Programming Sucks (2011)

#45

Post by qznc »

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.

Re: How Class-based Programming Sucks (2011)

#46

Post by pjmlp »

JackMorgan wrote: post #17
auggierose wrote: post #3

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.

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.

Re: How Class-based Programming Sucks (2011)

#47

Post by nly »

pbsd wrote: 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.

The author probably had (this was written 3 years ago) a bitter and rather narrow view of OOP capable languages.

In C++ a class is just a facility of the language with many different features. If you want immutable, value-semantic objects, then do it. If you want a closure... well objects can be closures too. C++ calls them functors, they can be immutable. In fact, C++11 lambdas are immutable by default.

His criticism of the STL is probably that they expose their mutation, rather than hiding it in the architecture like pure functional languages. In C++ you just have to hide the infrastructure yourself.

Re: How Class-based Programming Sucks (2011)

#48

Post by jeremyjh »

jonahx wrote: post #25
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…

Yes. The article correctly points out potential pitfalls of OOP but glosses over its benefits: > See, mutable state makes shorter English sentences, and the agent concept helps make analogies with our fellow humans. In the end, this first impression trumps the fact that avoiding mutable state where possible ultimately yield simpler programs. - But shorter English sentences are awesome. - Good analogies are awesome. -…

> - But shorter English sentences are awesome.

You missed the author's point here. He of course prefers shorter sentences as well. He is complaining that mainstream language syntax is biased in favor of mutability since you need to use an extra keyword to make a const expression. In F# for example it is just the opposite, you have to use the keyword "mutable" in your declaration.

Re: How Class-based Programming Sucks (2011)

#49

Post by w0utert »

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.

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

Been reading up on Heraclitus lately?

While this is an interesting statement for a philosophical dialogue, it doesn't really make much sense in the context of programming, where many things are constant, many things are not processes, and there are plenty of use cases for both mutable and immutable state (which is exactly why I always get really defensive reading articles like this one, that pretend all problem domains would be best modelled by a single programming language/paradigm/model of computation).

Post reply on HN