Object-Oriented Programming is Bad (2016) [video] • Hacker News Board

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

#131

Post by bklaasen » Mon, Mar 18, 2019, 12:37 AM UTC

Fellshard wrote: post #88

discreteevent wrote: post #77

Earlier quoted context omitted.

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…

Credit where it's due; that sounds like Gary Bernhardt's "functional core, imperative shell": https://www.destroyallsoftware.com/screencasts/catalog/funct...

Previous HN discussion: https://news.ycombinator.com/item?id=18043058

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

#132

Post by braindouche » Mon, Mar 18, 2019, 2:45 PM UTC

sisu2019 wrote: post #49

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…

In theory this sounds great but in reality every major application, game, operating system and even website is written in an OOP style. Why is that? People should first answer that question. Yeah, real existing software has flaws like every other thing in reality but at least it exists unlike a significant piece of fp style software. I like fp and I think it has a lot to teach but I think it's a bit presumptuous to a…

>In theory this sounds great but in reality every major application, game, operating system and even website is written in an OOP style. Why is that? People should first answer that question.

Ok, try this on for size: OOP in general has one characteristic that makes it fantastic for large-team development, and that's extending over replacing. OOP makes it easy to never remove or change any existing code, and also "easy" to make changes or fixes by only adding more code. I wouldn't call it a good thing, but it does enable enormous numbers of people to all work on a codebase productively at the same time. I think this, more than anything else, is the power of OOP.

> And if OOP is so horrible why do so many people write OOP style PHP and javascript where they really don't have to?

Numbers. OOP supports big teams, so there are lots of OOP programmers in the wild. I genuinely think Javascript is sucking up to the Java developers of the world, and PHP is genuinely better for adopting OOP bits and pieces, but I'm not entirely sure why OOP devs and Java devs in particular seem to be immune to the industry mantra of "stay current and learn new things".

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

#133

Post by willtim » Mon, Mar 18, 2019, 5:45 PM UTC

pjmlp wrote: post #125

willtim wrote: post #120

Earlier quoted context omitted.

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.

I don't recall any of Marlow's papers having a table comparing performance of Haskell tracing GC implementations versus the tracing GC implementations available across several JVM implementations.

You never defined what you meant by a "good concurrent GC", only now are you asking for "performance" numbers.

My point is that writing a GC for Java has in fact proved very difficult. It took Sun and Oracle many man years and different GC designs to get where they are today. So it seems Java also needs a "good" concurrent GC. With both functional and OOP languages generating a lot of garbage and sharing language features, I don't see a big difference in requirements in practice. And sure enough, Clojure/Scala seems to work well using the JVM GC and F# seems to work well with the .NET GC too.

I think the burden of proof rests with you and your statement that the concurrent GC situation is somehow more challenging for an FP language.

> I only accept CS papers about it

Me too