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

101–110 of 147 posts

Re: How Class-based Programming Sucks (2011)

#101

Post by protomyth »

lmm wrote: post #100
protomyth wrote: post #87

Earlier quoted context omitted.

"Class-based programming works great for GUI toolkits." I've programmed with 3 approaches to UI: every things a subclass, instance of class, and prototype-based objects. I enjoyed programming UI on the Newton because of the prototype-based programming. It felt natural. NeXT / Apple's instance of a class works very well too. Every time I see "every things a subclass", I wince and know its going to be a pain in the but…

Ever use Wicket? It's an utter joy to work with, and the only framework I've found that really shows the good side of Java.

Cannot say I have. I left Java at the 1.1 version and never made it back.

Re: How Class-based Programming Sucks (2011)

#103

Post by bunderbunder »

fhd2 wrote: post #31
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…

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

That and enterprise software. As productive as I am with functional programming, I still find it works better to expose object-oriented interfaces to the world at large.

Some of that's admittedly just down to the window dressing. Object-oriented abstraction mechanisms such as interface tend to have a measure of self-documentation built in, to the extent that all the members are named, right down to method parameters. There's no reason you couldn't do something similar with FP, it's just that as far as I can tell nobody's ever made a point of doing so.

Re: How Class-based Programming Sucks (2011)

#104

Post by [deleted] »

jeremyjh wrote: post #52
toolslive wrote: post #11

mutable state is not a problem per se. _Shared_ mutable state however, is a recipe for disaster. There are other problems with Object-Orientation. For example, it tends to scatter allocation which has performance impact. ( see this nice presentation: http://harmful.cat-v.org/software/OO_programming/_pdf/Pitfal... ) If performance is not an issue, I'd guess the price you pay for OO is that you eschew parallelism and c…

Any code that operates upon your object with "private" state still has to account for the fact that its methods are not referentially transparent. E.g. I have to open a connection to the database before I can send commands through it, and so now I have to check if its already open everywhere I use it. So that is definitely shared state, but I guarantee you that a lot of people think a private variable means it is not…

[deleted]

Re: How Class-based Programming Sucks (2011)

#105

Post by hcarvalhoalves »

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.

> OOP actually doesn't model the real world well at all. It seems to on the surface, but it completely ignores time.

This is important, and something almost everybody ignores.

Get an OO codebase, and try to implement a time-dependent feature, like snapshots, or even a simple undo. The abstractions fall apart.

Re: How Class-based Programming Sucks (2011)

#106

Post by runT1ME »

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…

>The expression problem is much safer solved using virtual classes (using traits and type members) in scala than with case matching.

Why do you think this? I prefer having an open trait that's only inherited by ADTs.

I can get non-exhaustive match warnings and I still 'solve' the expression problem by matching on a superset of my partial functions (that do the matching).

Re: How Class-based Programming Sucks (2011)

#107

Post by Alphasite_ »

pjmlp wrote: post #74
astrobe_ wrote: post #68

Earlier quoted context omitted.

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

I thought Simula was the originator of OO?

Re: How Class-based Programming Sucks (2011)

#108

Post by Nekorosu »

xerophtye wrote: post #86
barrkel wrote: post #77

Earlier quoted context omitted.

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

Wow. Don't mind us mere mortals please continue your discussion, it seems really fascinating even though i hardly understand a word of it.

I consider myself a mere mortal too but I can understand most of the discussion.

Re: How Class-based Programming Sucks (2011)

#109

Post by Nekorosu »

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 problem is it's not real-world most of the time.

Re: How Class-based Programming Sucks (2011)

#110

Post by wsc981 »

protomyth wrote: post #87
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…

"Class-based programming works great for GUI toolkits." I've programmed with 3 approaches to UI: every things a subclass, instance of class, and prototype-based objects. I enjoyed programming UI on the Newton because of the prototype-based programming. It felt natural. NeXT / Apple's instance of a class works very well too. Every time I see "every things a subclass", I wince and know its going to be a pain in the but…

That reminds me of a little quote by Aaron Hillegass in his book "Cocoa Programming for Mac OS X" (p. 73):

> "Once upon a time, there was a company Taligent. Taligent was created by IBM and Apple to develop a set of tools and libraries like Cocoa. About the time Taligent reached about the peak of it's mindshare, I met one of its engineers at a trade show. I asked him to create a simple application for me: A window would appear with a button, and when the button was clicked, the words 'Hello World!' would appear in a text field. The engineer created a project and started subclassing madly: subclassing the window and the button and the event handler. The he started generating code: dozens of lines to get the button and text field on to the window. After 45 minutes, I had to leave. The app still did not work. That day, I knew that the company was doomed. A couple of years later, Taligent quietly closed its doors forever. "

Post reply on HN