Live data from Hacker News

The Case Against OOP Is Wildly Overstated

medium.com

301–310 of 312 posts

Re: The Case Against OOP Is Wildly Overstated

#301

Earlier quoted context omitted.

That is OOP, regardless of what the language is.

It’s an OOP technique, yes, but functions operating on structures predate OOP and are used in practically every program, so they’re not enough to claim that a program is written in OOP style without the term losing all meaning. For me, true OOP requires some sort of inheritance and/or runtime method dispatch, at least.

OK, I'll go along with that. The description given doesn't contain a full "implementation" of what OOP is considered to be.

Can we at least agree that limiting operations on the structure to the code that controls that structure is following the definition of encapsulation, which is what I should have said anyway?

Re: The Case Against OOP Is Wildly Overstated

#302
post #295

Earlier quoted context omitted.

Hacker news was written in Arc, which, AFAIK, explicitly has no object-oriented features.

What’s your point?

To the downvoting-without-commenting crowd: The GP's claim is that OOP is "the most successful programming paradigm in history." Responding that there exists a single website that happens to be written in a non-object oriented language, which by all accounts is the only remotely useful thing written in that language, is not exactly a scathing rebuttal of the claim. It's not even relevant, honestly.

Re: The Case Against OOP Is Wildly Overstated

#303
post #290

Earlier quoted context omitted.

There are plenty of potential side-effects for vaccines as well. The last time I had one, I had a relatively unpleasant reaction. So I'm not saying that there aren't fair criticisms of object-oriented programming. But "the case against OOP" is not proven by real numbers and repeated experiments. It's the most successful programming paradigm in history. The evidence for the success of OOP is more overwhelming than for…

That it's successful doesn't mean it's also a good idea. To quote Dennis Ritchy: "C is quirky, flawed, and an enormous success". I feel this could probably be paraphrased to OOP as well. OOP isn't super terrible, but it does mix some good ideas with bad ones. Newer languages tend to not be fully "OOP" but do include some of the better ideas from it. OOP isn't the end-goal of programming, it's a stepping stone. Same a…

> That it's successful doesn't mean it's also a good idea.

No, but success brings out nothing but contrarians. You don't get an article on hacker news saying everything is fine and working well even if that is the reality.

You can't make money selling alternative medicine by claiming that medicine works. Newer languages, in my opinion, are going backwards in a lot of ways out of fear of ideas that shouldn't be feared.

Re: The Case Against OOP Is Wildly Overstated

#304
post #271

Earlier quoted context omitted.

If you have something that is something else in almost every way except for one or twos details inheritance is far superior than interfaces. The other benefit of inheritance, that often goes unmentioned, is the ability to fix bugs in other products. I've had to inherit from some library/framework class to fix a bug in that technology -- it might be a rare situation but it's absolutely invaluable to have that option.

I'll have to take your word for it that such things exist but experience so far has taught me that: 1. When I have something that is something else with minor modifications that my and everyone else's lives will almost always be better when if I solve the reuse issues with some composition and the is-a problem with an interface. 2. That when I inherit from a class I don't control to fix a bug in that class the fix is…

> if I solve the reuse issues with some composition and the is-a problem with an interface.

I'm not sure how that's better -- you're just implementing inheritance with more steps.

> is both very fragile and usually very short lived.

It is and I know you'd make that point but it's better to be fragile and short lived than completely impossible. I have a least one of these hacks that was completely necessary that has been in place for years.

Re: The Case Against OOP Is Wildly Overstated

#305
I still think procedural and OOP code requires 10-15 IQ points (for some theoretical "good" measurement of IQ) than FP.

Vocal proponents of languages will be on the more intelligent end of the spectrum to begin with, so this economic / structural "advantage" of OOP isn't as apparent, especially since such advocacies revolve around idealism and the hidden biases of it paying their bills.

Re: The Case Against OOP Is Wildly Overstated

#306
post #290

Earlier quoted context omitted.

That it's successful doesn't mean it's also a good idea. To quote Dennis Ritchy: "C is quirky, flawed, and an enormous success". I feel this could probably be paraphrased to OOP as well. OOP isn't super terrible, but it does mix some good ideas with bad ones. Newer languages tend to not be fully "OOP" but do include some of the better ideas from it. OOP isn't the end-goal of programming, it's a stepping stone. Same a…

> That it's successful doesn't mean it's also a good idea. No, but success brings out nothing but contrarians. You don't get an article on hacker news saying everything is fine and working well even if that is the reality. You can't make money selling alternative medicine by claiming that medicine works. Newer languages, in my opinion, are going backwards in a lot of ways out of fear of ideas that shouldn't be feared…

Obviously being against the common trend is always going to get more attention, but it makes no sense to assume that those people are wrong strictly because of that.

The fact that vaccines are widely used doesn't make anti-vax stupid. Anti-vax is stupid, because a lot of real research has gone into vaccines, and they really do work. The arguments anti-vaxers use are not based on reality, and can easily be proven wrong. The same can NOT be said about programming paradigms.

There is no proof that OOP produces more elegant, simpler, higher quality software with smaller programming effort than other paradigms. OOP isn't proven to work; it's proven to be an attractive choise

Re: The Case Against OOP Is Wildly Overstated

#307

IMO, OOP just puts too many footguns at your disposal, the most dangerous one being mutability (how normal is it that our methods mutate instance variables?). The larger a system grows the more mutability will make it even harder to understand and control. It may be tolerable in small-scale embedded software, but outside of that we should make use of the better alternatives that modern hardware affords us.

I knew a professor who worked on Density Functional Theory which can be used to derive many of the properties of materials from first principles. (e.g. "Does Iron Conduct Electricity?") This involved running FORTRAN programs on what was then considered a large supercomputer (256 nodes.) Asked what he thought about any programming technique that cost a factor of 2 in performance and he told me it was a non-starter whe…

Part of the communication problem is that “high”, “performance”, and “needs” are all relative, which makes the combined phrase super-ambiguous. If you reach for a thing that’s advertised as “2x faster” because it means you’ll get your answer in one month instead of two, I think reasonable people would agree that’s a reasonable optimization in that specific case. If you reach for it simply because it’s advertised (perhaps not reliably) as “2x faster”, that’s more of a premature optimization if you don’t know along what axes, or under what conditions, that speedup obtains.

Having said that, “2x improvement” can also be read as “an order of magnitude improvement (base 2)”, which does become more meaningful in general as x gets large.

Re: The Case Against OOP Is Wildly Overstated

#308

Earlier quoted context omitted.

Creating a new value only gives you a stale data problem if you had pointers to the old value. You don't have to have pointers like that, it's a choice. To take an obvious example, you might load a value from a database (company or employees, say), create a new value (with the higher salary, say), then write the new value to the database.

I think the point being made here was that alternative approach don't eliminate the difficulties of global state. Simply using immutable object doesn't make all your problems go away, it makes them different. I think it makes them better, but let's not pretend that all the challenges of dealing with state can be eliminated.

Quite so. I was just trying to make some small suggestions on how to handle the consequences of making that object immutable.

Here are some links along the same lines:

* _Aggregate Roots_ in DDD limit pointers, https://martinfowler.com/bliki/DDD_Aggregate.html * Guidance on where to mutate, _Functional core, imperative shell_, https://www.destroyallsoftware.com/screencasts/catalog/funct...

> using immutable object doesn't make all your problems go away, it makes them different

Yes, and here is a concrete example of the kind of 'different' problems you get: nested immutable structures, say `a.b.c.d`, become harder to update than simply `a.b.c.d = newValue`. The functional solution for this is 'lenses' (and other 'optics'). My favourite Kotlin framework that I use in my day job provides lenses for HTTP - URL query parameters, request and response bodies and so on - which work very well.

Re: The Case Against OOP Is Wildly Overstated

#309

I still think procedural and OOP code requires 10-15 IQ points (for some theoretical "good" measurement of IQ) than FP. Vocal proponents of languages will be on the more intelligent end of the spectrum to begin with, so this economic / structural "advantage" of OOP isn't as apparent, especially since such advocacies revolve around idealism and the hidden biases of it paying their bills.

IQ points less or more? I assume you mean OOP requires 10-15 IQ points less, but it is very hard to do OOP correctly so I don't think that's true.

Re: The Case Against OOP Is Wildly Overstated

#310

Earlier quoted context omitted.

The only real contention seems to be whether "functional programming language" should describe languages that merely facilitate functional programming (e.g. lisp), or only to those that enforce it (Haskell.) Otherwise, whether or not a procedure is a function is about as clear cut as you can get. It either is or it isn't, it's not subjective.

> whether or not a procedure is a function is about as clear cut as you can get Definitely. If it returns a single value then it's a function. If it does not return a value, it's a procedure. (Pascal) All procedures are functions (C) All procedures and methods are functions (Swift) A Function procedure is a series of Visual Basic statements enclosed by the Function and End Function statements. (Visual Basic) ...

I'm not sure if you mean this comment to be a joke, or....

https://en.m.wikipedia.org/wiki/Pure_function

Post reply on HN