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

141–147 of 147 posts

Re: How Class-based Programming Sucks (2011)

#141

Post by pkolaczk »

humanrebar wrote: post #92
nly wrote: post #47

Earlier quoted context omitted.

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

The overhead that is assumed unimportant by most functional languages (copying is cheap, GC is fine, etc.) is intolerable in key situations and problem domains. In C++ all overhead must be optional. That being said, nearly all C++ applications can benefit from immutable classes, algorithms that take closures, and so on. But C++, like C before it, is really just an abstraction of the hardware and OS below it. That har…

Dealing with complex immutable data structures without GC is either extremely hard or inefficient (and usually both). C++ standard library does not offer any helping hand here either. Additionally C++ logical memory model (flat, uniform memory) does not describe the hardware memory model well - it is already an abstraction. An memory access isn't uniform and mutations can cost you really very much. In some cases immutable structures + little copying is often the way to go, especially when we aim at parallelization.

Re: How Class-based Programming Sucks (2011)

#142

Post by coldtea »

smosher wrote: post #127
coldtea wrote: post #123

Earlier quoted context omitted.

> reads a lot like the Blub conceit Perhaps. But then again the "Blub conceit" is nothing that exists in real life as a proven fact of computer science. It's just an argument expressed in an essay. Not some kind of formal logical error.

What's your point?

My point, which is pretty obvious, is that it "reading like the Blub conceit" doesn't mean anything at all with regards to its correctness.

Might as well say "your argument reads a lot as something that an unbeliever in the flying spaghetti monster would say".

Re: How Class-based Programming Sucks (2011)

#143

Post by EdwardDiego »

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…

Java's anonymous classes can also act as a (large and bulky) closure, although as you have to declare local variables used by the anonymous class as final, the capacity to close over mutable state is limited to instance fields or mutable objects.

Re: How Class-based Programming Sucks (2011)

#144

Post by mtdewcmu »

matjazmuhic wrote: post #138
mtdewcmu wrote: post #102

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.

A bug-proof language is like an uncrashable car.

Re: How Class-based Programming Sucks (2011)

#145

Post by likeclockwork »

alkonaut wrote: post #62

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

I'm noticing that whenever there is talk about any language that isn't Java or a CLR language several someones pop up to go on about the tooling "we" expect.

The difference between norm vec and vec.norm() is that the function can be used in a higher order function while the method would require wrapping it in a lambda to achieve the same thing and would probably still break your tool's ability to autocomplete if you used it that way.

You're basically insisting that an FP language needs to include an embedded OO language to be usable.

Re: How Class-based Programming Sucks (2011)

#146

Post by emn13 »

pjmlp wrote: post #136
emn13 wrote: post #80

Earlier quoted context omitted.

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.

You can have Objects without classes, certainly - even C had structs, and all functional languages I know of have records or something similar.

It's a question of terminology whether you call that object-oriented. It's certainly part of OO, in any case.

Re: How Class-based Programming Sucks (2011)

#147

Post by Mikera »

w0utert wrote: post #49
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.

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

It makes a lot of sense in the context of programming when you look at the big picture. I think Rich Hickey articulates it best: http://www.infoq.com/presentations/Value-Identity-State-Rich...
Post reply on HN