We need action towards results.

We do not need 16 hour workdays.

Ugh, no. No, no, no. Tiago isn't doing anything original. Tiago has never done anything original. This isn't Tiago's thing.

"Red" may bring to mind the color. It may bring to mind anger. It may bring to mind a bull and a matador.

All of those things happen in your subconscious, and they affect your understanding in uniquely-local ways.

So the transfer of information through speech from my mind to yours may sound very direct, but your interpretation of what I am saying is different than my interpretation of what I'm saying in very subtle ways.

Because of this, there's a very good chance that I am either completely wrong because I have misinterpreted things, that I am wrong because you have different context than I do, or that I have done a poor job of explaining things because context exists locally (in my head) that you don't have.

About this topic in particular, it was hyperbole to say "you are all doing it wrong". What is more accurate to say is that "my understanding of OOP is different in implementation than what I'm used to seeing, and I believe that my understanding is more correct/beneficial than those implementations"

This also applies to really anything with the "-er" suffix, which lead us to treat objects as "data" and "things that act upon that data".

This often shows up in code as "Thing" and "ThingManager", or something similar.

I agree, though, that mutability is detrimental, and that traditional OOP can easily lead us to believe that state is not a concern.

I do not believe that this is a problem inherent to OOP, rather it's a problem of paradigmatic implementation.

One of the biggest issues with OOP I think is the lack of a unified understanding. I think there's value in trying to define a "right" way, if only so that when we are talking about OOP, we are talking about the same thing.

I think that definition would require a volume of text, so I'm not prepared to fully elaborate, but ultimately I think that the core issues lie in our approach. We tend to think like computers when programming, which leads to OOP being a morass of procedural code masquerading as objects. Effectively, we tend toward functional decomposition. Code is boxed up into related data and behavior, and we call these "objects". What we really should be doing is approaching object design as a function of behavioral affordances.

Object design then becomes a necessary, often overlooked, step.

Object design is the first hurdle. The second is in the actual implementation, wherein we traditionally treat our objects as "data" and "behavior upon that data". I can't tell you how many times I've cringed at seeing "Thing" and "ThingManager" in code.

OOP might not be a good thing. It definitely isn't a good thing when it is done poorly. Exposing an object's data, for instance, makes the entire paradigm worthless. The widespread acceptance of `public` data members completely ruins the usefulness of OOP.

That brings up implementation languages. Programming languages really want you to use them, and they make it easy to eschew good OOP principles in favor of ease of use. Accessibility features and syntactic sugar lead not only lead us away from the paradigm, but also confuse about what it actually is.

OOP's biggest strength, and one that most of the literature doesn't go into, is it's ability to lighten cognitive load. When an object works independently of its environment, it is easy to both learn and understand that object. But we sacrifice a huge chunk of this strength in the name of "getting the work done".

I believe that good OOP resembles FP in implementation. Not completely, but much more closely than the procedural landmines we're used to would have us believe. OOP just provides a lower barrier to entry in that it lends itself well to the usage of basic programming constructs and it more closely resembles how humans think, though that could also be argued.

tl;dr - literally all of you are doing it wrong.

The gist of this is that there are shared resources in the world. Air and water are examples. We recognize them as shared resources, and we recognize that without regulations, some people would use them in ways that make them unusable for others.

Crawford makes a pitch for treating "attention" as a resource, and asserts that folks should have a right not to be addressed by mechanized means.

It's a very good read, especially for software developers, phenomenologists, or cognitive science folks.

Additionally, doesn't advertising go directly against the notion of a "free market"? The idea that "capitalism breeds competition, and competition creates quality" goes out the window when huge advertising budgets urge you to buy some cheap commodity product over a well-made product with a smaller advertising budget.

CS classes teach you to "think like a computer", and computers "think" imperatively.

OOP is inherently a declarative paradigm.

CS classes don't prepare you to think this way. So we get fancy pants CS hotshots writing "objects" that are really just functionally decomposed into classes, and we call the instantiation of those classes an "object".

I would go so far as to say OOP is NOT science. It is philosophy.

I'd also throw in "Don't use static functions" and "Write declarative code".

Honestly, I think getting rid of public getters and setters goes a LONG way toward more reasonable objects.

This is a great article that represents the fundamental problem of OOP - that developers don't actually use it.

Instead, we have a lot of procedural programmers writing code that masquerades itself as "object oriented", when in reality it's imperative functional decomposition that we're calling OOP because we don't know any better.