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

The Big OOPs: Anatomy of a Thirty-Five Year Mistake

computerenhance.com

Post reply on HN
Print view View original

81–90 of 193 posts

Re: The Big OOPs: Anatomy of a Thirty-Five Year Mistake

#81

Post by lisbbb »

nine_k wrote: post #30
nottorp wrote: post #5

Any way to find out what the 35 year mistake was without being "engaged" for hours on that video?

In short, in my opinion: - Encapsulation / interfaces is a good idea, a continuation of the earlier ideas of structured programming. - Mutable state strewn uncontrollably everywhere is bad idea, even in a single-threaded case. - Inheritance-based polymorphism is painful, both in the multiple (C++) and single (Java) inheritance cases. Composable interfaces / traits / typeclasses without overriding methods are logicall…

Over multiple decades, I have come to reject all of it! Even interfaces.

I watched over and over again people writing code to interfaces, particularly due to Spring, and then none of those interface ever got a second implementation done and were never, ever going to! It was a total waste of time, even for testing it was almost a total waste of time, but I guess writing stubbed test classes that could pretend to return data from a queue or a database was somewhat useful. The thing is, there were easier ways to achieve that.

Re: The Big OOPs: Anatomy of a Thirty-Five Year Mistake

#82

Post by rr808 »

I really dont understand his reasoning. If you have a pointer to the base class different implementations are polymorphic and its hidden from the caller. That is the whole point and it means you can have an engine with a base class in a library, then different people can derive from it and use that engine.

I think his definition of OO is different to what we've got used to. Perhaps his definition needs a different name.

Re: The Big OOPs: Anatomy of a Thirty-Five Year Mistake

#83

Post by henning »

rr808 wrote: post #82

I really dont understand his reasoning. If you have a pointer to the base class different implementations are polymorphic and its hidden from the caller. That is the whole point and it means you can have an engine with a base class in a library, then different people can derive from it and use that engine. I think his definition of OO is different to what we've got used to. Perhaps his definition needs a different na…

what is your reasoning? if you make your own object system, that is indeed polymorphic. do you now feel the need to model the world in your application?

Re: The Big OOPs: Anatomy of a Thirty-Five Year Mistake

#84

Post by lisbbb »

voidhorse wrote: post #62

As someone who has always found popular OOP stupid (programming is closer to math , not linguistics —write functional programs!) I'm glad Casey is going out there and giving talks like this. If extensive academic research and extensively documented benefits couldn't convince the industry to abandon OOP in favor of functional style maybe an everyman like Casey finally can. A lot of so-called programmers and systems "e…

Yes! It became extremely tiresome to defend my position as a functional programmer from less experienced people who had big egos. Time and time again I would be accused of "not having enough experience" simply because I disagreed with just so many stupid things that have gone on over the years--the zealots I ran into where people with big chips on their shoulders who just had to be "right" instead of being inquisitive and thoughtful. I never had anything to prove, I just wanted to write tight, testable, maintainable code.

Re: The Big OOPs: Anatomy of a Thirty-Five Year Mistake

#85

Post by lisbbb »

troad wrote: post #79
voidhorse wrote: post #62

As someone who has always found popular OOP stupid (programming is closer to math , not linguistics —write functional programs!) I'm glad Casey is going out there and giving talks like this. If extensive academic research and extensively documented benefits couldn't convince the industry to abandon OOP in favor of functional style maybe an everyman like Casey finally can. A lot of so-called programmers and systems "e…

> programming is closer to math, not linguistics It's worth pointing out that actual linguistics is not unlike maths, e.g.: https://en.wikipedia.org/wiki/Formal_grammar , https://en.wikipedia.org/wiki/X-bar_theory , etc. There's an awful lot of vibes-and-feels nonsense about language in the popular press, which one ought not confuse with linguistics proper. In fact, as Casey mentions in this talk, a lot of the earlie…

[flagged]

Re: The Big OOPs: Anatomy of a Thirty-Five Year Mistake

#86

Post by lisbbb »

fc417fc802 wrote: post #80
voidhorse wrote: post #62

As someone who has always found popular OOP stupid (programming is closer to math , not linguistics —write functional programs!) I'm glad Casey is going out there and giving talks like this. If extensive academic research and extensively documented benefits couldn't convince the industry to abandon OOP in favor of functional style maybe an everyman like Casey finally can. A lot of so-called programmers and systems "e…

> A lot of so-called programmers and systems "engineers" act like religious zealots. Rather ironic given that in this very comment section I'm largely seeing that behavior associated with people appealing to Casey as an authority as an excuse not to engage with intelligently written counterpoints. I certainly won't defend the historic OOP hype but a tool is not limited by how the majority happen to use it at any give…

Just let me ask you this: How many years have you been in this game? I came in around 1990, but my first professional coding job wasn't until after I finished a BS in CS and Math in 1995. To me, having the perspective I have, OOP looks in retrospect to have been an enormous boondoggle championed by the Boomer generation. It as all people who did Waterfall, wrote endless requirements documents before coding anything, and did quarterly or even yearly code releases, if you can even imagine that.

Re: The Big OOPs: Anatomy of a Thirty-Five Year Mistake

#87

Post by lisbbb »

vjvjvjvjghv wrote: post #66
voidhorse wrote: post #62

As someone who has always found popular OOP stupid (programming is closer to math , not linguistics —write functional programs!) I'm glad Casey is going out there and giving talks like this. If extensive academic research and extensively documented benefits couldn't convince the industry to abandon OOP in favor of functional style maybe an everyman like Casey finally can. A lot of so-called programmers and systems "e…

I was around when OOP became popular in the 90s. I think it was a huge step forward. Problem is that with almost every useful paradigm at some point consultants and zealots take over and push things to an extreme that doesn't work. And when problems show up, it's because you didn't do it right. Happened with OOP, NoSQL, Agile and probably many others. I don't see how functional style won't go differently.

Despite spending untold hours learning and using C++ and Java, I never fully believed that OOP was anything great. It always felt so forced to code everything in terms of classes rather than just modules of code that have similar responsibilities.

Re: The Big OOPs: Anatomy of a Thirty-Five Year Mistake

#88

Post by hackthemack »

lisbbb wrote: post #73

I complained a lot about OOP all throughout my 25 years a developer. I wrote a ton of C++ and then Java and nobody can refute my expertise with those languages. I saw so many people make mistakes using them, particularly with forcing taxonomies into situations that weren't conducive to having them. Then, when I began complaining to my colleagues about my feelings, I was ostracized and accused of "not having a strong…

Similar experience. I would be the one the entire team would turn to when a really hard problem to debug came up. Yet, when I would say that OOP is not great and is over-complicating the code, I would be scoffed at. I never could reconcile how I was "leaned on" to fix things, but ignored in proposing different paradigms.

I recently read a quote, paraphrasing, Orthodoxy is a poor man's substitute for moral superiority.

Re: The Big OOPs: Anatomy of a Thirty-Five Year Mistake

#89

Post by inopinatus »

chrisg23 wrote: post #52

This is an excellent talk. It digs really deep into the history of OOP, from 1963 to 1998. The point is that in 1998 the commercial game "Thief" was developed using an entity component system (ECS) architecture and not regular OOP. This is the earliest example he knows of in modern commercial programming. During his research into the history of OOP he discovered that ECS existed as early as 1963, but was largely forg…

You can do ECS in any programming paradigm. It’s not incompatible with OO at all. There’s no need for the object model to be congruent to a static representation of a domain, in a line-of-business app it is much better for it to be congruent to workflow and processing.

Heck I’ve even done ECS in Rails for exactly this reason.

I never accepted the Java/C++ bastardisation of OOP and still think that Erlang is the most OO language, since encapsulation and message passing is so natural.

Re: The Big OOPs: Anatomy of a Thirty-Five Year Mistake

#90

Post by Jtsummers »

lisbbb wrote: post #87
vjvjvjvjghv wrote: post #66

Earlier quoted context omitted.

I was around when OOP became popular in the 90s. I think it was a huge step forward. Problem is that with almost every useful paradigm at some point consultants and zealots take over and push things to an extreme that doesn't work. And when problems show up, it's because you didn't do it right. Happened with OOP, NoSQL, Agile and probably many others. I don't see how functional style won't go differently.

Despite spending untold hours learning and using C++ and Java, I never fully believed that OOP was anything great. It always felt so forced to code everything in terms of classes rather than just modules of code that have similar responsibilities.

You must not mean C++ when you write about having to write everything in terms of classes. Java, yes, with the requirement that the nearest thing to a free standing function is a static method in a class (which becomes in effect a regular old module). But C++? You could, and many did, pretend it was fancy C and only deal with classes when it came to using things like collections and streams (because they were useful).
Post reply on HN