Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Goodbye, Object Oriented Programming

medium.com

Post reply on HN
Print view View original

11–20 of 355 posts

Re: Goodbye, Object Oriented Programming

#11

Post by quacker »

DanWaterworth wrote: post #6
Illniyar wrote: post #5

I think the functional vs OO debate is being done with a very narrow point of view. Functional came before OO and there are reasons why it became much more popular- it had much better, easier and simpler solution to the most common problems of the 90's and early 2000's, namely handling GUI and keeping single process app state (usually for a desktop app). It fares much worse in today's world of SaaS and massive parall…

> For instance I have yet to see an easy and simple to use (and as such maintainable) functional widget and gui library. Like react?

My impression of react is that it's very object oriented. Defining reusable, stateful components is classic OO design. Now, I don't have much experience with React so maybe someone can explain why it should be considered "functional".

Re: Goodbye, Object Oriented Programming

#12

Post by olmo »

DanWaterworth wrote: post #6
Illniyar wrote: post #5

I think the functional vs OO debate is being done with a very narrow point of view. Functional came before OO and there are reasons why it became much more popular- it had much better, easier and simpler solution to the most common problems of the 90's and early 2000's, namely handling GUI and keeping single process app state (usually for a desktop app). It fares much worse in today's world of SaaS and massive parall…

> For instance I have yet to see an easy and simple to use (and as such maintainable) functional widget and gui library. Like react?

ReactComponent are also very OO, just the render function is functional

Re: Goodbye, Object Oriented Programming

#13

Post by stepvhen »

In other literature the answer to inheiratance is "composition" or "components" rather than "delegate and contain." A nitpick, but I think it better captures the meaning of the method.

Bob Nystrom wrote a very good chapter on composition in his Game Programming Patterns book [1] and is worth reading if you want to program in the OO paradigm.

[1] http://gameprogrammingpatterns.com/component.html

Re: Goodbye, Object Oriented Programming

#14

Post by acemarke »

quacker wrote: post #11
DanWaterworth wrote: post #6

Earlier quoted context omitted.

> For instance I have yet to see an easy and simple to use (and as such maintainable) functional widget and gui library. Like react?

My impression of react is that it's very object oriented. Defining reusable, stateful components is classic OO design. Now, I don't have much experience with React so maybe someone can explain why it should be considered "functional".

React is an interesting mix of functional and OO. It's OO, in that the primary approach for defining components is class-based, and components have state and lifecycles. It's functional, in that the render methods are expected to be pure functions based on component state and props, and simply output a description of what the UI should look like as a result. Also, as a whole, React definitely pushes you to view the system in terms of composition, state transformations, and pure functions, rather than imperative "toggle this, add that, update the other thing".

Re: Goodbye, Object Oriented Programming

#15

Post by skocznymroczny »

Scanner and Printer can be made interfaces, then Copier can hold reference to IScanner and IPrinter, it doesn't have to care about their concrete implementations, as long as it's something that has a scan() method and print() method, for all the copier cares it doesn't have to be a powered device at all, it could be a cloud printer and a scanner located 1000 miles away.

Re: Goodbye, Object Oriented Programming

#16

Post by Nullabillity »

Clubber wrote: post #10

Regarding: Class Copier { Scanner scanner; Printer printer; function start() { printer.start(); } } --- Placing a Start() in a PoweredDevice base class doesn't make sense in the real world. There are plenty of "powered devices" that don't have start buttons. A phone, a fish tank pump, a smoke alarm, none have a "start." A powered device should have just that, a PowerOn() and PowerOff() or SetPower(bool isOn). I would…

Indent it with 4 spaces to make HN recognize it as a code block.

Re: Goodbye, Object Oriented Programming

#17

Post by Artlav »

I wonder if someone invented the "modular" programming yet.

Judging by the UNIX paradigm of the command line tools, the idea is clearly out there.

Instead of objects, do modules - things that do one thing, and carry minimal dependencies.

You need a banana? Grab the banana module. You need a banana with ice-cream center? Feed the "center" callback of the banana module with "ice-cream" instead of "banana intestines".

You need a copier? Grab both printer and scanner.

Is there any existing language that i'm describing now?

Re: Goodbye, Object Oriented Programming

#18

Post by jeremyjh »

GFK_of_xmaspast wrote: post #2

The author's beef with encapsulation seems to be that when an object A is used as an argument in the constructor to object B, the latter needs to do a deep copy (as keeping a pointer is not "safe"), which is of course not always possible. I'm at a loss as to what this has to do with encapsulation, and even less able to understand how any language with user-defined data types is going to be able to avoid it.

It is a very abrupt dismissal along the lines of: encapsulation doesn't perfectly encapsulate, therefore it is useless.

It is not perfect because the objects your class may encapsulate may have been passed in a constructor by reference, meaning there is code outside your class that can mutate those objects.

Even in functional programming languages encapsulation is a useful concept - often in a functional language it is implemented with opaque data structures that can only be manipulated by the module which creates them (constructors are not exported).

I don't think it always means there are not shared references; it all depends on the role of the data in question.

Re: Goodbye, Object Oriented Programming

#19

Post by astrange »

eyelidlessness wrote: post #8
EdJiang wrote: post #3

Interesting. I almost though this was going to be an advertisement for Swift, since I saw this exact argument in a WWDC talk. Apple calls Swift a "protocol-oriented" programming language, and with the addition of first class value types, tries to solve these problems in their own way. I'd definitely suggest people frustrated by the problems outlined in this post to check out the Apple talk on protocol-oriented progra…

It's a great video, and clearly the design behind Swift has tried to address many of the biggest problems with modern OOP. But Swift is by necessity a multi-paradigm language that has to interface with existing OOP code. If you're writing a Mac or iOS app, you're generally writing Cocoa with either Swift or ObjC syntax. Cocoa is unbearably stateful. For a simple app, you not only don't get to work with value types, y…

In ObjC everything is a "reference type" since it's a pointer, but most of the data structures are immutable, and some of them are stuffed into tagged pointers, so they really are values after all. (Try implementing that in C++!)

CoreAnimation and bindings make AppKit very slightly more functional, but not really.

Re: Goodbye, Object Oriented Programming

#20

Post by astrange »

huahaiy wrote: post #4
GFK_of_xmaspast wrote: post #2

The author's beef with encapsulation seems to be that when an object A is used as an argument in the constructor to object B, the latter needs to do a deep copy (as keeping a pointer is not "safe"), which is of course not always possible. I'm at a loss as to what this has to do with encapsulation, and even less able to understand how any language with user-defined data types is going to be able to avoid it.

Languages with immutable data structures?

Or linear types.

Actually, immutable containers isn't good enough; you need all the leaves to be immutable too.

Post reply on HN