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

Object-Oriented Programming is Bad (2016) [video]

m.youtube.com

Post reply on HN
Print view View original

81–90 of 133 posts

Re: Object-Oriented Programming is Bad (2016) [video]

#81

Post by nurettin »

contextfree wrote: post #63
pacala wrote: post #43

Earlier quoted context omitted.

Well duh. We’ve been sold object oriented platforms for decades with the insistence that everything is an object, hiding its internals from the world. There was tepid support for representing plain data. At the heyday of the madness people were busy building object-over-network abominations like CORBA. Even today, the most popular enterprise platform, Java, does not support value types. In the free world, the widely…

isn't "object over network" basically microservices?

It could be, if you also send the entire object with all its dependencies along with a remote procedure call. Kinda expensive and misses the point, though.

Re: Object-Oriented Programming is Bad (2016) [video]

#82

Post by vitriol83 »

one issue with OOP in practice that I've seen is the entanglement of the domain representation (member variables of a class) and the varied operations on that data (methods). Classic OOP encourages you to manipulate objects by methods rather than free functions, which combines potentially unrelated functionality in the same object.

my rule of thumb with objects is to keep the methods to a minimum, to the extent all classes are either interfaces, implementations of interfaces or pure data classes. obviously this approach will be natural to ML programmers.

Re: Object-Oriented Programming is Bad (2016) [video]

#83

Post by mjburgess »

discreteevent wrote: post #79
mjburgess wrote: post #21

Earlier quoted context omitted.

Yes, but I/O is impure and sequentially dependent, unlike mathematics. Maybe the "impedance mismatch" between pure-fp and I/O is too great, with the IO monad being the "leaky abstraction" of the FP world. Then OO is not a bad solution to an irrelevant problem, but a pretty-good solution to a bad relevant problem. EDIT: To clarify: The "problem" is change. Imperative programming relates sequential device-change over t…

Backus: Well, because the fundamental paradigm did not include a way of dealing with real time. It was a way of saying how to transform this thing into that thing, but there was no element of time involved, and that was where it got hung up. Booch: That’s a problem you wrestled with for literally years. Backus: Yeah, and unsuccessfully. http://archive.computerhistory.org/resources/access/text/201...

Thanks for the quote!

Before I wrote that comment I was actually on the anti-OO side, and in writing it, I convinced myself that maybe the FP solution wasn't great.

Good to see this wasn't a mistake!

Re: Object-Oriented Programming is Bad (2016) [video]

#84

Post by nfrankel »

Could we please stop this kind of useless statements? Aren't we developers supposed to be scientific-minded?

There is not such thing as "bad" or "good" in absolute. There are paradigmes that work better in certain contexts - and I use the word "context" in very general way here - and some that work worse.

If my consulting experience has taught me something, is that "it depends" is a valid comment most of the time. By the way, I also learned that if you stopped at this comment, you're not a good consultant.

Re: Object-Oriented Programming is Bad (2016) [video]

#85

Post by 0815test »

discreteevent wrote: post #70
contextfree wrote: post #63

Earlier quoted context omitted.

isn't "object over network" basically microservices?

No. Microservices pass data over the network. Distributed objects get handles to remote objects and then make calls to them. Sometimes there could be very many of them and it all got very complex and had poor performance. Microservices are still object oriented because each service is an object and the data being passed is a message. They are big objects. Alan Kay said that one if the mistakes with OO was not making…

CORBA actually supports both "object handle over network" and "ship some actual local object as part of a request/response". It's basically a way of addressing typical FFI/IPC concerns in a way that's actually network- and location-transparent, and that thus also addresses the concerns of distributed programming (for example, making something network-transparent introduces network faults as a possibility, and your system needs to deal with them appropriately!)

Re: Object-Oriented Programming is Bad (2016) [video]

#86

Post by smileypete »

stcredzero wrote: post #69
pacala wrote: post #43

Earlier quoted context omitted.

Well duh. We’ve been sold object oriented platforms for decades with the insistence that everything is an object, hiding its internals from the world. There was tepid support for representing plain data. At the heyday of the madness people were busy building object-over-network abominations like CORBA. Even today, the most popular enterprise platform, Java, does not support value types. In the free world, the widely…

At the heyday of the madness people were busy building object-over-network abominations like CORBA. There was even an unpleasant period of time in the 90's when people tried to make some of the Linux OS distro end-user apps run off of CORBA to bring about the interconnected "sea of objects" vision, slowing things down a lot. No wonder OO style is widely overused. It's overused in part, because it's easily sold. It's…

>Basically, software is organizational politics.

I'd go further to say that software management is (often, mostly?) organizational politics.

Software itself is about the flow of control and data, trouble often follows where dogma obscures this fundamental.

Re: Object-Oriented Programming is Bad (2016) [video]

#87

Post by jononor »

mjburgess wrote: post #21
j_m_b wrote: post #14

The problem for me in regards to OOP is the complexity related to the management of state. OOP encourages mutability and understanding the state of an object as its methods are called can be confusing when additional internal (and often times, private) methods are called. In functional programming, state is something acted upon by functions. It is as simple as f(x) = y. Reasoning in functional programming is much clo…

Yes, but I/O is impure and sequentially dependent, unlike mathematics. Maybe the "impedance mismatch" between pure-fp and I/O is too great, with the IO monad being the "leaky abstraction" of the FP world. Then OO is not a bad solution to an irrelevant problem, but a pretty-good solution to a bad relevant problem. EDIT: To clarify: The "problem" is change. Imperative programming relates sequential device-change over t…

Most of your application logic should not have to care about I/O. That is a concern which should stay at the edges. This way it is easier to reason about the program, and test it.

Re: Object-Oriented Programming is Bad (2016) [video]

#88

Post by Fellshard »

discreteevent wrote: post #77
Fellshard wrote: post #61

Earlier quoted context omitted.

A fair bit of that can be easily explained as cargo cult - a fair number of developers simply believe, because it's how they've been taught and what's been stated as fact over and over and over, that OOP is just 'how you write code'.

Ok but objects have been successful for a very long time. And this is in a field where there are more potential early adopters than most. Programmers like new stuff. I think they have been successful because in the end a lot of the world we deal with behaves like objects. Devices, processes, remote machines all accept messages and those messages have 'side effects' in that they change the future behaviour of that thi…

My current understanding (sure to change!) is this:

Objects and messaging are best at the boundaries of system components. The internals end up being far simpler to state in functional terms, where the side effects can be pushed to the edges with far less inherent complexity.

By assuming that objects are successful everywhere and always, it's really ignoring the regions where objects are more or less useful, painting over the picture with broad strokes.

By learning multiple paradigms, you're learning broad principles that map well across all languages, as well as principles that are stronger or weaker in some paradigms than others. This enables you to be much more versatile when creating systems than devoting yourself to the 'One Way To Code' mentality.

Re: Object-Oriented Programming is Bad (2016) [video]

#89

Post by dnautics »

j_m_b wrote: post #14

The problem for me in regards to OOP is the complexity related to the management of state. OOP encourages mutability and understanding the state of an object as its methods are called can be confusing when additional internal (and often times, private) methods are called. In functional programming, state is something acted upon by functions. It is as simple as f(x) = y. Reasoning in functional programming is much clo…

> OOP encourages mutability

This is largely only true in the post-bjarne soustrop OOP era. The smalltalk or actor paradigms don't necessarily encourage state mutation.

Re: Object-Oriented Programming is Bad (2016) [video]

#90

Post by dnautics »

felipeccastro wrote: post #78
vbuwivbiu wrote: post #66

Earlier quoted context omitted.

simply this: when any function returns a result, you never need to worry about anything else in the universe changing too. It's a self-contained operation with totally predictable results and no side effects.

Yeah but when you do need to mutate state, why returning a new object is any clearer than modifying an object and returning it? Especially when the new object you return is going to be used to update a state tree later. Isn’t this a side effect too, even if more indirect?

You don't have to worry about state mutating in the body of your functions, so when tracing or debugging the action of the function you can be very single minded and deterministic.

Its especially beneficial when you're doing multithreading work. I've debugged multithreading C++ and multithreaded elixir/erlang and fixing errors and identifying race conditions is night and day.

We wrote a front end in highly disciplined functional JavaScript on react with a single source of truth object in the center. I haven't touched JavaScript in a decade, and I could debug parts and add features with 100% confidence that I wasn't messing anything up (needed the frontend in a pinch so we hadn't done unit testing yet-i know I know, it's fixed now)

If you are curious, I recommend the video "boundaries" by Gary Bernhardt, of "wat" fame.

Post reply on HN