> You know what? Fuck it. When I tried to understand the Servicy/Factory/Provider distinction, I stumbled upon the same SO post and you know what ended up being the perfect way of understanding it? Forcing myself to go back to that paragraph right there until I understood it.
Yeah, that paragraph is difficult if you don't actually read through it and understand what it's saying. However, if you read through it with the intent of understanding it, it makes sense. And I think that really highlights the problem: the author wasn't reading to understand. At the point he got to that paragraph, he was already frustrated or upset, or whatever, and wasn't attempting to understand anything.
Key point: don't read documentation while frustrated. Take two minutes, relax, kick back, and read it with the understanding that it can teach you something.
I'm in the position of having written frameworks. I read that paragraph and though "Exactly! This is necessary for dynamic object binding using containers" etc. Nothing unusual at all. It depends upon context. As a professional I find it odd the OP brags about remaining ignorant of a common topic in his field.
Simplicity is actually really difficult to achieve. The only anti-intellectualism is Angular offloading that burden on it's developers. There are many other binding frameworks that have put more effort into both their use and their documentation. Hell, in the time you've read this you could already be a ractive.js expert.
It's easy to not use a C-based language and forget that there are many fundamental patterns that are still applicable, even if they look different. The purpose and intent behind a pattern is generally more important than the actual name used or the code structure. The factory pattern defines what it does (essentially code that creates objects without the caller needing to know the details), not the syntax behind it.
I see this happen all the time, even in functional languages.
Yeah, that paragraph is difficult if you don't actually read through it and understand what it's saying. However, if you read through it with the intent of understanding it, it makes sense. And I think that really highlights the problem: the author wasn't reading to understand. At the point he got to that paragraph, he was already frustrated or upset, or whatever, and wasn't attempting to understand anything.
Key point: don't read documentation while frustrated. Take two minutes, relax, kick back, and read it with the understanding that it can teach you something.