The top definition for "predicate", that most people are familiar with, and that was omitted from the dictionary quote, is:
> 1. (grammar) The part of the sentence (or clause) which states something about the subject or the object of the sentence.
And in that context, it was a perfectly valid use of predicate, effectively synonymous with "unary function".
Sure, someone could & should have pointed out that the term was confusing because it has a more specific meaning in a computer science context, but all of the responses were simply "you're wrong" and creating in-group/out-group boundaries[1] rather than trying to understand the communication mismatch.
[1] It's usually a bad sign when someone comes in and says "serious programmers should know [...]". :P
In classical/antiquated grammar, most sentences can be divided into a subject and a predicate. The predicate indicates what the subject does/is. While there are issues with agreement and semantics, on a broad syntactic level, the subject is arbitrary and can be replaced with another valid subject:
The angry dog // jumped over the fence.
My grandmother // jumped over the fence.
Twelve apples // jumped over the fence.
Then, in the OP's js context of Object.map we have a situation like this:
import map from 'just-map-object';
function jumpedOverTheFence(subj) { \\ impl };
var things = ['The angry dog', 'My grandmother', 'Twelve apples'];
map(things, jumpedOverTheFence);
IMO the analogy actually extends fairly well too. Agreement is a good match for typing (A singular typed predicate "walks" can't take a plural typed subject "Some dogs" => "Some dogs walks" fails at the syntax level), and semantics match internal expectations of functions (The "12 apples jumped..." breaks internal, but untyped expectation that the subject would have agency or control over its actions, like a "chooseTo" method or a "consciousness" property.)
My concern was not the particular question, but the tremendous mischaracterisation of the entire linked discussion.
Did you link to the correct comment? Because I see absolutely none of what you described.
I'd argue that usage is more "technically" correct than David Chang, who's referring to the _entities_ as the isomorphisms rather than the relationships between them. (Though I understand his usage and find no problem with it in the given context.)
"The term isomorphism literally means sameness (iso) of form (morphism)." https://en.wikipedia.org/wiki/Isomorphism_(Gestalt_psycholog...
Perhaps the knowledgable people here (that unfortunately so far have preferred to be flippant and condescending instead of educating) could provide an explanation of showing us why "Isomorphic JavaScript" is a misnomer?
I think the problem stems from considering the running on server and client as the entities, rather than the representation produced on the server and reinstantiated on the client as something that can be manipulated.
There is no self-reference in the paradox of something having 2 properties at once (e.g. undersalted and oversalted).
It is a paradox, but it's not a Liar's paradox or a strange loop. In other words, not all paradoxes are the Liar's paradox.
In order to grok strange loops, one must learn to accept rather than reject paradox. "Logic" doesn't like paradox, and tries to get rid of them when they are encountered. But once you've read GEB, you're sensitized to accept paradox.
I agree that all strange loops are paradoxical, but not all paradoxes are strange loops. Where I don't agree is that just because an idea isn't a strange loop doesn't mean it wasn't inspired by an awareness of strange loops. Without Hofstadter's idea, Chang would never have had this breakthrough on his own.
It's the same code on the server side and client side.
So the client and server are isomorphic, because an object is trivially isomorphic to itself.
It's a fine idea to run the same code on the client and server. No problem there. The word choice may be confusing because you expect there to be some deeper concept you are missing.
Hence the "strange loop".
I don't really think he used the concept of "strange loop" correctly, because there is no self-reference involved in his examples. It's more of a "paradox" (something that's undersalted and oversalted at the same time)