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

The faster you unlearn OOP, the better for you and your software

dpc.pw

Post reply on HN
Print view View original

201–210 of 252 posts

Re: The faster you unlearn OOP, the better for you and your software

#201

Post by dejaime »

I pretty much believe that all we have are bad solutions. OOP is a bad solution that is acceptable at a set of problems. Data oriented designs is an also bad solution that is acceptable at a set of problems. Anyone who has ever used any paradigm for big projects can do a write-up about how bad that paradigm is.

The problem of OOP is not OOP, but actually knowing only OOP. That creates a lot of hammer and nail problems. The same would be true if data-oriented had the same popularity, and everything was data oriented.

So, unless you ARE going to give me a __good__ solution, a silver bullet, it is silly to state that a whole paradigm is an absolute inferior. Especially when all you can give me is examples of bad paradigm-tech-problem matches or snippets of incompetent usage.

Re: The faster you unlearn OOP, the better for you and your software

#202

Post by bassman9000 »

crazygringo wrote: post #33
jryan49 wrote: post #26

> The vast majority of essential code is not operating on just one object – it is actually implementing cross-cutting concerns. Example: when class Player hits() a class Monster, where exactly do we modify data? Monster's hp has to decrease by Player's attackPower, Player's xps increase by Monster's level if Monster got killed. Does it happen in Player.hits(Monster m) or Monster.isHitBy(Player p). What if there's a c…

Great point... but doesn't it continue to prove the author's point that this is needlessly complex? It strikes me as bad design if something as simple as an action (hit) now needs to become it's own class that is instantiated merely to execute a single function and then have to delete itself. That just feels like insane overhead/boilerplate, no? The argument here is that it's far better to have player and monster be…

And you end up having functions that look like.

hit(player, monster, weapon, damage_modifier, arena, previous_turn, next_turn, global_modifiers)

because the author didn't like, or understood encapsulation.

Re: The faster you unlearn OOP, the better for you and your software

#203

Post by scarface74 »

naasking wrote: post #184
scarface74 wrote: post #180

Earlier quoted context omitted.

Once you use a language for awhile you develop boilerplate blindness just like people have developed ad banner blindness.

I'm sure, and yet it remains true that you spend a lot more time scanning and scrolling your wheel mouse than is necessary. You can also fit far less context on screen, making debugging and "learnability" harder.

There is overhead but with that overhead becomes maintainability, type safety, etc.

For me, on one side is Python. No compiler overhead, very little boilerplate, no complicated IDE etc but no type safety and harder to maintain for larger projects and C# with all of the overhead of a heavyweight compiler but the type safety and great IDE makes it perfect for larger projects where multiple people will be working on it simultaneously.

For simple scripting, where can I mentally keep everything in my head and think through how one change will affect everything else, Python is my go to language. For larger projects C#.

I’ve hated all scripting languages I’ve encountered over 20 years, but for some reason I love Python. It’s also a great teaching language.

Re: The faster you unlearn OOP, the better for you and your software

#204

Post by dragonwriter »

crazygringo wrote: post #33
jryan49 wrote: post #26

> The vast majority of essential code is not operating on just one object – it is actually implementing cross-cutting concerns. Example: when class Player hits() a class Monster, where exactly do we modify data? Monster's hp has to decrease by Player's attackPower, Player's xps increase by Monster's level if Monster got killed. Does it happen in Player.hits(Monster m) or Monster.isHitBy(Player p). What if there's a c…

Great point... but doesn't it continue to prove the author's point that this is needlessly complex? It strikes me as bad design if something as simple as an action (hit) now needs to become it's own class that is instantiated merely to execute a single function and then have to delete itself. That just feels like insane overhead/boilerplate, no? The argument here is that it's far better to have player and monster be…

> It strikes me as bad design if something as simple as an action (hit) now needs to become it's own class

Why, it's a noun in the problem domain. Why shouldn't it be a class?

> that is instantiated merely to execute a single function and then have to delete itself.

This may be inefficient in some language implementations because of limits of optimization, but there is no fundamental reason that, if that's all you do with it, the compiled code or runtime behavior needs to be much different than if it were just a procedure call.

On the other hand, lots of times you will want to do more than that with actions occurring in the domain then executing them (queueing, logging/serializing, etc.) and having a datatype for the event (a class in class-oriented OOP) supports that.

Re: The faster you unlearn OOP, the better for you and your software

#205

Post by naasking »

scarface74 wrote: post #203
naasking wrote: post #184

Earlier quoted context omitted.

I'm sure, and yet it remains true that you spend a lot more time scanning and scrolling your wheel mouse than is necessary. You can also fit far less context on screen, making debugging and "learnability" harder.

There is overhead but with that overhead becomes maintainability, type safety, etc. For me, on one side is Python. No compiler overhead, very little boilerplate, no complicated IDE etc but no type safety and harder to maintain for larger projects and C# with all of the overhead of a heavyweight compiler but the type safety and great IDE makes it perfect for larger projects where multiple people will be working on it…

I agree Python is good for teaching, but the maintainability and type safety aren't features of the boilerplate. This is clear when considering languages like OCaml, Haskell and other languages featuring type inference.

Re: The faster you unlearn OOP, the better for you and your software

#206

Post by dragonwriter »

naasking wrote: post #205
scarface74 wrote: post #203

Earlier quoted context omitted.

There is overhead but with that overhead becomes maintainability, type safety, etc. For me, on one side is Python. No compiler overhead, very little boilerplate, no complicated IDE etc but no type safety and harder to maintain for larger projects and C# with all of the overhead of a heavyweight compiler but the type safety and great IDE makes it perfect for larger projects where multiple people will be working on it…

I agree Python is good for teaching, but the maintainability and type safety aren't features of the boilerplate. This is clear when considering languages like OCaml, Haskell and other languages featuring type inference.

Python has an external static type checker with type inference.

Re: The faster you unlearn OOP, the better for you and your software

#207

Post by coolaliasbro »

This is coming from a business consultant (BA/PM and configuration primarily), but in my experience, it seems like the OOP paradigm is fine in most cases and is leveraged in a functional/compositional fashion typically, so I fail to see the issue with OOP a paradigm. Generics and polymorphism can be used to basically create a functional system that only uses domain specific classes to handle edge cases.

In short, OOP as currently used, in my experience working on numerous RIA/municipal/county government enterprise document management systems, seems perfectly adequate to the tasks at hand and can be used in an effectively functional way.

Re: The faster you unlearn OOP, the better for you and your software

#208

Post by coolaliasbro »

gerbilly wrote: post #41
crazygringo wrote: post #28

A lot of these initial points I don't think are relevant -- you can model your data in objects, data structures are complex because business needs are complex, data models wind up having implicit graph dependencies as well... BUT, "cross-cutting concerns" is where I think the main valid argument is. In my experience, OOP is just way too restrictive of a model, by forcing you to shoehorn data and code into an object h…

>In my experience, OOP is just way too restrictive of a model... Maybe, but if it's cross cutting concerns that bother you, just combine OOP with an aspect oriented programming library.

Exactly! So long as the developer approaches the solution with the expectation of scaling and extensibility from the get, this should not be a problem.

Re: The faster you unlearn OOP, the better for you and your software

#209

Post by coolaliasbro »

corebit wrote: post #74

> Data is more important than code Nope. Right there at the beginning is where the author goes off track. Computation itself is the most important aspect of computing. Code and data are just complexity to manage. > Do I have a Customer? It goes into class Customer. Do I have a rendering context? It goes into class RenderingContext. I whole heartedly agree with this. The naive approach to domain modelling is to classi…

"I whole heartedly agree with this. The naive approach to domain modelling is to classify the primitives of a domain into classes and stop there. In actuality, the processor of those primitives is likely what your class should be, and those primitives ought to be methodless data structures."

This is what I did not have the ability to articulate as well in an earlier comment. As far as I understand parent, the takeaway is that often OOP goes astray when the developer is unable to identify that a given need can be handled by generics/a parent class and instead instantiates their own class.

Re: The faster you unlearn OOP, the better for you and your software

#210

Post by smnplk »

coolaliasbro wrote: post #207

This is coming from a business consultant (BA/PM and configuration primarily), but in my experience, it seems like the OOP paradigm is fine in most cases and is leveraged in a functional/compositional fashion typically, so I fail to see the issue with OOP a paradigm. Generics and polymorphism can be used to basically create a functional system that only uses domain specific classes to handle edge cases. In short, OOP…

What is the point of OOP then, if you are using it in a functional way ? This just proves author's point.

Do you truly use it in a functional way though, that would mean, that you care about separation of state and identity. If you are mostly using immutable collectons/objects with pure functions, then it's fine, but this is not OO.

Post reply on HN