91–98 of 98 posts
Earlier quoted context omitted.
I would gently submit to you that Erlang is pretty close to the definition of 'Object Oriented' as given by the guy who created that phrase. The commonly held definition of OO has drifted far from that ideal over the years.
It is. But at this point it is rather tongue-in-cheek. I certainly wouldn't want Erlang to all of the sudden be called Object Oriented.
The more I read about functional programming the more I question why are things this hard in traditional oops. If so many people have been doing oops for so many years then it must have something that is easy to pick up or something that is easier to work with. But after doing some functional programming the number of lines are painfully less and the code is easier to understand. I was thinking may be I was giving to…
Back in the dark ages, the performance difference between imperative code and functional code was too large for FP to gain much traction outside of academic circles.
By the time the hardware was anywhere near reasonable, OO had become a thing. People missed some of the key points Alan Kay had, latching on to the one thing that was immediately understandable: objects could model the nouns of your problem domain. That popularity meant that the mainstream was focused on OO, rather than FP.
I went through college in the late 2000s, at a well respected university, for computer science. I had classes devoted to OO(A/D/P); I had none devoted to FP. If you were exposed to it, it was via having to learn a Lisp in the AI class, or similar.
Earlier quoted context omitted.
> The getX() and setX() is an anti-pattern of good OOP. No it isn't, it provides encapsulation, which the most important aspect of OOP. I agree with the rest.
>No it isn't, it provides encapsulation, The extensive use of getters()/setters() is a common misunderstanding of "encapsulation". It's an example of following the "letter of the law but not the spirit of the law" . Let's separate the idea of "encapsulation" into 2 categories: (1) syntax encapsulation: private int x; public getX(); public SetX(); // letter of the law (2) conceptual/semantic encapsulation: Object.DoSo…
Earlier quoted context omitted.
You indirectly put your finger on the real problem with OOP, and that's that a lot of people using it in the wild are frankly not very good at it. Bad object design, not seeing what should be objects in the first place. I always felt that people who had never used C before C++ or Java, nor any other procedural language, aside from some scripting tended to some of the messiest OO. Seemed they'd want to create a sea of…
> OO is harder to teach, and clearly harder to understand That is a pretty damning judgement of OOP. It seems to me the whole point of a paradigm should be to improve understandability. If, in practice, it makes it worse, then it is a failed paradigm.
The more I read about functional programming the more I question why are things this hard in traditional oops. If so many people have been doing oops for so many years then it must have something that is easy to pick up or something that is easier to work with. But after doing some functional programming the number of lines are painfully less and the code is easier to understand. I was thinking may be I was giving to…
Broad generalizations here, but from my understanding - Back in the dark ages, the performance difference between imperative code and functional code was too large for FP to gain much traction outside of academic circles. By the time the hardware was anywhere near reasonable, OO had become a thing. People missed some of the key points Alan Kay had, latching on to the one thing that was immediately understandable: obj…
Earlier quoted context omitted.
> The getX() and setX() is an anti-pattern of good OOP. No it isn't, it provides encapsulation, which the most important aspect of OOP. I agree with the rest.
It can very easily break the encapsulation though. Now external processes are dependent on direct access to the internal state of your object, and if the object is refactored in the future you need to reprogram those getters and setters to return something that is still correct but may not represent the internal state of the object at all and may in fact be complex now. An example of where this can all go wrong is if…
In that case you should use polymorphism. There is no reason why the consumer of the address returning the IP should know whether get_ipaddr returns an IPV4 or an IPV6 directly.
Earlier quoted context omitted.
"OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. There are possibly other systems in which this is possible, but I'm not aware of them." http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay...
That is not the definition of OOP the author is using. He made it clear what he meant by OOP; a paradigm seen often in production systems. Productive discussions start by accepting given definitions and arguing against the resulting points, not by arguing that the definitions are wrong because they don't match the exact form defined by someone somewhere.
If the author is using a wrong definition as a starting point, the rest of the argument is largely pointless...or must be explicitly marked as a hypothetical/counterfactual.
"I define the earth as being an infinite flat plane, from this it follows [for the real world] that..."
Well, no, the earth is not an infinite plane, even if it kinda looks that way, was long believed to be that (maybe minus the infinite) and apparently there still are people who believe that.
Earlier quoted context omitted.
That is not the definition of OOP the author is using. He made it clear what he meant by OOP; a paradigm seen often in production systems. Productive discussions start by accepting given definitions and arguing against the resulting points, not by arguing that the definitions are wrong because they don't match the exact form defined by someone somewhere.
No, the premises always need to be examined, not accepted at face value. If the author is using a wrong definition as a starting point, the rest of the argument is largely pointless...or must be explicitly marked as a hypothetical/counterfactual. "I define the earth as being an infinite flat plane, from this it follows [for the real world] that..." Well, no, the earth is not an infinite plane, even if it kinda looks…
When you define OOP, you aren't saying anything about the real world, just stuff about the words you will be using within the current context.