The term has been weirdly adopted by the dev community in a way that kinda makes sense if you squint a little but has always created a dissonance in my brain due to my maths background.
But since we’re here! For those who don’t know the word from outside of the dev sphere, in maths it refers to having 2 way mappings between 2 structures. You can do it between totally seemingly unrelated parts of maths (you just need to show how to map between them). As a result, anything you’ve proved in one space holds true in the other. It can be useful if you have an intuition and understanding of one of the spaces but not the other.
I’m trying to think of a nice example but I haven’t thought about this type of maths for a couple of decades now. Answers on a postcard please!
> The term has been weirdly adopted by the dev community in a way that kinda makes sense if you squint a little but has always created a dissonance in my brain due to my maths background.
I don't really have a 'math background' (engineering graduate, but I don't think that counts, a mathematician certainly wouldn't) but I know (enough, roughly, layman's definition) what it means in mathematics, and work in software engineering.
I have absolutely no idea why this project is called 'isomorphic', it doesn't make any sense to me however much I squint, and doesn't seem to be explained anywhere.
I'd guess it's just an arbitrary name and isn't supposed to have meaning? Though it's a library for `git`, why not just call it `git`? shrugs
All the good names were already taken on npm / GitHub: git, git.js, js-git, es-git. "Isomorphic JavaScript" had just been coined and was trendy at the time (2017ish, see https://en.m.wikipedia.org/wiki/Isomorphic_JavaScript) and "isomorphic-git" is unique enough to be Google-able.
This makes me think that there should be two names in package management: a UID, and the import/use-it name.
Many such systems do work like that, but the UID is chosen by the author, so invariably it's a close match to the import/use-it name, and often it's actually the preferred name because the other had to be mangled to be syntactically correct in a program. Consequently, the main display name is the UID; not the import/use-it name.
The UID should be generated by the package manager, and only the import/use-it name chosen by the author. The latter would be the one prominantly displayed, and be allowed to conflict with other packages (that have different UIDs).
Even if you wanted to use two that shared an import/use-it name, there could just be a way of renaming them in the requirements/lockfile, e.g.:
[dependencies]
d34db33f = { version = "^0.1", name = "isomorphic_git" }
l333333t = { version = "^3.2", name = "native_git" }
where usually both of those use the import/use-it name `git`, and the names `isomorphic_git` & `native_git` are whatever I fancied for this project with this dependencies file - could've been `foo` & `bar`.
(Perhaps a more human-friendly format would be `git = "^0.1"`, and we only have to specify something like `= { uid = "d34db33f", ...` when the package manager detects that there is a naming collision. Of course the lockfile, if used, would already have the UID, in case a colliding package was suddenly created.)
The “isomorphic” comes in because the same library / API is available in both the browser and in node. So “anything you can prove in [node] is also proved in [the browser]” (in the context of this library).
Not that you're wrong, but it's a deep and pervasive concept in mathematics, and the field of computing is closely connected to mathematics in general. It's sort of a namespace collision.
Ok, but the same arguments could be made about the terms "refactor" and "plane" (as in control-plane/data-plane) but we seem to manage to cope with the overload.
This isn't an argument about consistency. It's an argument about whether overloaded terms are acceptable. If you want to argue that terms shouldn't be consistent that's an entirely different (and entirely bizarre, IMO) discussion.
Another term in computing/programming for "same code in different environments" is "portable". (e.g. C++ code that compiles/runs on both Linux/Windows). I've not seen 'isomorphic' used in computing outside of JS.
The community has been slowly moving to the term "Universal JS" for that concept, though. Probably partly due to the mathematical ambiguity, but mostly because "universal" is a bit more approachable term.
I remember my mind being blown when in Discrete Math 101 we learned that natural numbers are isomorphic with whole numbers. Was it, you map 0 to 0, even n to n/2, odd n to -(n+1/2) and all of us were like whoa and the TA is like "wait till I tell you about diffrent cardinalities" :D
This is just a bijection - for an isomorphism you need more structure. Roughly, having an isomorphism (which is a function) says:
0. I have two sets of things, and I can perform operations on each set
1. These two things are the same size (this is your example)
2. If I do operation A on elements (a, b) in set A, then perform the isomorphism on the result, this gives me the same thing as if I performed the isomorphism on a and b independently then performed operation B on their result
3. The isomorphism has an inverse with the same properties
[There are various types of isomorphism depending on what part of maths you’re thinking about. But they all have roughly this idea of “same size” and “preserves something cool that I can do in each of the spaces”]
Yes, I probably ought to have mentioned that. Though ime people are more likely to talk about isomorphisms in other categories, since the only “structure” a set has is its size
Bijective means that a mapping is exactly one to one.
Homomorphic means that "structure is kept". E.g. in a vector space you can add and multiply by a scalar, so a mapping f is homomorphic if for all x, y in the vector space and lambda a scalar
A little correction: an isomorphism is a homomorphism which is bijective and has a homomorphism as its inverse. For many structures the inverse being a homomorphism automatically happens as a logical consequence of the function being a bijective homomorphism, but this isn't the case for all structures. The most prominent examples are topological spaces: a bijection between topological spaces can be continuous (i.e. a homomorphism of topological spaces) but can have an inverse which is not continuous.
The classic example is a function which maps an interval to a circle by applying cos and sin to get the coordinates; this is continuous as small changes in the interval result in a small change in the position on the circumference, but its inverse is not continuous because there will be a point on the circle where the nearby points on one side come from the start of the interval but the nearby points on the other side come from the end of the interval.
But since we’re here! For those who don’t know the word from outside of the dev sphere, in maths it refers to having 2 way mappings between 2 structures. You can do it between totally seemingly unrelated parts of maths (you just need to show how to map between them). As a result, anything you’ve proved in one space holds true in the other. It can be useful if you have an intuition and understanding of one of the spaces but not the other.
I’m trying to think of a nice example but I haven’t thought about this type of maths for a couple of decades now. Answers on a postcard please!