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

Case against OOP is understated, not overstated (2020)

boxbase.org

Post reply on HN
Print view View original

221–230 of 557 posts

Re: Case against OOP is understated, not overstated (2020)

#221

Post by sodapopcan »

sodapopcan wrote: post #214
AnimalMuppet wrote: post #131

Earlier quoted context omitted.

Let me separate out immutability for a moment. If I don't have immutability, then if I can call foo(thing), then I can write bar(), and then call bar(thing). Bar can now alter thing. So my encapsulation can be broken by someone just writing a function. (This is the same problem that C had with structs - anyone could write a function to alter the data in your struct, and thereby put it in an inconsistent state.) Now,…

Your last sentence there is pretty unnecessary. Moving along... Echoing my sibling comment: immutability is a defining feature of FP, so there is no way to put it aside if we're talking about FP. As for the rest of your argument, I'm a bit of meathead and maybe haven't followed it fully. My thought is that in OO, an instance of an object can be passed some data that it processes along with its own internal state. If…

I also want to say that I'm in no claim that FP is a silver bullet. All-in-all, programming is terrible, lol (naw, I love it). I've just found myself carrying around fewer footguns since I converted and generally less stressed and confused by what's going on... even when reading less-than-ideal legacy code.

Re: Case against OOP is understated, not overstated (2020)

#222

Post by a-dub »

taurath wrote: post #14

In my mind, state is the real enemy impacting: comprehension, brittleness towards making changes, and the surface area exposed to potential bugs. OOP as frequently implemented, while claiming to encapsulate state, ends up creating so much more. In accordance with this view, I think project architecture should be approached with an emphasis around how much state is necessary for it to run. This is why simulations like…

if you're writing something like a wrapper service around a database, there should be no state at all. (i'd argue it's high time that databases moved forward with respect to security and hardening such that they can be accessed nearly directly or... directly)

if you're building a thing where state is required, then yes, it should be minimized. but i'd argue against dogmatic use of immutable data records and really think about what that sort of design is attempting to achieve: reduction of sprawl in places in the code where a piece of data is updated.

the goal is to put all that stuff in one easy to find place. that can be manifested or violated (sometimes with great acrobatics) regardless of whatever rules are followed. (even oop!)

Re: Case against OOP is understated, not overstated (2020)

#223

Post by throwawaylinux »

wainstead wrote: post #217
throwawaylinux wrote: post #65

Back in the 90s OOP was touted as revolutionary. The next big thing, would completely change programming. If something wasn't object oriented, it was looked down upon. SQL even got on the bandwagon. It was said that very complex inheritance structures, operator overloading, and all this other stuff would (somehow) make it far easier to write and understand complex projects. Many seemed to have taken and repeated this…

> Were there ever any real objective [hah] studies done about how much it improved software development? And did they show a significant improvement? I think years of hard experience across the industry found out that, for example, multiple inheritance and operator overloading caused more problems than they solved. Both features were taught and advocated back in the day, and now "there be dragons" signs have sprung u…

Right. What I want to know is, what was the basis for claiming all this would be so great in the first place? It appears to have been almost entirely free of any evidence, as far as I've been able to tell.

It's mind boggling to me when we see the kinds of people in the industry and their demands for data and evidence when it comes to other subjects.

Re: Case against OOP is understated, not overstated (2020)

#224

Post by john-shaffer »

dwohnitmok wrote: post #179
taurath wrote: post #164

Earlier quoted context omitted.

I appreciate the thought process here, and I'd want to spend more time thinking it over before a full response - though I think it maybe goes a little bit too into etymology for my taste! My immediate comment is that working memory is a measurable finite resource that developers have to use. The more entities they have to track in order to model the part of the system they're working on, the more usage of working mem…

First off I don't think this is quite the way Hickey thinks about the issue (though I suspect he would agree about the working memory part), especially with the comment about etymology /s!(it's a meme in Clojureland that every Hickey presentation and library must contain at least one slide on/mention of etymology) In particular Clojure as a whole embraces an ideology of "open systems" vs "closed systems" where we sta…

In production, I may only want one connection pool to a DB, and in that case global state is pretty much equivalent to passing state as an argument. Development in a Clojure REPL is a different story. I have one connection pool for the dev server, and a separate pool to run tests against. The test db is re-created from a template between each test run, without affecting the dev db at all. I can trivially have multiple test pools if I want to run tests concurrently.

I also have a separate service that the server makes calls to, which doesn't run on this server in production (it has its own production server), but does run in dev and test. Each dev/test system runs a separate instance of this service, which has its own separate connection pool(s), and setting this up was trivial.

Needless to say, failures are reproducible and meaningful. There is no mocking -- we test against real local services with real local DBs. (There are still some remote service calls which I'm slowly replacing, and some flakey, unavoidable remote dependencies in a few browser tests).

I didn't do anything special to make this possible other than naming the config files "service-name-config" instead of just "config". It is just the natural result of passing state in explicit arguments. The same is not true of global state.

Re: Case against OOP is understated, not overstated (2020)

#225

Post by djmetzle »

Meh. Is this a hot debate still?

No mention of Ruby or smalltalk in this post, which i think of as "true" OO languages, down to the runtime. The ruby object model has its merits! Sandi Metz's POODR is a fantastic intro into OO _and_ a compositional approach to design.

FP vs OO is always a false dichotomy for sure. Actors and messaging appear in FP languages. Inheritance surely has nothing to do with OO. Inheritance means nothing for data, and it's almost a bug to extend Record types.

In short, this post seems to rage against inheritance and blind use of design patterns, not the spirit of OO. But the post also qualifies that "that is what an OO advocate would say".

Consider Typescript. The same program can be written with `class`es, or as a module of "loose" types and functions. Really, lets pick a mix that best represents the problem we're solving? I think OO can be a _useful complement_ to FP and other paradigms.

Re: Case against OOP is understated, not overstated (2020)

#226

Post by Jtsummers »

djur wrote: post #181
bcrosby95 wrote: post #109

Earlier quoted context omitted.

> Conjecture: programming is hard, especially as the scope of the system becomes larger and the problem domain more complex. This means that all programming tools and techniques have at least some problems and downsides. Yes. > You can do this with FP too. But FP isn't used so much... So close.... The problem is single paradigm tools. No single paradigm fits all of a problem. And in my experience, OOP is particularly…

What are these very popular single paradigm OOP languages? The closest thing I can think of is Java.

Java isn't even single paradigm.

Re: Case against OOP is understated, not overstated (2020)

#227

Post by ecshafer »

djmetzle wrote: post #225

Meh. Is this a hot debate still? No mention of Ruby or smalltalk in this post, which i think of as "true" OO languages, down to the runtime. The ruby object model has its merits! Sandi Metz's POODR is a fantastic intro into OO _and_ a compositional approach to design. FP vs OO is always a false dichotomy for sure. Actors and messaging appear in FP languages. Inheritance surely has nothing to do with OO. Inheritance m…

I only played with Small talk in school as it was before my time but it was great. As I am working at a large Ruby shop currently, Ruby is a lovely language. Ruby really does solve many of the issues I had with Java. Its a very elegant language. I think the behavior of any object taking messages is great, though thats not used much in professional code it seems. I think more people should give ruby a shot.

I do wish it were a bit faster ,but hopefully truffle ruby, sorbet, yjit, etc. can put in the work to fix that.

Re: Case against OOP is understated, not overstated (2020)

#228

Post by ecshafer »

zamalek wrote: post #206

My issue with OOP is: Design Patterns: Elements of Reusable Object-Oriented Software. I don't take issue with the authors, with their insights, or anything related to the content of the book. It's that the book exists at all: it's a book filled with solutions to imaginary problems. When using a procedural language the first thing you do is start implementing a solution. When using OOP, you first have to solve the ima…

Design patterns as a concept exist without OOP. Even in procedural code or functional code you have concepts like a strategy pattern, or how do I get version X vs Y of object A. These things arise in any code you are writing a sufficient complexity.

Re: Case against OOP is understated, not overstated (2020)

#229

Post by dwohnitmok »

jolux wrote: post #208
dwohnitmok wrote: post #179

Earlier quoted context omitted.

First off I don't think this is quite the way Hickey thinks about the issue (though I suspect he would agree about the working memory part), especially with the comment about etymology /s!(it's a meme in Clojureland that every Hickey presentation and library must contain at least one slide on/mention of etymology) In particular Clojure as a whole embraces an ideology of "open systems" vs "closed systems" where we sta…

There's a lot to think about in your comments in this thread but I have a nitpick about functional programming style here. > In fact maybe it's nicer to have that implicit state strewn everywhere instead of having to carry around values which are irrelevant for the bulk of a function body and only relevant for a single part of a subfunction. I would call this an anti-pattern in FP. It's often a symptom of trying to r…

> Threading mostly-irrelevant state through a bunch of different functions is a sign that your program is under-abstracted.

The problem is that often you do want fairly complex state in the leaves of the tree, but want very little of it in anything else. Web browsers are a classic example of this. Pure FP solutions such as Elm that completely eschew the idea of local mutable state require a lot more ceremony to implement something like a form (the classic thorn for Elm users). By forcibly moving up the state to the root, you sometimes end up needing to pull some fairly severe contortions.

E.g. the usual answer to move the state back up to the root in the land of statically-typed, pure FP is to express it in a return type (e.g. a reader or state monad, culminating in the famous ReaderT handler strategy in Haskell) or in the limit bolt on an effect system instead. The usual answer in impure FP is to accept some amount of mutable state and just rely on programmers not to "overdo" it.

But from a certain point of view, writing an elaborate effect system whose very elaborateness might cause performance issues and inscrutable error messages sounds suspiciously like trying to work around a problem in visualization with an over-engineered code solution. And from another perspective it feels a bit like a trick. If some function has a lot of state, then I would hope by opening up the definition of the function I'd see how it all works, but with an effect system all of a sudden I've split things up into an interpreter that actually performs the mutation and an interface that merely marks what mutation is to be done. It feels like I've strewn logic around in even more places than if I just had direct stateful, mutable calls there!

Re: Case against OOP is understated, not overstated (2020)

#230

Post by zackees »

lkrubner wrote: post #215

For my part, I've tried to be as overstated as possible, as you can tell from the title "Object Oriented Programming Is An Expensive Disaster Which Must End." Written in 2014, and discussed several times here on Hacker News, it remains the most popular technical essay that I've written: http://www.smashcompany.com/technology/object-oriented-progr...

No post body was provided.
Post reply on HN