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

261–270 of 557 posts

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

#261

Post by toomanydoubts »

taeric wrote: post #255
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…

Hot take: OO is more powerful when you embrace stateful objects. As long as you are dealing with stateless objects, many other techniques have plenty of advantages. But, consider, OO grew in a time when the likes of Logo was strong. How do you draw a square in Logo? Usually, some form of: pen down repeat 4 straight 10 right 90 degrees But this /only/ works if you keep track of the state of the system in your mind, wh…

A polygon is a set of lines

A square is a polygon with four lines of the same length, forming 4 equal angles of 90°

A drawing can be made given a pen and a shape

The output is a drawing of square made with pen

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

#262

Post by taeric »

toomanydoubts wrote: post #261
taeric wrote: post #255

Earlier quoted context omitted.

Hot take: OO is more powerful when you embrace stateful objects. As long as you are dealing with stateless objects, many other techniques have plenty of advantages. But, consider, OO grew in a time when the likes of Logo was strong. How do you draw a square in Logo? Usually, some form of: pen down repeat 4 straight 10 right 90 degrees But this /only/ works if you keep track of the state of the system in your mind, wh…

A polygon is a set of lines A square is a polygon with four lines of the same length, forming 4 equal angles of 90° A drawing can be made given a pen and a shape The output is a drawing of square made with pen

And a line is a set of points. Your point?

That is, yes, to an extent you can expand your vocabulary to include more shapes and find ways to compose them. Or you could peel back and literally write point values. Both have uses. And both are used.

Consider, we aren't forcing all art assets to be created and described using elementary shapes. For many of those, we are closer to literally writing the canvas by hand. And then retroactively glueing to program.

It is a shame we often force a single paradigm with our code bases.

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

#263

Post by jolux »

dwohnitmok wrote: post #248
jolux wrote: post #238

Earlier quoted context omitted.

I will say plainly that I think there are situations in which mutability offers more elegant solutions than immutability, but I think most languages that offer it do it badly. I’m most experienced programming the Erlang platform via Elixir, and I think it offers a really nice midpoint between locality of state and purity. Within a process everything is immutable, and mutation requires sending a message to a process t…

> to the example of a web browser I would say, most applications are not web browsers. I should've clarified. I meant developing a web page to run on a web browser, hence the form example.

It’s a good point. UI is a situation where the classic OOP-style frameworks work really well when they’re carefully designed. I think we’re still waiting on a model for doing that with FP that doesn’t rely on passing state deep down into an expression tree like React and its descendants encourage you to do. There’s stuff like Redux but it has its own problems.

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

#265

Post by woggy »

> To see where the problem is, just think about this: If int/float were separate modules that do not depend on each other, where the (int,float) and (float,int) pairs should be defined? Nowhere? Somewhere? In either one of the modules but why?

I'm confused by this argument against multiple dispatch. Can't there be a third module that references both?

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

#266

Post by c-cube »

ummonk wrote: post #211
taurath wrote: post #122

Earlier quoted context omitted.

I appreciate that info! Its an abstraction that I had used in the past to demonstrate to other engineers that I have thought seemed somewhat useful about OOP, but as I was typing I thought to myself I'd bet that modern performant games wouldn't use active mutable entities but rather abstract into systems that change state at certain ticks so state can be much more easily managed, reasoned about and optimized. This so…

> This sort of begs the question: where does classical OOP, the one taught to all undergrad CS majors in programs that use Java or C++, really fit in nowadays? As everyone is telling you, it’s a poor paradigm that makes the developer’s job harder compared to both non-OOP approaches and better approaches (mixins / multiple inheritance). That said, one should be cognizant of the reason it was created in the first place…

C++ supports multiple inheritance though. And it still does it with (multiple) vtables. Did you mean single dispatch?

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

#267

Post by sunjester »

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…

Preach it brother.

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

#268

Post by _9omd »

I never understand all the hate for certain tools. OOP is a tool, FP is a tool, and other programming paradigms are different tools. If you're bad a software architecture and you tend to write convoluted OOP software, you're probably also going to make a mess using FP as well. Applied correctly, they can both be great tools for different problem sets.

Writing something that inherently has a lot of state, like a simulation, game, or user interface? OOP might be a good choice. Working on a backend API that's basically a database wrapper, a data processing pipeline, or something else with less inherent state, FP may be a better tool. Choose the rights tools, design good architectures, and stop blaming the language paradigm.

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

#269

Post by _9omd »

ummonk wrote: post #51
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…

Games are actually moving away from OOP by separating out state into a data oriented system.

But aren't they doing that mostly for performance via better memory layout and thus better cache locality? ie: arrays of objects vs objects of arrays. It's a sacrifice of code architecture for performance. I feel like games are actually a good example where OOP makes sense, since there is inherently so much state and encapsulation is useful.

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

#270

Post by _9omd »

Subsentient wrote: post #204

Haskell gives me headaches. I write a lot of Rust, which has elements of both. I think their approach is pretty good, though sometimes regular inheritance would just be easier. I don't hate OOP. I don't love it either. I tend to write my code in a mix of procedural and diet-OOP paradigms. It tends to produce less state, less inter-dependencies, and doesn't require abandoning stuff like mutable state. Why do I want mu…

>diet-OOP paradigms

Ha nice, I love the idea of calling it diet-OOP. "Diet-OOP, same great productivity with 99% less inheritance!"

Post reply on HN