Learning and developing projects in Distributed Systems using Elixir made me realise the same..
The faster you unlearn OOP, the better for you and your software
191–200 of 252 posts
Re: The faster you unlearn OOP, the better for you and your software
#192I'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…
> OOP will be here forever
Being the overwhelmingly dominant paradigm of the nineties and early oughts, largely because it was better for large scale programming than simple procedural and got bolted on in a very backwards compatible way to the overwhelmingly dominant procedural language of the immediately preceding period doesn't mean it is going to be around, in a significant way, forever.
> You want to know why OOP is useful and common?
Path dependence, its superiority for large products over what was dominant just before, the dominance of C before OOP became common, and the near simultaneous introduction of C++ and Objective-C which framed the debate about how to move beyond C (which C++ won, which is why not only is OOP dominant, but static class-based OOP on the C++ model, both strucurally and syntactically, is dominant within OOP.)
Re: The faster you unlearn OOP, the better for you and your software
#193A language has 2 main purposes: 1. communication 2. representation of concepts 1 is pretty obvious, and for a programming language this means communication between a person to a computer 2 might not be as clear, but if you know that people cannot count in languages that have no numbers, it becomes obvious. There is a tribe that only has 0, 1 and many, and guess what, they can't tell the difference between 7 and 8. No…
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.
Yet OOP reads more like English and functional programming more like math.
Re: The faster you unlearn OOP, the better for you and your software
#194> 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 class Weapon involved? Do we pass it as an argument to isHitBy or does Player has a currentWeapon() getter?
You have a function that has access to these objects. Based on that it will update the player and monster.
Function onAttack(from as player, to as monster, weapon)
player.addXp(weapon.xp)
monster.addHealth(-weapon.damage)
(I'm on mobile so I can't put too much code)
The reason you do this is to decouple code. You don't want the player to be aware of the monster, at least not in this scenario.
Re: The faster you unlearn OOP, the better for you and your software
#195A language has 2 main purposes: 1. communication 2. representation of concepts 1 is pretty obvious, and for a programming language this means communication between a person to a computer 2 might not be as clear, but if you know that people cannot count in languages that have no numbers, it becomes obvious. There is a tribe that only has 0, 1 and many, and guess what, they can't tell the difference between 7 and 8. No…
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 rustling a tree.
The OOP paradigm seems to map more closely to agents taking action. But perhaps my speculations aren't well grounded. I'm not sure.
Re: The faster you unlearn OOP, the better for you and your software
#196Earlier quoted context omitted.
New to OOP programming. Could you explain what sort of arguments are presented against using OOP? I am genuinely curious.
I've been programming for 15 years (so I was around for the rise of OOP). There's nothing fundamentally wrong with OOP. I still write a lot of classes. But what I haven't written in a almost a decade: code with inheritance, encapsulation or polymorphism. Nothing has exploded. Also, objects are best when used to represent actual objects (i.e. collections of data rather than collections of functions). This is OK User u…
> Also, objects are best when used to represent actual objects (i.e. collections of data rather than collections of functions).
This reminds me of a certain blog post about Java flavored OOP[1]
[1] https://steve-yegge.blogspot.com/2006/03/execution-in-kingdo...
Re: The faster you unlearn OOP, the better for you and your software
#197> For concurrency and multi-threading, I typically glue different logical components via message passing
There's a word for the programming paradigm where you glue logical components together via message passing...
Re: The faster you unlearn OOP, the better for you and your software
#198Earlier quoted context omitted.
The OOP that the author "never understood" is what we see ALL the time in enterprise and startup code. Well, is there a paradigm where you tend to see mostly good code? If so I’ve never come across it. Besides plenty of bad OO, I’ve seen bad functional programming, bad reactive programming, very bad state machines. Bad code is bad code. (And what other categories of code are you thinking of, besides “enterprise and s…
> besides “enterprise and startup” There are several: FOSS projects like Gnome/KDE can be said are neither enterprise or startup. Industrial coding (e.g. to control operations in a factory) Embedded code. Hobbyist projects. Games. Application development (desktop apps and co).
- Research software (e.g. scientific)
Re: The faster you unlearn OOP, the better for you and your software
#199This article seems to fit the template: Here are some abstract reasons why paradigm X is bad, and here is a class of problems that have a more straightforward solution in paradigm Y, therefore paradigm Y is better than X.
The real message here is that if you have a problem that nicely maps onto a relational database then use the database-like approach instead of OOP.
In my domain, I work on algorithms for a very specialized class of graphs whose structure and manipulation must obey a diverse set of constraints. I have tried implementing the core ideas using multiple popular paradigms but so far I did not find anything better than OOP.
Re: The faster you unlearn OOP, the better for you and your software
#200I'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…
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 and interoperation. Test code "actually does something" too--it helps prevent issues and ensure quality.
All of those things can be done wrong (core algorithms can have bugs, abstractions/interfaces can confuse people, tests can lie/test the wrong things), but they're all equally necessary in many cases. I think the misconception about non-core-procedure code being "cruft" automatically comes about because very early on in small projects, you don't need much more than the core. But when projects grow (to more people or just more code), other goals, like standardization/maintainability/extensibility/testability, become just as important as the goals of the core: if your added engineering staff can't add value to the company, or if your software is fatally buggy, it doesn't matter how good the shape of the original core-ideas code is, you'll lose money.