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

91–100 of 147 posts

Re: How Class-based Programming Sucks (2011)

#91

Post by profquail »

pjmlp wrote: post #46
JackMorgan wrote: post #17

Earlier quoted context omitted.

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.

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

The reason F# gets used for implementing libraries is because that makes it easier to introduce into organizations with existing code in C# or VB.NET; a new component or plugin can be written in F# and easily utilized by the existing code, so the other developers in the organization don't need to anything differently than if they were consuming another C# or VB.NET component.

Re: How Class-based Programming Sucks (2011)

#92

Post by humanrebar »

nly wrote: post #47
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 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 hardware mutates. That pool of memory changes size and locality. The closer your problem domain is to the metal (especially drivers and highly-optimized code), the more you appreciate mutable state, at least given the current state of computing.

Re: How Class-based Programming Sucks (2011)

#93

Post by smosher »

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…

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.

Re: How Class-based Programming Sucks (2011)

#94

Post by davexunit »

seanmcdirmid wrote: post #71
ocharles wrote: post #66

Earlier quoted context omitted.

I spent some time writing Asteroids in netwire - a functional reactive programming library in Haskell - in my free time over a few evenings. I blogged about this at http://ocharles.org.uk/blog/posts/2013-08-18-asteroids-in-ne... - and I don't think it pretends to be OO. It was a radically different style, and I left feeling fairly convinced that FRP is a fantastic model for realtime interactions

FRP is great until you need to be interactive or switch over collections, then it becomes quite ugly. It can work for small games, like the ones in Courtney's dissertation. But over that? Not until a complete physics engine can be joined with a FRP library.

FRP can exist happily alongside imperative methods of updating state. This approach is explored in FrTime for Racket. http://cs.brown.edu/~sk/Publications/Papers/Published/ck-frt...

Re: How Class-based Programming Sucks (2011)

#96

Post by nested »

drharris wrote: post #82
Paradigma11 wrote: post #79

Earlier quoted context omitted.

The analogy would be that those functions are mutually recursive and while mutual recursive functions can be an elegant solution to several problems (state machine, some algorithms)overuse is not a mistake i have seen very often. FP does coerce, or at least very strongly suggests, a very simple program structure. This makes it hard to model some more complex relationships that are easy in OO. Anyway, my point is that…

My main point was that bad code exists in all paradigms. If there were a perfect language or paradigm, everybody would be using it and there would be no such debate. Immutability is not necessarily good or bad, same for mutability. We should all do a better job at explaining to beginning programmers how to use all paradigms appropriately, and how to choose among them. And of course, to use vi.

Why should I use vi? Why wouldn't this decision be similar to what paradigm I choose?

Re: How Class-based Programming Sucks (2011)

#97

Post by jkrems »

emn13 wrote: post #81
delinka wrote: post #38

Earlier quoted context omitted.

"... RectangleCollectionColorPickerFactory ..." Sounds like you're blaming the OO world for Java's problems. But I digress... Trying to make code correspond to real world objects is annoying because after you've modeled your Car with Wheels that support Tires, and an Engine with EngineParts attached ... you then have to write a adaptation layer to make all that fit into your storage engine, your user interface, your…

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 point will start being a little more balanced and stop trying to pretend like "the purer and functional the better" (or the opposite).

Re: How Class-based Programming Sucks (2011)

#98

Post by drharris »

nested wrote: post #96
drharris wrote: post #82

Earlier quoted context omitted.

My main point was that bad code exists in all paradigms. If there were a perfect language or paradigm, everybody would be using it and there would be no such debate. Immutability is not necessarily good or bad, same for mutability. We should all do a better job at explaining to beginning programmers how to use all paradigms appropriately, and how to choose among them. And of course, to use vi.

Why should I use vi? Why wouldn't this decision be similar to what paradigm I choose?

It was a joke. Emacs vs. Vi, FP vs OOP, etc. All members of the set of useless debate topics.

Re: How Class-based Programming Sucks (2011)

#99

Post by nilkn »

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…

The most complex code I've ever personally worked with involved a proliferation of abstract visitors in Java. I really don't think most people working on the code could understand how it all tied together (myself included).

Re: How Class-based Programming Sucks (2011)

#100

Post by lmm »

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…

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.
Post reply on HN