Sometimes we use different words instead, like “practical” vs “theoretical” or “real world” vs “ivory tower”. It all means the same thing: “good” vs “bad”. Which is a big lie, because we’re not making ethical judgments, we’re trying to assess the pros and cons of different solutions to particular problems in concrete contexts. This isn’t The Lord of the Rings.
It’s funny that the author says this and then later goes on a rant about the importance of words having meanings and respecting those. Someone saying “this is a pragmatic approach” is making a more nuanced claim than “this is a good approach”, and one that doesn’t have to lead to banality or polarization.
This is a function that computes the square of the integers 1-5, not by reflecting any understanding of what it means to square a number, but rather by emulating correct behavior. It has a small bug for the input number 4, but that doesn’t matter much, we rarely get that value, and the result isn’t too far off. It’s a perfectly pragmatic solution if you can assume that x will always be in the range 1-5.
It’s more code than the other example. It’s going to be harder to maintain - what if we needed to refactor the function to cube instead of squaring? Or maybe numbers larger than 5 do come up in our use case. See, talking about “pragmatism” has focused our discussion on concrete scenarios, rather than abstract principles like correctness. If we don’t already agree on those principles (and anyone claiming that the first solution is better probably doesn’t) then the discussion is well served by going down to concrete instances, and their saying “pragmatism” is a good way to make that happen.
For instance, some architectural properties have principles that cannot be violated while still maintaining the properties – they are simply no longer present due to the violation. (A vegetarian cannot eat meat in the weekends and still be a vegetarian, if you will.)
This is just begging the question. Those principles should not be sacred, they should be on the table for compromise - that’s what pragmatism is.
Now we have the strange situation that it’s apparently OK for some words in software to have no meaning (REST), whereas we insist that others do have meaning (secure). For the meaningless words, prefixing “pragmatic” will absolve you from your sins, for the meaningful words, it will not. This is a problem, I think. Who’s to decide which words should have meaning?
Welcome to the English language. It’s an accident of history that REST has become picked up as a term for something different from its original definition. This is unfortunate, but a fact of life when communicating in English. Insisting that “REST” must mean what the original paper claimed it meant is unproductive nitpicking, of the same nature as complaining about someone talking about “the vegetables” when one of them is a tomato.
I mean, usage determines meaning, languages are a tool for communicating in English. If your definition means that 90% of the things that people call “REST APIs” are not “REST APIs” (as the hypermedia definition does), maybe it’s a bad definition and you should change it.
I’ve experienced this in a few ways. Most recently this has been with Go defenders. Regardless of if the choices of Go are valid, many defenders I’ve talked with are not able to elucidate an argument beyond “pragmatism”.
On the other hand, I have had very positive experiences stopping over “pragmatism” by arguing in terms of how serious the effect is if a corner case is hit. In some management software my team was working on, a coworker did not want to handle a particular edge case. The strength of my argument was roughly that if the edge case does happen, the software becomes unusable, so the edge case needs to be handled, either but isolating it away or actually handling it.