The article is considerably better than the comments here imply. In my view, the OP is showing intelligent intuition about software.
I've encountered the exact same issues that they have. It's frustrating when code wrapped up in a function prevents you from testing or experimenting in a REPL. It's infuriating when a framework wraps your code in one of these mega-lambdas so you can't get at it. There are many programming techniques that require the ability to breach encapsulation when appropriate.
Meanwhile, the virtues of enforced privacy are overrated. There are countless ways to screw up software; trying to lock things down so the next guy can't screw them up (preventing access, etc.) is a classic mistake. Modularity is extremely important in systems design, but not as an enforcement mechanism. It's an organizational tool. It's about decomposition and factoring, not hiding things so that only you can control them.
It's worth noting that Smalltalk doesn't have private methods [1], and that this was regarded as a feature not a bug. That alone shows that there's no particular link between enforced-privacy and OO, or even enforced-privacy and encapsulation.
To some extent this is a matter of taste, but I come down on the side that sees little value (and considerable drawbacks) in the privacy fetish. It's one of those things that people believe in because it sounds like things ought to work that way, when in reality they do not.
Enforced privacy is not as common as people think either, so you don't really even need to pull out the Smalltalk argument. In Java, C#, PHP etc it is not possible for the developer to actually enforce privacy like you can in JS because the privates are readily accessible through reflection if needed.
Another point is that the Javascript enforced privacy pattern only supports private, so 2 internal classes cannot get at each other even if they are maintained together as a package. That encourages creating god objects which is not surprisingly what I commonly see in projects that use enforced privacy in Javascript.
Comments
The article is considerably better than the comments here imply. In my view, the OP is showing intelligent intuition about software.
I've encountered the exact same issues that they have. It's frustrating when code wrapped up in a function prevents you from testing or experimenting in a REPL. It's infuriating when a framework wraps your code in one of these mega-lambdas so you can't get at it. There are many programming techniques that require the ability to breach encapsulation when appropriate.
Meanwhile, the virtues of enforced privacy are overrated. There are countless ways to screw up software; trying to lock things down so the next guy can't screw them up (preventing access, etc.) is a classic mistake. Modularity is extremely important in systems design, but not as an enforcement mechanism. It's an organizational tool. It's about decomposition and factoring, not hiding things so that only you can control them.
It's worth noting that Smalltalk doesn't have private methods [1], and that this was regarded as a feature not a bug. That alone shows that there's no particular link between enforced-privacy and OO, or even enforced-privacy and encapsulation.
To some extent this is a matter of taste, but I come down on the side that sees little value (and considerable drawbacks) in the privacy fetish. It's one of those things that people believe in because it sounds like things ought to work that way, when in reality they do not.
[1] http://stackoverflow.com/questions/7399340/smalltalk-public-...
Enforced privacy is not as common as people think either, so you don't really even need to pull out the Smalltalk argument. In Java, C#, PHP etc it is not possible for the developer to actually enforce privacy like you can in JS because the privates are readily accessible through reflection if needed.
Another point is that the Javascript enforced privacy pattern only supports private, so 2 internal classes cannot get at each other even if they are maintained together as a package. That encourages creating god objects which is not surprisingly what I commonly see in projects that use enforced privacy in Javascript.