How Class-based Programming Sucks (2011) • Hacker News Board

Re: How Class-based Programming Sucks (2011)

#111

Post by haberman » Fri, Dec 13, 2013, 10:40 PM UTC

barrkel wrote: post #77

seanmcdirmid wrote: post #70

Earlier quoted context omitted.

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…

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…

> Visitors are implicitly closed to extension unless you create very abstract visitors (and I've gone down that path, it's not pleasant)

I'd love to hear more detail about your experience on this point.

Re: How Class-based Programming Sucks (2011)

#112

Post by dustingetz » Fri, Dec 13, 2013, 10:44 PM UTC

theseoafs wrote: post #8

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.

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 ?

Immutable doesn't mean unchanging. It means no mutation. I can throw a ball in the air and model it as a function of time without mutation.

Re: How Class-based Programming Sucks (2011)

#113

Post by MichaelGG » Fri, Dec 13, 2013, 11:43 PM UTC

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…

If your functions are inside a module you import, you can still navigate them by browsing autocomplete using the module name as an unnecesary qualifier. Then once you find/remember, delete the qualifier in cleanup. No need to force members just for discoverability. (Not to mention that tools could provide other ways of doing autocomplete.)

Re: How Class-based Programming Sucks (2011)

#114

Post by colinkahn » Fri, Dec 13, 2013, 11:45 PM UTC

smosher wrote: post #93

seanmcdirmid wrote: post #70

Earlier quoted context omitted.

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…

I couldn't help but notice this phrase: [X] is nice but [Y] will get you most of the way and [dealing with the difference] is simple. reads a lot like the Blub conceit. I'm not accusing you of that, but I do disagree that OO can give you what pattern matching typically does.

What is the blub conceit? Google searched it and got nothing.

Re: How Class-based Programming Sucks (2011)

#115

Post by Jare » Fri, Dec 13, 2013, 11:45 PM UTC

mcphilip wrote: post #85

zeteo wrote: post #23

Earlier quoted context omitted.

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

The inability to comprehend why a mashup of nouns into a long class name might be useful is one of the most annoying memes on HN. Is it just that programmers are slow typist or something? Surely any competent programmer should be able to string together what the individual terms mean in your example (Rectangle, Collection, Color Picker, Factory), and easily grok what the class is intended to be used for.

The meme is more about the abuse of that idea into absurdly overengineered and the approach to programming where anything needs 3x the amount of work in the form of scaffolding and code bureaucracy.

Re: How Class-based Programming Sucks (2011)

#116

Post by emn13 » Fri, Dec 13, 2013, 11:52 PM UTC

jkrems wrote: post #97

emn13 wrote: post #81

Earlier quoted context omitted.

It's not just java - any good OO platform has those problems. If you don't have that problem, it's worse: that tends to mean you failed to abstract away critical concepts like factories, and that you will have a hard time elsewhere, for example in testing (this is what you often see in C#, for instance) or with global state (a common issue in ruby code). There is of course an alternative: use a function rather than a…

No, "any good OO platform has those problems" is just wrong. Point-like classes without factories or any other BS are alive in kicking in big code bases. And geometry (visualization) is actually an excellent example for where mutable state and simple classes make things easier (I can actually move the point/scene object and everyone who has a reference to it gets the update). I really hope those articles at some poin…

I'm not suggesting that everything has a factory; I'm suggesting that having a factory isn't some java-specific code smell; it's a necessary pattern in an OO language. You obviously don't need one for a point. The context was some color picker example - and I could well imagine multiple color pickers and a useful color picker factory.

And I entirely agree with you that a PointFactory is unwanted (barring special circumstances) - though I entire disagree you'd want points to be mutable. Certain control points? Certainly - make a MutablePoint which is (conceptually) simply a reference to a point value. All points? That's just asking for pain; I really have better things than to track down with nested submodule thought it was mutating a copy but due to some optimization interaction turned out to be mutating a copy someone was actually looking on. Not to mention that reference semantics don't work very nicely with hashtables and lots of other datastructures which become a lot more complicated when the values can change right under them.

Re: How Class-based Programming Sucks (2011)

#117

Post by smosher » Fri, Dec 13, 2013, 11:56 PM UTC

colinkahn wrote: post #114

smosher wrote: post #93

Earlier quoted context omitted.

I couldn't help but notice this phrase: [X] is nice but [Y] will get you most of the way and [dealing with the difference] is simple. reads a lot like the Blub conceit. I'm not accusing you of that, but I do disagree that OO can give you what pattern matching typically does.

What is the blub conceit? Google searched it and got nothing.

The important bit is:

    As long as our hypothetical Blub programmer is looking down the power 
    continuum, he knows he's looking down. Languages less powerful than Blub 
    are obviously less powerful, because they're missing some feature he's used 
    to. But when our hypothetical Blub programmer looks in the other direction, 
    up the power continuum, he doesn't realize he's looking up. What he sees are 
    merely weird languages. He probably considers them about equivalent in power 
    to Blub, but with all this other hairy stuff thrown in as well. Blub is good 
    enough for him, because he thinks in Blub.

From PG's Beating the Averages (http://www.paulgraham.com/avg.html)

Re: How Class-based Programming Sucks (2011)

#118

Post by mrkhwrd3 » Fri, Dec 13, 2013, 11:58 PM UTC

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.

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.

Re: How Class-based Programming Sucks (2011)

#119

Post by seanmcdirmid » Sat, Dec 14, 2013, 12:55 AM UTC

barrkel wrote: post #77

seanmcdirmid wrote: post #70

Earlier quoted context omitted.

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…

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…

I've never had to use visitors in my compiler implementations; abstract methods + overrides is good enough; I also use partial classes in C# heavily even those these don't support separate compilation. I also dislike callbacks also, but control flow in general is abstracted away by a flow analysis framework of some sort anyways (technically you don't need this for parsing, but it works well for the systems I build). On the other hand, scalac is just a giant pattern match in Typers and Namers, a style I dislike but to each his own.

I've built a live programming environment where reactive mutable collections are much more appropriate than immutable persistent collections, you can check it out here:

http://research.microsoft.com/en-us/people/smcdirm/liveprogr...

The problem with immutable collections in general is that they completely cannot track change deltas, which is necessary when building an incremental systems. Undo is also essential for these kinds of systems. I think persistent collections are a dead end, but its an argument I'll have to work on over the next few years.

Re: How Class-based Programming Sucks (2011)

#120

Post by seanmcdirmid » Sat, Dec 14, 2013, 12:59 AM UTC

runT1ME wrote: post #106

seanmcdirmid wrote: post #70

Earlier quoted context omitted.

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

Virtual classes with family polymorphism attacks the problem directly: you can add new variants as well as enhance the super class with new abstract methods: your system is abstract until all variants have implemented the abstract methods of the super class. You can then do cool things like factor all your functionality for X in one layer and Y in another layer, replicating variants in X and Y layers to specify their implementations separately.

When I did this in Scala (using traits and type parameters in a virtual class pattern), I got a lot of pushback from the FP people, who thought this problem couldn't, or more correctly SHOULDN'T, be solved using object-oriented constructs; it was one of the main things they liked to boast about in how FP was better than OOP, and I literally took that away from them. A 10,000 line pattern match was somehow preferable to a file with 20 traits that described how the new operation was performed per variant. Martin even made my pattern illegal via a new type check in the Scala compiler after I left EPFL :)