10 ms·

OOP “is really just a common sense extension of structured programming”

39 points by jjuliano 4y ago

Twisol 4y ago
For those wondering, the quote in the submission is in the first paragraph of the Preface, page vii.
kerblang 4y ago
OOP gives excellent benefits as concerns scope control, and since many of us are suffocating to death under overwhelming scope, there's a win. As for the handwaving about simulation & modelling and We Must Design The Matrix and all that nonsense... not applicable to most programming.
- bluefirebrand 4y ago
  You're probably not suffocating under scope, you're suffocating under State. OOP helps encapsulate state to make it more manageable. I am starting to reject OOP because I find working at reducing state is much more fruitful than encapsulating it.
  - kaba0 4y ago
    Reducing state and OOP is not against each other, I believe FP+OOP is a good match. Many problems are data-oriented where FP is hands down better, but I think OOP helps exactly at the side-effecting edges.
swatcoder 4y ago
It’s true. But eventually a junior developer realizes that a Triangle is an PolygonalOpenFrameMetallicPercussionInstrument and it now has 4kb of private state, 307 inherited member functions, and floods your console when its logged. I love OOP, but caution is indeed warranted.
- pier25 4y ago
  You can totally have OOP without inheritance. In fact "composition over inheritance" is a thing in the OOP world. https://en.wikipedia.org/wiki/Composition_over_inheritance https://en.wikipedia.org/wiki/Composition_over_inheritance
  - WesolyKubeczek 4y ago
    But why not have both?
    - adgjlsfhk1 4y ago
      inheritance makes your code slower even if you don't use it.
      - WarChortle18 4y ago
        That's a very broad statement care to back it up?
        Kim_Bruning 4y ago
        Presumably thinking of virtual methods, in the context of C++ ? At least that used to make your code very slightly slower. Might be measurable in a tight loop?
        adgjlsfhk1 4y ago
        This is one of several places. Some others are. You don't know how much memory an object of a given type takes to instantiate. This makes object allocation slower. This also means that you can't allocate a Vector<T> inline. It has to be a vector of pointers. You don't know what fields a type has. This makes GC scanning more expensive. You can't optimize the layout of a type. If you know an object doesn't have subtypes, you can move it's fields around to reduce padding. If you want to be able to look up fields quickly, you need to put all the fields of the supertype first in memory which will increase the size of your objects.
ReptileMan 4y ago
And yet common sense is(was) severely lacking in most OO languages implementations.
- slively 4y ago
  If it’s not common, maybe it’s not common sense?
  - astrange 4y ago
    If you have to justify proposals with explicit reasoning (or conversely, if you're allowed to), then it's hard to reject them because they go against common sense, since it's hard to just say "my intuition told me this would be bad".
    - slively 4y ago
      Agreed, of course so many reasoned conversations it seems like at some point have a moment of intuition because not everything can be known at the time. I think this is the stuff that makes engineering fun. That combination of well reasoned responses sprinkled with gut feeling and heuristics.
AprilArcus 4y ago
OOP's greatest crime is needlessly adding an I-thou dichotomy to the realm of programming languages. The "switching" or context sensitive properties of deictic pronoun referents is one of the last and most difficult linguistic skills that first language learners acquire. Class instances add deixis to programming languages, which never needed it and don't benefit.
- MauranKilom 4y ago
  Could you translate this into English, please?
  - nighthawk454 4y ago
    attempt: a class and an instance of a class aren't the same thing, which creates cognitive load to distinguish
  - samatman 4y ago
    I think they're complaining about `this`, which I also find annoying, but don't feel the need to dress that up in fancy terms. My issue with `this` and things like it is that the first argument (the 'object') is usually the most important thing, and it's easier to read methods if they have a name. Ok, you can call this deixis but do you need to? Clearly not.
    - maxbond 4y ago
      Your fancy terms are someone else's terms. It was critical to their point about how deixis specifically being difficult for new language learners. Addutionally I enjoyed skimming the Wikipedia articles and considering programming languages as languages; I got more out of it than I do most HN comments. I think it's fair to skip over a comment using terminology you find tiresome, be it because you aren't familiar, or you find it irritating for some reason, or for any reason; it's your time. I think it's unnecessary to insist we all use the same terminology, as that just limits what conversations can be had and who can have them. One of the things that makes HN feel magical is when people from a weird discipline jump in to give their two cents, and they add value to the community when they bring their terminology with them.
bumblebritches5 4y ago
echelon 4y ago
The biggest problem with OOP is the concept of class hierarchies. They're an unnatural representation of units of work and state that force obtuse topological reasoning where there should be none. Traits and type classes are a much better solution that offer far more flexibility, yet still allow the programmer their own balance of expressiveness and rigidity. Of course data can have defined behavior. Don't try to marshall it into genetic lineages of parents and ancestors. That's an orthogonal and entirely made up problem.
- zozbot234 4y ago
  Traits and type classes are broadly the same as interface inheritance. So there still is a hierarchy, it's just restricted to the interface layer as opposed to impacting the implementation.
mikewarot 4y ago
In Turbo Pascal/Delhi/Free Pascal/Lazarus, the OOP seems quite sane. The whole abstract factory generator class iterator thing I see in other languages scares the bejeezus out of me.
- bandyaboot 4y ago
  How do you iterate over your abstract factory generator classes in those languages?
mixedCase 4y ago
Objects are a good tool. Isolating some kinds of state in more manageable units can be very handy while remaining maintainable. Even inheritance can be nice under the right circumstance. Object oriented programming? An unmitigated disaster.
hudon 4y ago
In terms of readability and maintainability, one problem with OOP is the development process that tends to go with it, where you're asked to create upfront the separation of concerns, before code has had a chance to run and breathe for a while. Most of the time, you end up being wrong on how things should be segregated, and your behavior ends up fragmented across a variety of objects, making it difficult to easily see the flow of your program. Actions related to a Widget end up not actually being neatly encapsulated in a Widget, and encapsulation is one of the major selling points of OOP. It's probably best to start off a solution with plain old data structures, and plain old functions (ie. procedural style). Build with that until right abstractions or separations emerge.
- colordrops 4y ago
  Also, within the context of an individual class, variables can be modified and accessed anywhere in the class, creating all the same problems as global variables.
  - bostonsre 4y ago
    If the single responsibility principle is followed and cohesion is strong, it should help mitigate these concerns. Creating large uber classes can quickly become troublesome.
- arinlen 4y ago
  > Most of the time, you end up being wrong on how things should be segregated, and your behavior ends up fragmented across a variety of objects, making it difficult to easily see the flow of your program. This can only become a problem if you pay little to no attention to modularization, software architecture, and even encapsulation. The responsibility of a paradigm and a language is to allow a developer to freely express their concepts. The programming paradigm is not to blame if the developer chooses to express poorly thought-out ideas that are riddled with detrimental consequences.
  - julienfr112 4y ago
    the problem is not about software development, it's about business logic that change, when a new client arrive and want new features, some feature where not usefull, other needed change ...
GrumpySloth 4y ago
Something being common sense is not a good argument for it making sense. The most obvious demonstration of that is physics. Our common sense is hopeless at modelling the world around us accurately. Maths is better at that. In programming, similarly, algebraic properties and representation in memory should be preferred over a reasoning that something is just “common sense”.
gorgoiler 4y ago
I’m not sure what I supposed to be reading here but the title at least rang a bell of recognition for me. Programming to an interface, composition, immutable classes and objects as fancy closures that can do more than one thing: Drake-yes-please.jpg Inheritance for code sharing: Drake-no-thanks.jpg. One thing I really miss from my Java days, and which I don’t really think has anything to do with OOP, is the concept of package visibility. Private data for the class itself. Protected data for inheritors if you dare have them. Public for anyone using your library. And package level visibility for me and my team to have special privileged access to these things in the same module, but which one outside of it is allowed to touch. It’s a great feature for large groups of programmers.
- arinlen 4y ago
  > One thing I really miss from my Java days, and which I don’t really think has anything to do with OOP, is the concept of package visibility. C++ has that in the form of internal linkage. You can have all the symbols you want that are only visible within your own translation unit.
  - kaba0 4y ago
    Since C++ is probably the root of modern OOP, sure it does.
phpthrowaway99 4y ago
I like to think I'm a decently intelligent person. UC Berkeley Mechanical Engineering. I self taught a few years ago and wrote an entire project management SaaS for a certain industry in PHP and jQuery front end. 34 small companies use it. Even though I once took a highschool C++ course long ago that talked about OOP and made us do a few things with it..... I still have no idea what OOP really is, and why I need it. Unless I'm using it without knowing, I have a feeling I'm either dumber than I think or people have lost their minds. I can't tell.
- civilized 4y ago
  Self-taught programmers have an easier time thinking in a simple, direct, solution-oriented way. CS-educated programmers tend to think too much about whether this project gives them an excuse to use fancy things they learned in courses (how can I cram algebraic types into my recipe management program?). The downside of being self-taught is well-known - you might end up convincing yourself that for loops don't work, strings with more than 10 characters are unreliable, numbers can only reliably be added using BigDecimal, etc.
  - dpkirchner 4y ago
    Self-taught programmer checking in: OOP is about isolating private implementation details, akin to using local variables inside a function. Seems pretty direct to me.
    - phpthrowaway99 4y ago
      Totally, "isolating private implementation details" sounds super clear and useful. /s The general answer seems to be that OOP starts really helping when many people/teams are involved. Being self taught and a one person team I suppose hasn't forced me into it yet.
      - Kim_Bruning 4y ago
        At some point in time "the other people" are going to end up being different versions of Future You :-P . So if you take the "other people" argument, then it's definitely worth learning just for that reason. OO is pretty handy for the You Of Today too though. The basic low down is that this is all about encapsulation (tidying things away in boxes). You hopefully already know a bit about that. Say you just have all globals through all your files, you probably know you end up with a big mess of spaghetti. To help with that, you've probably already learned about tidying away code and variables into functions. And you might know that if you have a local variable, it is only visible inside the scope of your function. If you're doing it right, then nothing outside your function will ever directly touch the local variables inside the function, or vice versa. This makes it really really easy to reason about what happens inside the function, since -with the exception of your parameters and your return- what happens in vegas... uhh... your function, stays in your function. And the inputs and outputs to the function are well defined. This saves hours and hours of hunting out every last spot that some global was used, just in case it is interfering with something 1000 lines away. If you've done a lot of programming, you've probably been there a hundred times, cursing the laziness of Past You as you went. Maybe you also separate your program out into different files. Model.php, View.php, Controller.php DoImportantThing.php ... maybe something like that? So you probably already realize that tidying things away in boxes is a good idea. Everything you can tidy or organize away inside some box is something you don't need to worry about elsewhere at least. Out of sight is out of mind. Wouldn't it be great if there were more ways to help you tidy things away into boxes? Well, we're in luck. PHP has classes and objects. These are a further way to organize functions and data together into a next-size box. The idea is to tightly control what gets in and what gets out of these boxes again. And if you do, that's an additional level of things you don't need to worry about constantly. This frees up that part of your mind for other things. Of course if you're a PHP programmer you don't NEED to use classes and objects. You don't NEED to use anything. But they're a very powerful tool to help you keep your code squared away. And since they're built right in to the language already, right at hand, why wouldn't you use them? Classes and objects make most non-trivial projects easier and quicker to write (especially if you can reuse old classes, which you often can!) , and they make medium to large projects rather more manageable and tractable. If you poke me, I could find some time to show you how you can make classes and objects work for you? [disclaimer: Classes and Objects are definitely not the first/last/only/best/worst tools to organize code. Different languages have different tools sometimes. PHP just happens to provide Classes and Objects, so that's what you've got to work with there.]
recursivedoubts 4y ago
"Object-oriented programming is an exceptionally bad idea which could only have originated in California.” --Edsger Dijkstra NB: I am from California and I like object oriented programming.
- maxbond 4y ago
  Dijkstra was the original HN flame warrior.
nine_zeros 4y ago
Having worked with physical models that store state in memory during simulations, I assure you that OOP has its place and works very well. Without OOP, we quickly get into codebases much like JavaScript where every new framework attempts to reinvent the same thing in even more contrived ways. The only place where OOP style doesn't make sense is in stateless programs, which a lot of web backends are (but even there, it's often useful to hold connections and to create good interfaces). Don't let your code in any language go down the JavaScript framework path.
nsajko 4y ago
OOP is just a buzzword. There's no clear meaning behind "OOP" as far as I see, it's not even close to being well-defined, it just serves to confuse and fuel pointless discussions and arguing about semantics (see this thread, for example).
- timbit42 4y ago
  "OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things." – Alan Kay Simula was the first language to have objects but Alan Kay's Smalltalk was what really caused it to take off and is what most OOP languages today were derived from. Today he feels he mis-named it and that he should have called it Message-Based Programming, which is what he feels should be the primary focus of languages with objects. Most OOP languages today are not message-based and do not offer the full benefits of message-based programming. A few that do are Self, Ruby, and Erlang. The reason OOP seems like a buzzword with no clear meaning is because there are so many languages that implement OOP only partially and not always the same parts.
gballan 4y ago
I model systems that naturally have block diagrams (modulators, phase locked loops, power amplifiers, channels...). I came to an object oriented approach relatively late, but I would not go back. I don't know about general software, but for simulating physical systems it seems ideal.
rileyphone 4y ago
It's important to note that there are two schools of OOP that often get conflated and muddy the waters of understanding. On the one hand is the one evidenced in the OP and C++, where OOP is mostly an organizing principle and function calls are bound early. On the other side is the Smalltalk school, emphasizing message passing and late bound everything, which is slower but a lot more dynamic and flexible, as best laid out by Kay in his famed email [0]. At this point, object-oriented programming is about as precise a term as socialism (and equally likely to start a flamewar). 0. http://lists.squeakfoundation.org/pipermail/squeak-dev/1998-October/017019.html http://lists.squeakfoundation.org/pipermail/squeak-dev/1998-...
deleted 4y ago
[deleted]
pjmlp 4y ago
Taken to a basic extreme, OOP is basically extensible modules. Just pick a modular language like Modula-2, and add the capability to store module instances into variables, and extend them from there. Polymorphism and dynamic dispatch at their root are plain function pointers, and anything else is just syntax sugar to avoid manually dealing with them. Languages like Oberon or Lisp show how minimal the language has to have native support for OOP features, while still supporting most of its concepts.
throwaway903901 4y ago
In practice I found FP more useful for web service backends, and OOP more suited for GUI tookits and game dev. The Actor model seems to fit well with OOP also.
mbrodersen 4y ago
The only “true” OO language that I am aware of is Erlang (using the definition given by Alan Kay).

39 points by jjuliano 4y ago

For those wondering, the quote in the submission is in the first paragraph of the Preface, page vii.

OOP gives excellent benefits as concerns scope control, and since many of us are suffocating to death under overwhelming scope, there's a win. As for the handwaving about simulation & modelling and We Must Design The Matrix and all that nonsense... not applicable to most programming.

bluefirebrand 4y ago
You're probably not suffocating under scope, you're suffocating under State. OOP helps encapsulate state to make it more manageable. I am starting to reject OOP because I find working at reducing state is much more fruitful than encapsulating it.
- kaba0 4y ago
  Reducing state and OOP is not against each other, I believe FP+OOP is a good match. Many problems are data-oriented where FP is hands down better, but I think OOP helps exactly at the side-effecting edges.

swatcoder 4y ago

It’s true. But eventually a junior developer realizes that a Triangle is an PolygonalOpenFrameMetallicPercussionInstrument and it now has 4kb of private state, 307 inherited member functions, and floods your console when its logged. I love OOP, but caution is indeed warranted.

pier25 4y ago
You can totally have OOP without inheritance. In fact "composition over inheritance" is a thing in the OOP world. https://en.wikipedia.org/wiki/Composition_over_inheritance https://en.wikipedia.org/wiki/Composition_over_inheritance
- WesolyKubeczek 4y ago
  But why not have both?
  - adgjlsfhk1 4y ago
    inheritance makes your code slower even if you don't use it.
    - WarChortle18 4y ago
      That's a very broad statement care to back it up?
      - Kim_Bruning 4y ago
        Presumably thinking of virtual methods, in the context of C++ ? At least that used to make your code very slightly slower. Might be measurable in a tight loop?
        adgjlsfhk1 4y ago
        This is one of several places. Some others are. You don't know how much memory an object of a given type takes to instantiate. This makes object allocation slower. This also means that you can't allocate a Vector<T> inline. It has to be a vector of pointers. You don't know what fields a type has. This makes GC scanning more expensive. You can't optimize the layout of a type. If you know an object doesn't have subtypes, you can move it's fields around to reduce padding. If you want to be able to look up fields quickly, you need to put all the fields of the supertype first in memory which will increase the size of your objects.

ReptileMan 4y ago

And yet common sense is(was) severely lacking in most OO languages implementations.

slively 4y ago
If it’s not common, maybe it’s not common sense?
- astrange 4y ago
  If you have to justify proposals with explicit reasoning (or conversely, if you're allowed to), then it's hard to reject them because they go against common sense, since it's hard to just say "my intuition told me this would be bad".
  - slively 4y ago
    Agreed, of course so many reasoned conversations it seems like at some point have a moment of intuition because not everything can be known at the time. I think this is the stuff that makes engineering fun. That combination of well reasoned responses sprinkled with gut feeling and heuristics.

AprilArcus 4y ago

OOP's greatest crime is needlessly adding an I-thou dichotomy to the realm of programming languages. The "switching" or context sensitive properties of deictic pronoun referents is one of the last and most difficult linguistic skills that first language learners acquire. Class instances add deixis to programming languages, which never needed it and don't benefit.

MauranKilom 4y ago
Could you translate this into English, please?
- nighthawk454 4y ago
  attempt: a class and an instance of a class aren't the same thing, which creates cognitive load to distinguish
- samatman 4y ago
  I think they're complaining about `this`, which I also find annoying, but don't feel the need to dress that up in fancy terms. My issue with `this` and things like it is that the first argument (the 'object') is usually the most important thing, and it's easier to read methods if they have a name. Ok, you can call this deixis but do you need to? Clearly not.
  - maxbond 4y ago
    Your fancy terms are someone else's terms. It was critical to their point about how deixis specifically being difficult for new language learners. Addutionally I enjoyed skimming the Wikipedia articles and considering programming languages as languages; I got more out of it than I do most HN comments. I think it's fair to skip over a comment using terminology you find tiresome, be it because you aren't familiar, or you find it irritating for some reason, or for any reason; it's your time. I think it's unnecessary to insist we all use the same terminology, as that just limits what conversations can be had and who can have them. One of the things that makes HN feel magical is when people from a weird discipline jump in to give their two cents, and they add value to the community when they bring their terminology with them.

bumblebritches5 4y ago

echelon 4y ago

The biggest problem with OOP is the concept of class hierarchies. They're an unnatural representation of units of work and state that force obtuse topological reasoning where there should be none. Traits and type classes are a much better solution that offer far more flexibility, yet still allow the programmer their own balance of expressiveness and rigidity. Of course data can have defined behavior. Don't try to marshall it into genetic lineages of parents and ancestors. That's an orthogonal and entirely made up problem.

zozbot234 4y ago
Traits and type classes are broadly the same as interface inheritance. So there still is a hierarchy, it's just restricted to the interface layer as opposed to impacting the implementation.

mikewarot 4y ago

In Turbo Pascal/Delhi/Free Pascal/Lazarus, the OOP seems quite sane. The whole abstract factory generator class iterator thing I see in other languages scares the bejeezus out of me.

bandyaboot 4y ago
How do you iterate over your abstract factory generator classes in those languages?

mixedCase 4y ago

Objects are a good tool. Isolating some kinds of state in more manageable units can be very handy while remaining maintainable. Even inheritance can be nice under the right circumstance. Object oriented programming? An unmitigated disaster.

hudon 4y ago

In terms of readability and maintainability, one problem with OOP is the development process that tends to go with it, where you're asked to create upfront the separation of concerns, before code has had a chance to run and breathe for a while. Most of the time, you end up being wrong on how things should be segregated, and your behavior ends up fragmented across a variety of objects, making it difficult to easily see the flow of your program. Actions related to a Widget end up not actually being neatly encapsulated in a Widget, and encapsulation is one of the major selling points of OOP. It's probably best to start off a solution with plain old data structures, and plain old functions (ie. procedural style). Build with that until right abstractions or separations emerge.

colordrops 4y ago
Also, within the context of an individual class, variables can be modified and accessed anywhere in the class, creating all the same problems as global variables.
- bostonsre 4y ago
  If the single responsibility principle is followed and cohesion is strong, it should help mitigate these concerns. Creating large uber classes can quickly become troublesome.
arinlen 4y ago
> Most of the time, you end up being wrong on how things should be segregated, and your behavior ends up fragmented across a variety of objects, making it difficult to easily see the flow of your program. This can only become a problem if you pay little to no attention to modularization, software architecture, and even encapsulation. The responsibility of a paradigm and a language is to allow a developer to freely express their concepts. The programming paradigm is not to blame if the developer chooses to express poorly thought-out ideas that are riddled with detrimental consequences.
- julienfr112 4y ago
  the problem is not about software development, it's about business logic that change, when a new client arrive and want new features, some feature where not usefull, other needed change ...

GrumpySloth 4y ago

Something being common sense is not a good argument for it making sense. The most obvious demonstration of that is physics. Our common sense is hopeless at modelling the world around us accurately. Maths is better at that. In programming, similarly, algebraic properties and representation in memory should be preferred over a reasoning that something is just “common sense”.

gorgoiler 4y ago

I’m not sure what I supposed to be reading here but the title at least rang a bell of recognition for me. Programming to an interface, composition, immutable classes and objects as fancy closures that can do more than one thing: Drake-yes-please.jpg Inheritance for code sharing: Drake-no-thanks.jpg. One thing I really miss from my Java days, and which I don’t really think has anything to do with OOP, is the concept of package visibility. Private data for the class itself. Protected data for inheritors if you dare have them. Public for anyone using your library. And package level visibility for me and my team to have special privileged access to these things in the same module, but which one outside of it is allowed to touch. It’s a great feature for large groups of programmers.

arinlen 4y ago
> One thing I really miss from my Java days, and which I don’t really think has anything to do with OOP, is the concept of package visibility. C++ has that in the form of internal linkage. You can have all the symbols you want that are only visible within your own translation unit.
- kaba0 4y ago
  Since C++ is probably the root of modern OOP, sure it does.

phpthrowaway99 4y ago

I like to think I'm a decently intelligent person. UC Berkeley Mechanical Engineering. I self taught a few years ago and wrote an entire project management SaaS for a certain industry in PHP and jQuery front end. 34 small companies use it. Even though I once took a highschool C++ course long ago that talked about OOP and made us do a few things with it..... I still have no idea what OOP really is, and why I need it. Unless I'm using it without knowing, I have a feeling I'm either dumber than I think or people have lost their minds. I can't tell.

civilized 4y ago
Self-taught programmers have an easier time thinking in a simple, direct, solution-oriented way. CS-educated programmers tend to think too much about whether this project gives them an excuse to use fancy things they learned in courses (how can I cram algebraic types into my recipe management program?). The downside of being self-taught is well-known - you might end up convincing yourself that for loops don't work, strings with more than 10 characters are unreliable, numbers can only reliably be added using BigDecimal, etc.
- dpkirchner 4y ago
  Self-taught programmer checking in: OOP is about isolating private implementation details, akin to using local variables inside a function. Seems pretty direct to me.
  - phpthrowaway99 4y ago
    Totally, "isolating private implementation details" sounds super clear and useful. /s The general answer seems to be that OOP starts really helping when many people/teams are involved. Being self taught and a one person team I suppose hasn't forced me into it yet.
    - Kim_Bruning 4y ago
      At some point in time "the other people" are going to end up being different versions of Future You :-P . So if you take the "other people" argument, then it's definitely worth learning just for that reason. OO is pretty handy for the You Of Today too though. The basic low down is that this is all about encapsulation (tidying things away in boxes). You hopefully already know a bit about that. Say you just have all globals through all your files, you probably know you end up with a big mess of spaghetti. To help with that, you've probably already learned about tidying away code and variables into functions. And you might know that if you have a local variable, it is only visible inside the scope of your function. If you're doing it right, then nothing outside your function will ever directly touch the local variables inside the function, or vice versa. This makes it really really easy to reason about what happens inside the function, since -with the exception of your parameters and your return- what happens in vegas... uhh... your function, stays in your function. And the inputs and outputs to the function are well defined. This saves hours and hours of hunting out every last spot that some global was used, just in case it is interfering with something 1000 lines away. If you've done a lot of programming, you've probably been there a hundred times, cursing the laziness of Past You as you went. Maybe you also separate your program out into different files. Model.php, View.php, Controller.php DoImportantThing.php ... maybe something like that? So you probably already realize that tidying things away in boxes is a good idea. Everything you can tidy or organize away inside some box is something you don't need to worry about elsewhere at least. Out of sight is out of mind. Wouldn't it be great if there were more ways to help you tidy things away into boxes? Well, we're in luck. PHP has classes and objects. These are a further way to organize functions and data together into a next-size box. The idea is to tightly control what gets in and what gets out of these boxes again. And if you do, that's an additional level of things you don't need to worry about constantly. This frees up that part of your mind for other things. Of course if you're a PHP programmer you don't NEED to use classes and objects. You don't NEED to use anything. But they're a very powerful tool to help you keep your code squared away. And since they're built right in to the language already, right at hand, why wouldn't you use them? Classes and objects make most non-trivial projects easier and quicker to write (especially if you can reuse old classes, which you often can!) , and they make medium to large projects rather more manageable and tractable. If you poke me, I could find some time to show you how you can make classes and objects work for you? [disclaimer: Classes and Objects are definitely not the first/last/only/best/worst tools to organize code. Different languages have different tools sometimes. PHP just happens to provide Classes and Objects, so that's what you've got to work with there.]

recursivedoubts 4y ago

"Object-oriented programming is an exceptionally bad idea which could only have originated in California.” --Edsger Dijkstra NB: I am from California and I like object oriented programming.

maxbond 4y ago
Dijkstra was the original HN flame warrior.

nine_zeros 4y ago

Having worked with physical models that store state in memory during simulations, I assure you that OOP has its place and works very well. Without OOP, we quickly get into codebases much like JavaScript where every new framework attempts to reinvent the same thing in even more contrived ways. The only place where OOP style doesn't make sense is in stateless programs, which a lot of web backends are (but even there, it's often useful to hold connections and to create good interfaces). Don't let your code in any language go down the JavaScript framework path.

nsajko 4y ago

OOP is just a buzzword. There's no clear meaning behind "OOP" as far as I see, it's not even close to being well-defined, it just serves to confuse and fuel pointless discussions and arguing about semantics (see this thread, for example).

timbit42 4y ago
"OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things." – Alan Kay Simula was the first language to have objects but Alan Kay's Smalltalk was what really caused it to take off and is what most OOP languages today were derived from. Today he feels he mis-named it and that he should have called it Message-Based Programming, which is what he feels should be the primary focus of languages with objects. Most OOP languages today are not message-based and do not offer the full benefits of message-based programming. A few that do are Self, Ruby, and Erlang. The reason OOP seems like a buzzword with no clear meaning is because there are so many languages that implement OOP only partially and not always the same parts.

gballan 4y ago

I model systems that naturally have block diagrams (modulators, phase locked loops, power amplifiers, channels...). I came to an object oriented approach relatively late, but I would not go back. I don't know about general software, but for simulating physical systems it seems ideal.

rileyphone 4y ago

It's important to note that there are two schools of OOP that often get conflated and muddy the waters of understanding. On the one hand is the one evidenced in the OP and C++, where OOP is mostly an organizing principle and function calls are bound early. On the other side is the Smalltalk school, emphasizing message passing and late bound everything, which is slower but a lot more dynamic and flexible, as best laid out by Kay in his famed email [0]. At this point, object-oriented programming is about as precise a term as socialism (and equally likely to start a flamewar). 0. http://lists.squeakfoundation.org/pipermail/squeak-dev/1998-October/017019.html http://lists.squeakfoundation.org/pipermail/squeak-dev/1998-...

deleted 4y ago

[deleted]

pjmlp 4y ago

Taken to a basic extreme, OOP is basically extensible modules. Just pick a modular language like Modula-2, and add the capability to store module instances into variables, and extend them from there. Polymorphism and dynamic dispatch at their root are plain function pointers, and anything else is just syntax sugar to avoid manually dealing with them. Languages like Oberon or Lisp show how minimal the language has to have native support for OOP features, while still supporting most of its concepts.

throwaway903901 4y ago

In practice I found FP more useful for web service backends, and OOP more suited for GUI tookits and game dev. The Actor model seems to fit well with OOP also.

mbrodersen 4y ago

The only “true” OO language that I am aware of is Erlang (using the definition given by Alan Kay).