The Case Against OOP Is Wildly Overstated • Hacker News Board

Re: The Case Against OOP Is Wildly Overstated

#71

Post by PaulHoule » Fri, Jul 31, 2020, 3:34 PM UTC

eternalban wrote: post #53

PaulHoule wrote: post #34

Earlier quoted context omitted.

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…

HPC obviously prefers higher performing approaches, but how is this anecdote relevant to general programming community? The position that x2 "isn't much in the grand scheme of things" is a reasonable position. Note the "grand scheme" qualifier. Also the implicit here is "we trade performance for ---". The professor was making a sensible statement about tradeoffs when considering 'general programming approaches'. Your…

It's a potshot at everybody.

Years ago I thought "people are fundamentally good."

Now I listen to the fire and brimstone preachers on the radio and every so often it gets to me.

I wouldn't quite say "people are born in sin" but it does seem that people can't really handle computers or carbon-containing fuels or other technologies. So often I meet somebody who is said to have 'good social skills' or who 'cares about people'. Somebody will have a talk with them and tell you that they felt like they were 'listened to' but when I talk with the 'good social skills' guy an hour later about the conversation he had that left somebody impressed it is clear the 'good listener' dubbed over what he heard in his mind with what he wants.

He never gets challenged over this, but this is the problem I see. People talking past each other, not listening. I know one person who can listen to people argue for an hour and repeat back what they said in great detail, but a lot of "high performers" seem to make it through life because their bluff never gets called.

---

The model where software development starts by "determining the requirements" may itself be a "bad smell".

On some level it is all about 'satisfying the requirements', but there is something to say for putting the integrity of the system first.

For instance, say you want to build an airplane that carries a huge radar, such as an AWACS plane. If you were going to build a plane from scratch you would be overwhelmed with "non-functional requirements" such as being able to take off and land, not crash because of ice, etc. You would be driven batty by the people who want to argue with reality about those requirements (e.g. Boeing executives that couldn't reconcile the asked-for-by-customer not retraining the pilot with the 'not crash' non-functional requirement.)

If you have any sense you buy an off-the-shelf plane and stick an antenna on top and you skip the psychoanalysis. You get this

https://en.wikipedia.org/wiki/Embraer_R-99

By "design reuse" you reuse all sorts of validation, testing and experience. Many software projects go at it entirely wrong, getting into the "let's design a whole new airframe" approach.

Re: The Case Against OOP Is Wildly Overstated

#72

Post by liability » Fri, Jul 31, 2020, 3:37 PM UTC

mpweiher wrote: post #67

clktmr wrote: post #27

> The solution to the fragile base class problem and other inheritance hangovers is surprisingly simple — don’t use it If OOP provides the footgun to shoot yourself, OOP is at fault. Overall the article reads as "OOP has no problems if is used correctly". Of course that's true. I have seen well designed OOP programs, but the majority was not. The author should ask the question, why OOP is applied the wrong way so oft…

Sure 90% of OOP is crap, that's because 90% of everything is crap. https://en.wikipedia.org/wiki/Sturgeon%27s_law

10% of OOP isn't crap? God I wish I could believe that was true. Unfortunately, Sturgeon's Law is just a lower bound.

Re: The Case Against OOP Is Wildly Overstated

#73

Post by andreareina » Fri, Jul 31, 2020, 3:40 PM UTC

skrtskrt wrote: post #8

The author is right about ORMs. They are ridiculously over engineered solutions. (My experience is largely with Django and SQLAlchemy ORMs) As soon as you want to do something that's not already perfectly built in, everything becomes a mess of impenetrable hacks. Autogenerated Django migrations are unstable and often need to be edited to to be correct or make any damn sense. It also encourages to people to blur or ju…

I get that, and I'm comfortable writing raw SQL but as the system grows larger and requirements change I inevitably run into the fact that raw SQL doesn't compose. For me the query builders hit that sweet spot of mapping almost one-to-one to raw SQL, while giving me composition when I need it.

Re: The Case Against OOP Is Wildly Overstated

#74

Post by tempodox » Fri, Jul 31, 2020, 3:42 PM UTC

dnautics wrote: post #16

skrtskrt wrote: post #8

The author is right about ORMs. They are ridiculously over engineered solutions. (My experience is largely with Django and SQLAlchemy ORMs) As soon as you want to do something that's not already perfectly built in, everything becomes a mess of impenetrable hacks. Autogenerated Django migrations are unstable and often need to be edited to to be correct or make any damn sense. It also encourages to people to blur or ju…

Always prescribing raw sql is dangerous: You typically want something managing your sql queries if there's user input because scrubbing out SQL injections is hard and it's not something you should be 'rolling your own'

You should use ODBC or one of its siblings anyway. Never use printf() or raw string concatenation for SQL queries yourself.

Re: The Case Against OOP Is Wildly Overstated

#75

Post by platz » Fri, Jul 31, 2020, 3:42 PM UTC

andreareina wrote: post #73

skrtskrt wrote: post #8

The author is right about ORMs. They are ridiculously over engineered solutions. (My experience is largely with Django and SQLAlchemy ORMs) As soon as you want to do something that's not already perfectly built in, everything becomes a mess of impenetrable hacks. Autogenerated Django migrations are unstable and often need to be edited to to be correct or make any damn sense. It also encourages to people to blur or ju…

I get that, and I'm comfortable writing raw SQL but as the system grows larger and requirements change I inevitably run into the fact that raw SQL doesn't compose. For me the query builders hit that sweet spot of mapping almost one-to-one to raw SQL, while giving me composition when I need it.

99% of the time you should'be be composing SQL.

If you need composition at the DB level, that is what Views are for.

Re: The Case Against OOP Is Wildly Overstated

#76

Post by jeffffff » Fri, Jul 31, 2020, 3:49 PM UTC

Barrin92 wrote: post #56

thom wrote: post #22

Earlier quoted context omitted.

I'm not sure you're responding directly to the point the parent made. Even if state is encapsulated, objects are mutable. Many people believe reasoning about programs in which lots of mutable objects coordinate is harder than some of the alternatives (e.g. pure functions, immutable data etc).

depends on the domain. In anything that has say, a very structured 'data flow' in one direction, like in finance or accounting or versioning immutability works well as a concept. In other domains like say, game development it feels forced and out of place. If actual usage of paradigms is an indication rather than belief then it doesn't look like functional programming really is intuitive, it tends to be very useful i…

game development seems to be moving away from OOP and towards entity component systems and data oriented design. i've heard arguments that OOP's killer application is desktop guis, which i could buy, but those become less and less relevant daily. (caveat: my experience is entirely in back end and low level software and anything i say about front end or ui development should be highly suspect)

Re: The Case Against OOP Is Wildly Overstated

#77

Post by JackMorgan » Fri, Jul 31, 2020, 3:49 PM UTC

jayd16 wrote: post #66

lgessler wrote: post #4

This doesn't speak to what I consider some of the most dangerous parts of OOP, which include the assumptions that tightly binding data and code is helpful, and that statefulness is fine to freely sprinkle throughout your program.

Objects are essentially structs with namespaces and methods with implicit this params. If you can't have state then you throw structs out too. If you're going this far, you're essentially throwing away typing as well. Are you actually just opposed to private fields?

Separating functions and state has nothing to do with the type system. Otherwise how could you put types on the parameters to static functions? Check out F#, OCaml, or Haskell for plenty of examples of how you can have strong static types without mixing state and functions in a scope together.

Re: The Case Against OOP Is Wildly Overstated

#78

Post by treis » Fri, Jul 31, 2020, 3:55 PM UTC

platz wrote: post #75

andreareina wrote: post #73

Earlier quoted context omitted.

I get that, and I'm comfortable writing raw SQL but as the system grows larger and requirements change I inevitably run into the fact that raw SQL doesn't compose. For me the query builders hit that sweet spot of mapping almost one-to-one to raw SQL, while giving me composition when I need it.

99% of the time you should'be be composing SQL. If you need composition at the DB level, that is what Views are for.

I'm not sure why you think we shouldn't be composing SQL. What about for cases like:

User.banned.posts.flagged where we want all flagged posts from banned users.

Posts.flagged.today where we want all flagged posts from today

User.created_today.posts.flagged where we want all flagged posts from users created today

Re: The Case Against OOP Is Wildly Overstated

#79

Post by tempodox » Fri, Jul 31, 2020, 3:58 PM UTC

jayd16 wrote: post #68

tempodox wrote: post #18

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.

Calling mutability an OOP issue doesn't make sense to me. You could certainly have immutable objects. You can event have immutable object inheritance. Maybe you just want a language where fields are immutable by default. If you're just passing around raw structs or arrays, it's way harder to manage blocks of data.

Obviously mutability is not an issue in OOP alone. Note, however, how I said, “how normal is it that our methods mutate instance variables?”. A well-skilled programmer can always choose to not use the footgun a language hands them. But those are not the only people to consider.

As for structs, you could qualify the pointee of a pointer argument as `const` but this is as rare in C as the equivalent is in OOP languages.

Re: The Case Against OOP Is Wildly Overstated

#80

Post by platz » Fri, Jul 31, 2020, 4:01 PM UTC

treis wrote: post #78

platz wrote: post #75

Earlier quoted context omitted.

99% of the time you should'be be composing SQL. If you need composition at the DB level, that is what Views are for.

I'm not sure why you think we shouldn't be composing SQL. What about for cases like: User.banned.posts.flagged where we want all flagged posts from banned users. Posts.flagged.today where we want all flagged posts from today User.created_today.posts.flagged where we want all flagged posts from users created today

Or you could just create a View for flagged posts and join on that as appropriate, no ORM needed.

There's probably some room for limited compositional SQL, but there are ways to get that without a full ORM, given your type system is expressive enough.