I didn't stigmatize poor people. If you consider stating facts of reality to be stigmatization, you are fighting reality, and that is no way to deal with it.
> rather than focusing on bad luck they have had
One of the main point of the article is precisely that being poor is not bad luck: overall, it happens because a person didn't take education seriously because they were not taught to do so by their parents.
I mean, you can say it's bad luck to be born to such parents, and I would agree there.
The economics of drugs are different. The probability of two different labs inventing the exact same drug are pretty small. But when they do invent a drug they have a limited monopoly to make their money back. Which is a good thing, since it encourages more investment in drug development then there otherwise would be.
ReST shows that a person can invent a technical term, write a long dissertation on what it means, clarify any ongoing misconceptions on the web, and have people use the word to mean whatever they like.
Let's assume there is a platonic ideal for REST, or for OOP. Just talking about REST over HTTP (methods, response codes, URIs) clouds that ideal, making it hard to learn about and even harder to talk about with other programmers. The same could be said about OOP with classes, structs, prototypes, etc... or as some of this article's quotes do, about OOP in Smalltalk. Over time you could look at this in terms of SCOT theory and I think it would be fascinating. You could look at all of the marketing, conflict, and the effects of collective perspective shifts where things are considered "solved" but they aren't really.
My own opinion about the platonic ideal of OOP is close to Chapter 18 of Pierce's Types and Programming Languages, which suggests these attributes:
1. Multiple representation
5. Open recursion.
To me the kernel of OOP is mainly just #1 and #2. If you don't have #3, you should have a damn good alternative. I don't attach #4 and #5 to the core definition but certainly the former should imply the latter. Another favorite is "On Understanding Data Abstraction, Revisited", which contrasts objects and ADTs in a different framework.
Have you tried a manual stovetop frother? It's made of metal, and it has a plunger with a frothing head (looks like a coil-type whisk) on the end.
You fill it with milk, put it on a gas burner or electric hot plate, warm it until the milk is hot enough (around 60-65C). Then you take it off the heat and push the frother up and down until the milk is sufficiently aerated. Here's the one I have:
There don't appear to be any engineers involved in those predictions.
Their predictions require many other changes: "The baseload issue can be solved by reducing baseload demand,having some renewable energy sources that can supply baseload power and increasing the proportion of flexible peakload plant in the generating mix." Who should pay for this? Price pollution properly, and you will see the push away from natural gas and coal to nuclear, not "renewables" at far higher prices ($7-10 billion AUD/year for Australia, according to this article).
In summary, if you change the goalposts (reduce baseload) and pay lots more, "renewables" are totally doable according to somebody with no engineering experience.
Who is putting their hand up for their street lights to be switched off? For their hospital to run expensive co-generation when there isn't enough supply or it becomes to expensive? A lot of these statements are made by groups which just pretend that you can cut down a lot of energy and that's how they make their sums work. The BZE group do this with their calculations and it's pretty unrealistic.
The problem I have with all of these plans is that they drastically inflate the cost of energy for no real reason apart from dislike of certain generation types.