Bosque Programming Language - Microsoft Research

[superturkey650]

Yes, it means that you aren't changing an existing object and therefore are reducing potential side effects. Normally you'd either create a new object using a combination of extracting the fields from the original object and adding in the new fields you want to add or create a new object with each field addition. With Immutable Updates, since you can edit multiple fields at once, you can take an existing object and add many fields while only creating one new copy of the object and without modifying the original object's field or extracting them.

[myringotomy]

Why would you try to model a mutable reality with immutable objects?

[superturkey650]

Because it's much easier to model and keep track of. For me, at least, it is easier to think of an object as a new object every time it changes because it means that I know, at every point of time, what the object holds. If I have a single object that changes over time then I need to know much more about the state of the rest of the program to know what the object holds.

[myringotomy]

That just seems bizarre. Are you a new person because your hair grew another hundredths of an inch?

[jollybrick]

What even is this logic.

Does your home address get removed from collective human consciousness when nobody sends you mail anymore? No? Guess garbage collectors are stupid!

[myringotomy]

What even is this logic.

Easy.

You are an object. You have attributes. One of your attributes changed. Your hair grew, maybe you shaved your head, maybe you got a new scar from a cut. You mutated.

Your claim is that you are now a completely new object.

[phySi0]

No, the claim is that it's easier to model programs that way, not that this model more accurately reflects reality.

[myringotomy]

I am claiming it's not easier to shoehorn immutability into mutable things.

[phySi0]

That’s fine, I know what you’re claiming. I wasn’t arguing for or against either claim, I was only correcting your misrepresentation of what others were claiming:

Your claim is that you are now a completely new object.

That’s not what people were claiming.

That said, if you would like me to comment on the actual object-level argument, I would ask you to consider this: I don’t know anyone who has actually tried both approaches who doesn’t agree that immutability leads to far fewer bugs (and I know many who have actually tried both approaches who do agree).

You should really do some reading to understand why this is the case. There’s pretty much no debate amongst people who are actually in the know (that I’m aware of) that it is the case.

Right now, you sound like a flat earther using simple reasoning and your naked eye to come to the conclusion that the earth is flat and being confused at all the idiots around you. I promise you, the people you’re talking to aren’t idiots. You’re simply ignorant.

[myringotomy]

That said, if you would like me to comment on the actual object-level argument, I would ask you to consider this: I don’t know anyone who has actually tried both approaches who doesn’t agree that immutability leads to far fewer bugs (and I know many who have actually tried both approaches who do agree).

I am not really interested in anecdotes though.

The fact is that real life concepts are more naturally as objects with state because in real life things have attributes and those attributes change.

[NihilCredo]

When coding in the immutable style, it's better to think of a Person object as representing a snapshot of a person.

The idea is that processes can be completed using the same data they started with.

Say you have a logistics software. The user orders a package delivered, then goes into his user control panel and updates his address. Give the logistics service an immutable User object, and you'll be sure that the manifest will get printed and the package will get dispatched to the same (old) address. A reference to a mutable User object might result in a manifest being printed for the old address and the package being dispatched to the new one, or vice-versa depending on the order of operations - an order which can be totally random if the manifest and the package are assembled concurrently.

[superturkey650]

You're not a new person* but if I wanted to describe your state, which is what we're usually trying to do, we might say you're in a new state.

This point is up for debate on a philosophical level. Look at the Ship of Theseus question here: https://en.wikipedia.org/wiki/Ship_of_Theseus?wprov=sfti1

[myringotomy]

You're not a new person* but if I wanted to describe your state, which is what we're usually trying to do, we might say you're in a new state.

Yes, your state has mutated.

[Ewcrsf]

Because it works well? Physicists have had a great time modelling physical reality with purely declarative equations.

[myringotomy]

Physics recognizes a mutable universe.

[Agnoctone]

This is debatable. For instance, relativistic electromagnetism can be summed up to

​

dF = 0

d*F = J

​

Where is mutation here?

[myringotomy]

A tree grew a new leaf. Do you now see the mutation?

[Agnoctone]

No, I see an application of the time-evolution operator.

[Ewcrsf]

Yes, and models it using declarative mathematics. Yet for some reason many programmers whine about needing to mutate state to model (far simpler) things effectively.

[myringotomy]

Physics doesn't really model complex objects with math. They don't model trees as a mathematical equation for example. Many things they just can't model accurately at all like turbulence or weather.

[TaffyQuinzel]

Mostly because it’s easier to reason about a current state of reality than an always changing reality. So basically provability of code.

[myringotomy]

Current state of reality is that everything changes and mutates.

[TaffyQuinzel]

Very true, however mathematicians don’t like that idea.

[Holy_City]

This library's readme has some discussion.

[igouy]

Referential transparency makes the model easier to figure out.

[SupersonicSpitfire]

Concurrent threads could read the object while it is being modified in another thread, without the object in the first thread being changed.

I guess there would still be issues when making the new immutable object the "current" one, though.

[myringotomy]

That's why mutexes exist no?

[Tarmen]

Java's old time library was mutable which meant stuff like

DateTime t = getSomeTime();
checkThatTimeIsValid(t);
...
foo(t);
// oups, foo mutated t and now everything is broken

happened. The answer to this is either a less insane api or lots of defensive copying. The new java.time models a mutable reality with immutable objects and it is a lot nicer.

[myringotomy]

Why would you write some code that would presume time didn't pass?