I know the answer, thanks to watching a recent video by Richard Feldman on why functional programming isn’t popular yet. I recommend watching it for some intere

I know the answer, thanks to watching a recent video by Richard Feldman on why functional programming isn’t popular yet. I recommend watching it for some interesting talk about programming languages in general, it’s on YouTube at https://m.youtube.com/watch?v=QyJZzq0v7Z4 https://m.youtube.com/watch?v=QyJZzq0v7Z4 Anyway what privates give you is what everyone wants from a programming language: modularity. We want to be able to expose an api to some code and for it to have some inner workings that we don’t see because: 1. If we know they can’t be touched we have some implicit guarantees about our program. E.g. the mouse pointer cannot go off screen even if we try to make a call to do that. 2. It is simpler for a programmer to understand the api which might be 1% of the size of the module itself with all private’s. 3. I can change my private’s without breaking your calls. Essentially a minor version change in Semvar parlance instead of a major breaking change. 4. Make impossible state impossible! By guarding the state. All these things require modularity, and OO uses classes and private members to provide that modularity. Elm uses modules and the exposing keyword (or lack of!) as a contrast. JS modules are similar with a lack of an export allowing you to hide something. That something you did export can use for state or functionality. There is an old IIFE trick that works this way also. Making everything public is a bad idea, as you miss out on modularity advantages. Not sure how Ruby hides things as I haven’t used it for a while but I’m sure there is a way. And finally reflection in OO to access private’s is almost always a sin, unless you are make a debugging tool or similar. Canny? No way!