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

231–240 of 252 posts

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

#231

Post by Paradigma11 »

zippy5 wrote: post #135
gameswithgo wrote: post #86

Earlier quoted context omitted.

No true Scotsman. >Because it's easy There are lots of cases when forcing yourself to stick to OOP styles or programming is much less easy. You could look at various comparisons of code line counts of equivalent programs between C# and F# code as some basic examples. I don't mind having classes that can inherit available in a language, but languages like Java and C# that force you to use only those things leads to a…

I would suggest that boilerplate is small price to pay for having a compiler enforce design discipline and conventions. Remember that code should be written for both the run time environment and next coder who will have to understand it. Constraints enforced in java often make it easier for the next dev. I suspect part of this is that in unconstrained languages, there are so many ways of doing the same thing that pat…

To go with the above example of c# vs f#. I find f# far easier to understand because the compiler enforces a strict top down compilation order. Combined with the encouraged basic type system (records and DU) this enforces a very rigid design structure that is easy to understand.

Compared to that c# is a ball of wool where not only have you to follow all strands but also understand when something will happen.

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

#232

Post by fenomas »

scarface74 wrote: post #132
fenomas wrote: post #121

Earlier quoted context omitted.

> You end up with: > Player.hits(Monster).with(Weapon) I think games are a particularly pathological case for OOP, and as such probably not a good example for the article's case. But FWIW, the problem with what you describe (and with OOP for games generally) is that game logic tends to be way too polymorphic for code like that. That is, players don't just Hit() monsters, they also hit items, traps, breakable terrain,…

I find the fluent style programming to be much more readable. But in OOP you would define an IHittable interface or use AOP like you suggested.

You can define iHittable and get the code to compile, but it doesn't make the actual issue (polymorphism) any easier to tackle. I think eschewing inheritance in favor of aspects is definitely the way to go.

(Of course, you can wrap everything in a fluent-style interface either way - that part is orthogonal to all the rest.)

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

#233

Post by hota_mazi »

armitron wrote: post #227
hota_mazi wrote: post #167

Earlier quoted context omitted.

Right. Because Objective C and Smalltalk are such resounding successes, uh?

Going by what you write here, we should all praise PHP and Javascript. Popularity amongst the masses of 9-5 brogrammers who code for money and have no artistic sense when it comes to programming doesn't really imply quality. All the programming languages that are truly technically great - today - have small userbases. They're not easily digestible by mediocre coders, require some upfront effort and an open mind. Sinc…

You do not sound condescending at all!

While it's true that popularity does not equal quality, one should be careful to go full tilt in the other direction and assert that non popularity means quality.

Objective C and Smalltalk were decent languages twenty years ago, but terrible languages by today's modern standards, starting with the fact that they're both dynamically typed, which we know today, is an evolutionary dead end in PLT.

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

#234

Post by atoav »

zbentley wrote: post #200
jstimpfle wrote: post #75

Earlier quoted context omitted.

Yes, OOP is easy. At least the layers of sedimentary cruft were comparatively easy to write. The parts that actually do something, not easier in the slightest. It's still procedural code that must move data. (Usually that code is much less straightforward in OOP because it has to deal with so much boilerplate that is in the way of accessing the actual data).

> The parts that actually do something This comes up a lot, and I think there's a broken assumption here. The core business logic of a product "actually does something", to be sure. But that doesn't mean that all the other code is somehow less important or pointless. Code that allows multiple people to work on the same abstractions in slightly different ways "actually does something" too--it facilitates cooperation a…

I had similar thoughts. Before I started learning how to program Rust.

All your arguments ( standardisation, maintainability, extenseability, readability) are true, but they are not necessarily always brought to you by (ab-)using OOP.

I experienced that OOP can be at times something that can make people see everything as a nail, because all they have got is a hammer. In the end a lot of the real work a piece of code is the transformation of data. OOP often distracts inexperienced programmers from this, which leads to unnecessary complexity in bussiness logic and interfacing alike.

Thinking in the line of data transformation is useful because you will focus on two things: how to do this transformation fast/simple/extensible and what the most useful abstraction over said transformation is.

You can (and given some complexity, must) achieve all of the mentioned attributes without using classes at all. And sometimes taking classes away can make things so much better.

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

#235

Post by atoav »

dragonwriter wrote: post #206
naasking wrote: post #205

Earlier quoted context omitted.

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.

I learned Rust after learning Python. I do solve similar problems in Rust as I did in Python.

The single worst thing that python thought me, is that it would be cool/useful to make classes. Some call that a “sea of objects”. When I tried similar concepts in Rust I learn quickly that things started falling apart much faster at a point reached much earlier.

However this was also happening in Python – only much later in the game. This made me realize: instead of focusing on the flow of data and useful abstractions (”blackboxes”) over it, I actually made a lot of classes and objects and tried to pipe them into each other, without giving too much thought on the flow of data.

It felt so reassuring to make a Car-class for car objects, wit a Wheel class for its wheels, that I somehow forgot to think about the actual data that I wanted to work on.

The danger of OOP is IMO that it highly encourages bringing in preexisting patterns of abstraction that seem to make so much sense that you discard other, potentially more useful abstractions.

I have more broken Python code than I have broken Rust code, and one of the reasons is, that a lot of the stuff I did in Python (rightfully so) wouldn’t even compile in Rust.

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

#236

Post by atoav »

Novashi wrote: post #172
jstimpfle wrote: post #150

Earlier quoted context omitted.

> When something else outside monster/weapon/damage/environment has to change the hit calculations When something should change, you edit the freakin' code. There is no way around it. If you have different kinds of hits then you make different procedures. e.g. magicPixieDustHit(monster, pixieDust, weapon, damage). > Side effects are terrible for maintenance and debugging FP apologetists want to make you believe that,…

>When something should change, you edit the freakin' code. If you have different kinds of hits then you make different procedures. e.g. magicPixieDustHit(monster, pixieDust, weapon, damage). I dunno, maybe aim for something a little better than writing an exponential amount of functions for all of your interactions. >FP apologetists want to make you believe that, but side effects are the actual point of the program.…

Please consider watching (or reading) this talk. If you are interested in how a modern Game ECS works and why indeed OOP often isn’t the way to go: https://kyren.github.io/2018/09/14/rustconf-talk.html

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

#237

Post by atoav »

mabbo wrote: post #47

I'm always confused when people criticize OOP, because most of the time the criticisms they use are just plain bad programming. Or they're using hyperbole that isn't really useful. You want to know why OOP is useful and common? Because it's easy. Easy things allow for faster development, faster onboarding of devs. Humans need a mental models of things and OOP very explicitly gives it. But like most easy things, OOP s…

Sometimes there is just no right way when it comes to using OOP. Sure OOP is often a hammer that will make everything look like nails, but for some problems it really just isn’t the right approach at all.

For a very good example when this is indeed the case, watch (or read!) this amazing talk by kyren on Game ECS: https://kyren.github.io/2018/09/14/rustconf-talk.html

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

#238

Post by pas »

mannykannot wrote: post #229
pas wrote: post #221

Earlier quoted context omitted.

What's wrong with config/value holder objects? Most OOP languages can store them as simple structs in memory.

It has nothing to do with efficiency. Insofar as Bassman9000's example indicates a real problem (and there are a couple of ways it might do so, ultimately leading back to the poor use of abstraction and separation-of-concerns), stuffing the arguments (or any other weakly-related collection of variables) into an ad-hoc struct (or object) having no real cohesion is simply sweeping the dust under the rug, and is just as…

Why is no cohesion, in, let's say a HitEvent object? This knows the target, source, method (weapon, magic, physics like falling down), etc. You can make handy helper methods and subtypes depending on important concerns.

I don't get the adhocness of the example.

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

#239

Post by mercer »

segmondy wrote: post #152
chx wrote: post #72

Earlier quoted context omitted.

> You want to know why OOP is useful and common? Because it's easy. With as much proof as you have given, let me offer you a counterargument: it is common because academia loves OOP. It's easy to teach, it's easy to test. It is most decidedly not easy and very often not useful. My favorite example of how everything falls apart in due time is the color of a car. That's it, right? A car has a color. A Porsche Panamera…

It's not OOP that's the problem, but your mental model. There's no OOP language that says a car has to have one color. You can define an object to have more than one color, or maybe instead of having a color have a color pattern. How creative is your imagination? If you use a tuple of (r, g, b) to represent color in a functional language, you will still have the same problem when you realize you can have multiple col…

Sometimes it's not primarily that it's impossible to model this stuff in OOP, but rather that the change in requirements over time can be more difficult to implement in an OOP codebase. At least that's been my experience.

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

#240

Post by mercer »

dwaltrip wrote: post #195
hliyan wrote: post #122

Earlier quoted context omitted.

OOP in that sense leans very close to concepts of normal humans. Objects, things objects can do, objects have separate responsibilities, etc. This is not entirely accurate. Human languages are closer to functional languages: they have verbs that operate on nouns. Verbs are not attached to nouns, but rather, the operation of the verb is dependent on the noun.

I think the claim may have been that the brain is usually doing something more akin to "noun.verb(...)", rather than "verb(noun, ...)". It's a very interesting question. The concepts of agency and intention are very important in human cognition. If we hear a sound, we wonder if some intentional agent (predator, enemy, etc) that we need to be aware of caused the sound. Or if it was something inanimate like the wind ru…

It is a very interesting question. As an FP fan, I'd argue that we model the world primarily in terms of the actions we want to perform, with the objects secondary. But I'm obviously biases.

Furthermore, perhaps how we actually model the world mentally is or should not bear much of a relation to how we do so in code.

I haven't made my mind up about these things, even though I lean towards the FP approach in my day to day coding. But I love (constructive) discussions about the issue because somehow I feel they're about more than just 'making shit work'. Aside from the occasional flame-war I really like the discussions on HN about this stuff, and usually there are at least a few comments that give me new insight into both OOP and FP.

Post reply on HN