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

111–120 of 133 posts

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

#111

Post by platz »

ravenstine wrote: post #31

In my experience, the thing that's wrong about object-oriented programming is not the object-orientation itself, but the over-application of it. - Sometimes more "procedural" programming provides better clarity. At other times, object-orientation is a cleaner approach. Neither should be a replacement for the other at all times. - The idea that objects should reflect how we think of real objects in the physical world…

But, what do you think of the specific points that were made in the video (not the title)? Are they not worthy of discussion, since, ostensibly that is why we are here?

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

#112

Post by platz »

type0 wrote: post #57

Actually - Object-Oriented Programming is Good* https://www.youtube.com/watch?v=0iyB0_qPvWk

Namedrops golang again.. seeing a pattern here.

The claim that primitive types are better than interfaces (inside modules) reveals that he is comfortable with golang style. But this point misses that you can do _more_ things when you know the full concrete type of something, than when you program generically, only depending on the minimal requirements of what you need, which in turn opens up flexibility for the caller (constraints liberate).

Of course, one doesn't think too hard about this in golang, lacking generics

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

#113

Post by anonimito »

viach wrote: post #53
chriswarbo wrote: post #39

Earlier quoted context omitted.

> Stop that laziness and learn OOP properly, you'll find a good use for it! This is my biggest problem with OOP: proponents keep shifting the goalposts to avoid criticisms. If someone follows OOP practice, and it doesn't work out perfectly, then they must not have been doing it "properly". Hence "OOP" becomes a nebulous term, encompassing a whole bunch of approaches (encapsulation, inheritance, subtype polymorphism,…

> OOP is fraught with gotchas, misaligned incentives and lacks objectively checkable criteria Like, almost everything in programming these days (especially the frontend part)? I actually like how functional code looks like, especially ML dialects - OCaml, Haskell, F# What stopping me from trying to use these languages in prod is the lack of tooling (mostly refactoring), in the sense what Idea can offer. And when you…

Have you tried HIE/hlint for rrfactoring haskell code?

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

#114

Post by hakfoo »

vbuwivbiu wrote: post #66
felipeccastro wrote: post #64

Earlier quoted context omitted.

“Mental overhead is greatly reduced when you can assume that your data structures are immutable”. I’ve been reading lots of articles claiming that but I still haven’t understand how that’s so. If you have fifty functions all acting on the same piece of state, why would returning new objects instead of mutating would greatly reduce mental overhead? Isn’t there still mental overhead in tracking which of the fifty funct…

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.

On the other hand, if the "everything else in the universe changes" model is established and understood, that can be an excellent way to streamline and decouple things.

I could see it working well with a React-style component model-- update the state, and anything derived from it automatically changes to match.

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

#115

Post by vbuwivbiu »

UncleMeat wrote: post #99
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.

But this is (largely) a property of the functions you write rather than the data structures. You can get virtually all of the benefit in the procedural world by just writing pure functions.

when you have immutable data structures by default you get the additional assurance that other places in the code that previously used an input to a function can continue to work with their data without needing to worry that it might have been changed by its use by a function elsewhere, since that function cannot modify the data, only return a new 'version' (through structural-sharing)

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

#116

Post by vbuwivbiu »

hakfoo wrote: post #114
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.

On the other hand, if the "everything else in the universe changes" model is established and understood, that can be an excellent way to streamline and decouple things. I could see it working well with a React-style component model-- update the state, and anything derived from it automatically changes to match.

of course, if you prefer the 'anything could happen!' universe, have it at! And good luck to you

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

#117

Post by pjmlp »

willtim wrote: post #102
pjmlp wrote: post #95

Earlier quoted context omitted.

Functional generates tons of garbage and requires a very good concurrent generational tracing GC, more so than OOP languages. Only thanks to researchers like Simon Peyton Jones[1], did functional language compilers improved their code quality. [1] - https://www.microsoft.com/en-us/research/publication/the-imp...

It's actually harder to write a GC for a language like Java with both rampant mutation and plenty of garbage!

I only accept CS papers about it, do you have one at hand against Java favouring some random FP language instead?

Something of this level of quality, not random assertions on online forums.

http://kcsrk.info/multicore/gc/2017/07/06/multicore-ocaml-gc...

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

#118

Post by pjmlp »

willtim wrote: post #100
pjmlp wrote: post #91

The irony of the anti-OOP bashers is that all successful GUI frameworks are OOP based, even those written in non-OOP languages like C. Likewise all the functional programming languages that get used as example, are also not pure FP, rather multi-paradigm, also supporting concepts from OOP. "FP vs OOP: Choose Two by Brian Goetz" https://www.youtube.com/watch?v=HSk5fdKbd3o

GUI frameworks have always been OOP-based because everybody was copying Xerox Parc. But even the most successful were not always easy to use (composition and control-flow/concurrency being particularly awkward). Modern GUIs are all based on HTML/CSS these days anyway and certainly not always OOP, as demonstrated by frameworks such as react.

Those modern GUI based on HTML/CSS don't work at all without JavaScript.

Prototype inheritance is also OOP.

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

#119

Post by willtim »

pjmlp wrote: post #118
willtim wrote: post #100

Earlier quoted context omitted.

GUI frameworks have always been OOP-based because everybody was copying Xerox Parc. But even the most successful were not always easy to use (composition and control-flow/concurrency being particularly awkward). Modern GUIs are all based on HTML/CSS these days anyway and certainly not always OOP, as demonstrated by frameworks such as react.

Those modern GUI based on HTML/CSS don't work at all without JavaScript. Prototype inheritance is also OOP.

I'm not a web developer, but I don't think the OOP features of JavaScript are really used much. I once saw some jQuery code and it looked pretty functional to me.

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

#120

Post by willtim »

pjmlp wrote: post #117
willtim wrote: post #102

Earlier quoted context omitted.

It's actually harder to write a GC for a language like Java with both rampant mutation and plenty of garbage!

I only accept CS papers about it, do you have one at hand against Java favouring some random FP language instead? Something of this level of quality, not random assertions on online forums. http://kcsrk.info/multicore/gc/2017/07/06/multicore-ocaml-gc...

There are a few papers about Haskell's GC by Simon Marlow where this is discussed. The absence of mutable references is a big win for writing a concurrent collector.
Post reply on HN