Dit is een discussie op reddit aan de hand van het artikel Why Javascript still sucks.

De blauwe namen zijn de verschillende gebruikers.

ilikecomputahs Why is object oriented programming considered so absolutely necessary? /braces for shitstorm

egonelbre Simple answer, it isn't. Depending on your definition of OOP, there are useful parts to it. Going back to the roots; messaging is a requirement for fault tolerance, also the interface for messaging provides an abstraction for the components, hence less coupling of things. One additional use from this abstraction layer is the ability to delegate other objects. The "object concept" itself allows easier (not necessarily simpler) mapping from human concept to the code. For example this box is blue, this box is red; they both are boxes and you should be able to the same things with both of them. Hence we get a notion for a abstract idea Box (a class) that defines the things you can do with a box. Easier doesn't mean better, since some things can be much better described with components or traits.

gargantuan Going back to the roots; messaging is a requirement for fault tolerance, also the interface for messaging provides an abstraction for the components, hence less coupling of things. The only practical language that fits the bill for this is surprisingly Erlang (maybe Rust, Go, and Dart with their channels, isolates and whatever else they have in Rust). Interestingly in Erlang there is not inheritance and not sure about abstraction, they have behaviors that separate common vs specific code, but now sure where that fits in the traditionally (sub-classing and encapsulation patterns).

egonelbre Well, abstraction is achieved via messaging; essentially the messages become the abstraction layer. If you send it to a process you really don't know how or who or even when it will be eventually handled. As for method call, it's just a limited version of messaging; so you still get the decoupling even if it's not "async messaging". Async messaging can be cumbersome to work with, but I think Go struck a nice balance with channels.

gargantuan Not familiar much with it but it seems since Erlang was made for large distributed system async is the default because sync in that case could mean blocking the whole distributed cluster. Then sync messaging (calls) can be built on top of async if needed if the sender can obtain his own address (as the callee would see it) and send it along with the message. Then he waits for the response to that message (with a practical timeout). Other way (simulating async using sync) is possible I guess but only if every sync message is send from a newly spawned process/thread/isolate.

egonelbre I don't think fully simulating async messaging is possible with sync messaging. As I understand, something is needed for unbounded nondeterminism. NB: Following maybe wrong, since I haven't studied this properly. Basically synchronous messaging can be simulated with Turing machines, this means it cannot provide unbounded nondeterminism. So you would need something to introduce it, like arbiter, network. Since those already are in modern computers it can be practically simulated - but not with pure sync messaging.

gargantuan What about my suggestion, would that not work? You create a new concurrency context (thread, process, task), send the sync message from there then that exit). The parent context can continue making progress.

egonelbre You still need to start the concurrency context somehow. The async messaging behavior, then would come from starting the context and it arriving at the method call; you don't know exactly when the method is called since, you don't know exactly when the context is run.

----------------------------------------------------------------------------------------ilikecomputahs Why is object oriented programming considered so absolutely necessary? /braces for shitstorm

x86_64Ubuntu The issue generally arises for when programs get bigger and larger in scope. The web appears to be driving the future of development, as we have seen the rise of mobile sites and JS being a first class citizen across desktops, tablets and phones. However, JS was never intended for making applications, it was just used to make marquees spin, and ponies sprinkle glitter across Geocities homepages. Now why does this matter ? It matters because as things get bigger no matter what they are, you eventually are going to need rules and constructs. OOP can provide that, even though people still fuck it up. Generally, applications work with objects because objects imply properties and methods. If I know the class type of the object, I know how it fits in the larger scheme of my application.... ...Um, I kind of have lost the ability to convey my thoughts. I upvoted you anyway because this is an important point in application development by allowing us to take complexity a bit further without incurring such misdirection and indirection costs.

smog_alado The issue generally arises for when programs get bigger and larger in scope.

I don't agree with that. This is a matter of encapsulation and modularity and those are not exclusive to OOP. In fact, I believe that OO by itself is pretty bad at solving these two problems, since classes are usually too small to be modules and too heavyweight for the simpler cases of encapsulation.

DrDichotomous It's more about forcing large teams of people to NOT do certain things, so they rigidly follow an API. You can still do those things without Java-style OOP, but too many people will be tempted to screw around and end up doing it wrong. People are just too used to their toolchains, and so they're pushing for those toolchains to exist in competing languages.