6 ms·

Object-Oriented Programming: "Luckily the industry doesn’t really use this term any more" Wait really? What world are they living in? Am I just out of touch or

by TT-392 4y ago

Object-Oriented Programming: "Luckily the industry doesn’t really use this term any more" Wait really? What world are they living in? Am I just out of touch or something?

Banana699 4y ago
Bubbles. Software isn't just whatever the author's particular bubble happens to be. OOP is still very alive and well, mainly because an aweful lot of the most widespread languages are OOP, how can you talk about java and python without using OOP ?
mattarm 4y ago
OOP became a marketing term, but no longer sells designs, languages, etc. OOP alone used to be hot. Now it is either just assumed, or eschewed, or considered ambiguous. We’re getting there with FP, too. OOP…which kind? FP…which kind?
- TT-392 4y ago
  Just because it is not a selling point, doesn't mean people don't still use the term a lot. I used to only know C, OOP is still a relatively new thing for me.
- mypastself 4y ago
  Please note that the author never specifies that their context is marketing or management. They instead use a far broader term, “computing”. It would be very difficult for huge swaths of developers to do their job without using OOP and other attendant terms.
AndrewDucker 4y ago
You aren't out of touch. Some people are just living in bubbles. There's still a massive amount of Java, C# and other OOP work going on out there.
- ncmncm 4y ago
  Just because it is in Java (equivalently, C#) does not mean it is OO. Java just makes coding the non-OO parts of a system awkward and unnatural. Of course most parts of most systems are non-OO.
imtringued 4y ago
OOP is pretty well defined. 99% of the time it means type dependent namespaces. Class A.foo and Class B.foo both represent separate namespaces in which a field or method foo can be defined, the name space is directly tied to a type. In Haskell every function is defined in what amounts to be a global namespace. This is particularly annoying when you have records that share the same attribute names. You might argue that structs fit this definition but they are missing type dependent namespaces for functions/methods and the fact that you can define fields and methods to only be accessible within their type dependent namespace, not outside of them.
- tome 4y ago
  Is using structs in C OOP by that definition?
  - ncmncm 4y ago
    Would be, but isn't.
- ncmncm 4y ago
  By that, then, you mean undefined. It once meant that three features appeared: encapsulation, inheritance, and constrained runtime binding. Any time it is used without implying those, it is just more or less noise. That said, OO has become a niche technique: it fits certain problem spaces well, others very badly. Any big enough system will have some parts that could meaningfully be described as mostly OO. But there is no value in purity, so none in distinguishing those bits, particularly, or excluding non-OO notions there. Trying to cram all solutions into the OO shoe by providing no support for any other organization (cough Java) damaged the brand, probably irreparably. It still makes sense to say part of a system has an OO flavor, for exposition, but there is little value, otherwise.
  - tengwar2 4y ago
    I think we have to look to Alan Kay for an original definition, since he invented the term, and according to him, inheritance is not a necessary part of object orientation. In Smalltalk (and various Lisps), inheritance is something that is created from objects and messages, not a fundamental feature of the language. In [one place](http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay...) he defines it as "OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things."
commandlinefan 4y ago
I've observed the same for at least the past 20 years: most people who are working as programmers can't or won't write object-oriented code, nor will they write functional code. For whatever reason, even if they're working in a language like Java that's fundamentally object oriented, they'll write primarily procedural code (mostly static functions accessing datatypes with no functionality besides getters and setters): either they don't understand that there's an alternative, or they see some benefit in it.
- OkayPhysicist 4y ago
  I'm a functional guy myself, so I think OO is a downgrade from plain ol' procedural code. Regardless, the procedural soup model gets applied because it's the end result of too many hands touching any given codebase. Elegant abstractions take time to grok, and are opinionated. If you start a project with a UML diagram, I'm going to be disgusted. If I start a project by defining the whole thing as a left fold over an infinite stream, someone else is going to be appalled. Abstractions have a target audience, and that rarely aligns with corporate hiring practices. If you're working on a given project for a long time, you'll appreciate the abstractions. If you just want to monkeypatch in a quick fix/feature because your boss told you to, you find where it fits, you hammer it into place, and call it a day. Rinse repeat for a few years, and all corporate code becomes procedural.

by TT-392 4y ago

Object-Oriented Programming: "Luckily the industry doesn’t really use this term any more" Wait really? What world are they living in? Am I just out of touch or something?

Banana699 4y ago

Bubbles. Software isn't just whatever the author's particular bubble happens to be. OOP is still very alive and well, mainly because an aweful lot of the most widespread languages are OOP, how can you talk about java and python without using OOP ?

mattarm 4y ago

OOP became a marketing term, but no longer sells designs, languages, etc. OOP alone used to be hot. Now it is either just assumed, or eschewed, or considered ambiguous. We’re getting there with FP, too. OOP…which kind? FP…which kind?

TT-392 4y ago
Just because it is not a selling point, doesn't mean people don't still use the term a lot. I used to only know C, OOP is still a relatively new thing for me.
mypastself 4y ago
Please note that the author never specifies that their context is marketing or management. They instead use a far broader term, “computing”. It would be very difficult for huge swaths of developers to do their job without using OOP and other attendant terms.

AndrewDucker 4y ago

You aren't out of touch. Some people are just living in bubbles. There's still a massive amount of Java, C# and other OOP work going on out there.

ncmncm 4y ago
Just because it is in Java (equivalently, C#) does not mean it is OO. Java just makes coding the non-OO parts of a system awkward and unnatural. Of course most parts of most systems are non-OO.

imtringued 4y ago

OOP is pretty well defined. 99% of the time it means type dependent namespaces. Class A.foo and Class B.foo both represent separate namespaces in which a field or method foo can be defined, the name space is directly tied to a type. In Haskell every function is defined in what amounts to be a global namespace. This is particularly annoying when you have records that share the same attribute names. You might argue that structs fit this definition but they are missing type dependent namespaces for functions/methods and the fact that you can define fields and methods to only be accessible within their type dependent namespace, not outside of them.

tome 4y ago
Is using structs in C OOP by that definition?
- ncmncm 4y ago
  Would be, but isn't.
ncmncm 4y ago
By that, then, you mean undefined. It once meant that three features appeared: encapsulation, inheritance, and constrained runtime binding. Any time it is used without implying those, it is just more or less noise. That said, OO has become a niche technique: it fits certain problem spaces well, others very badly. Any big enough system will have some parts that could meaningfully be described as mostly OO. But there is no value in purity, so none in distinguishing those bits, particularly, or excluding non-OO notions there. Trying to cram all solutions into the OO shoe by providing no support for any other organization (cough Java) damaged the brand, probably irreparably. It still makes sense to say part of a system has an OO flavor, for exposition, but there is little value, otherwise.
- tengwar2 4y ago
  I think we have to look to Alan Kay for an original definition, since he invented the term, and according to him, inheritance is not a necessary part of object orientation. In Smalltalk (and various Lisps), inheritance is something that is created from objects and messages, not a fundamental feature of the language. In [one place](http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay...) he defines it as "OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things."

commandlinefan 4y ago

I've observed the same for at least the past 20 years: most people who are working as programmers can't or won't write object-oriented code, nor will they write functional code. For whatever reason, even if they're working in a language like Java that's fundamentally object oriented, they'll write primarily procedural code (mostly static functions accessing datatypes with no functionality besides getters and setters): either they don't understand that there's an alternative, or they see some benefit in it.

OkayPhysicist 4y ago
I'm a functional guy myself, so I think OO is a downgrade from plain ol' procedural code. Regardless, the procedural soup model gets applied because it's the end result of too many hands touching any given codebase. Elegant abstractions take time to grok, and are opinionated. If you start a project with a UML diagram, I'm going to be disgusted. If I start a project by defining the whole thing as a left fold over an infinite stream, someone else is going to be appalled. Abstractions have a target audience, and that rarely aligns with corporate hiring practices. If you're working on a given project for a long time, you'll appreciate the abstractions. If you just want to monkeypatch in a quick fix/feature because your boss told you to, you find where it fits, you hammer it into place, and call it a day. Rinse repeat for a few years, and all corporate code becomes procedural.