TenForward: Where Every Vulcan Knows Your Name
/c/TenFoward: Your home-away-from-home for all things Star Trek!
Re-route power to the shields, emit a tachyon pulse through the deflector, and post all the nonsense you want. Within reason of course.
~ 1. No bigotry. This is a Star Trek community. Remember that diversity and coexistence are Star Trek values. Any post/comments that are racist, anti-LGBT, or generally "othering" of a group will result in removal/ban.
~ 2. Keep it civil. Disagreements will happen both on lore and preferences. That's okay! Just don't let it make you forget that the person you are talking to is also a person.
~ 3. Use spoiler tags. This applies to any episodes that have dropped within 3 months prior of your posting. After that it's free game.
~ 4. Keep it Trek related. This one is kind of a gimme but keep as on topic as possible.
~ 5. Keep posts to a limit. We all love Star Trek stuff but 3-4 posts in an hour is plenty enough.
~ 6. Try to not repost. Mistakes happen, we get it! But try to not repost anything from within the past 1-2 months.
~ 7. No General AI Art. Posts of simple AI art do not 'inspire jamaharon'
~ 8. No Political Upheaval. Political commentary is allowed, but please keep discussions civil. Read here for our community's expectations.
Fun will now commence.
Sister Communities:
Want your community to be added to the sidebar? Just ask one of our mods!
Honorary Badbitch:
@jawa21@startrek.website for realizing that the line used to be "want to be added to the sidebar?" and capitalized on it. Congratulations and welcome to the sidebar. Stamets is both ashamed and proud.
Creator Resources:
Looking for a Star Trek screencap? (TrekCore)
Looking for the right Star Trek typeface/font for your meme? (Thank you @kellyaster for putting this together!)
view the rest of the comments
Wait wait wait... immutable means unchangeable! In your analogy this would mean if someone changes anything about them, like a name due to marriage or gender due to affirming care, they become a new object. And you can, but shouldn't assign that new object the same UUID.
Welcome to the wonderful, confusing world of objects, semantic models and unintuitive terminology.
The "immutable object" is an abstract kernel of your being, to which all other properties are related. It represents, in a way, the coincidence of all those other properties, but it's not quite so simple.
In semantic modelling, those properties are considered objects too, albeit often dependent ones: "Hair color" in the sense of a person's hair color is an object type; individual instances cannot exist without a person whose hair they're describing. "Blonde", in that sense, is a grouping of instances, but if there were no blonde people, the group would be empty.
Likewise, "Name" is an object type that depends on the thing it's naming. Sure, you can come up with arbitrary terms that don't refer to anything, but they're semantically meaningless. Conversely, a thing can exist without being named, like a newborn. You could identify it as "the newborn baby of ", but that isn't a name so much as list of properties (newborn, parents\¹), that coincide for one particular person.
The combination of a simple object (that a stract kernel) and its dependent objects (properties) forms a complex object. You, as a person, probably have a name by now. You also probably have a body, a past², some knowledge and skills like the ability to understand and form words and sentences, which in turn includes a vocabulary...
If you change your name, that is one property that changes; one dependent object that is swapped out for another. The rest of your properties is unaffected by that. Formally, the relation between you and your name is mutable, but your eye color for instance (probably) isn't dependent on your name.
Now, if you were to somehow swap out all dependent objects at once, changing every property - a different name, different past, different parents, different body - then you would arguably be a different person. Even if you could argue that the core object remains the same, but given that this core object is an abstraction to describe the complex of properties and relations, which no longer has any intersection with the original, that "sameness" is effectively meaningless. The original configuration of properties is no longer tied to anything.
The philosophical difficulty of this concept is the question just what level of change constitutes a different object; which properties are immutably tied to you, so that changing one of them would be a different person? It's the Ship Of Theseus question: How much about a thing can change before it's no longer the same?
Do we argue that, as soon as even one property is changed, it no longer is the same object? Then every moment in time, adding to the past of an object, will make it a new object, nothing is permanent and the immutability is worthless.
For a person, most immutable properties of yours would be part of your past - where you were born, when you were born, essentially the continuous sequence of moments in your existence leading up to this one. The name you were assigned after birth would be a part of that history, even if the name you now use is a different one. Yet we do say that someone has become a different person if things like worldview and patterns of behaviour differ strongly enough. Again we encounter the question: What else, besides your past, defines you?
Practically, most contexts use some subset of your properties to define a person. In the example of a user id, that is the one immutable identification for user management purposes. Change the name, age, login, permissions and everything - from the system's perspective it's still the same user. Semantically, this might be a different person, but the system doesn't care.
Practice has to make concessions to the limitations of human abilities. We accept a level of ambiguity by ignoring some properties, because ultimately every model and pattern is supposed to simplify our decision-making. Overcomplicating things doesn't help us navigate life.
1 Parenthood itself could be modeled a simple, abstract object, dependent on both the parent and the progeny, representing the circumstance that one is the parent of the other. Technically, the Child could then exist independently from having parents; Practically, biology gets in the way of that.
2 Modeling the past of a given object is actually a complex exercise that also runs up against many of the same problems: You could consider it a continuous set of moments, each of which represents a relationship between a point in time and your exact state (coincidence of properties) at that point. But under the assumption of linear time, each moment would describe a different state, at the very least a different set of past moments.
I would just argue that objects of the Person-type are mutable, because basically everything about them can change without modifying who they are. The only thing immutable about a person is any one Moment-type object in their past.
Edit: I found your comment to be an interesting take on the concept, thank you!
I had to read up on the topic of semantic models for my Bachelor's thesis - this just might be the first time I've actually gotten to talk about it since my thesis defense.
I think this is fairly well explained by others, but the root object is immutable. That would be the human object that represents a unique person. The properties/parameters applied to that object are entirely mutable.
Even after death, your person object still exists, it's just given the property of being disabled/dead (and/or, the "living" property is removed).
Not quite. Picture an immutable map in your programming language of choice (something like const map). You cannot reassign the map object to a new one, but you totally can change its keys and values.
I get what youre saying but this is still only kind of true for languages that only the variable assignment is constant (like javascript) rather than the value itself (like rust). If I create a map in rust, without any modifiers, that map is immutable and can't be changed (not even the contained values). If I create a map in JavaScript using the const keyword, I have created a constant in that block that cannot be reassigned, but any values within the map are changeable like you mentioned. It means the object itself is mutable, but it belongs to a variable that is not.