DEV Community

Cover image for But the World is Mutable

But the World is Mutable

Eric Normand on September 25, 2017

Immutability is a hard topic to breach. As a programmer used to modeling the world, you might object to immutable data structures. How do you model...
Collapse
 
barryosull profile image
Barry O Sullivan

Ready to join the 13th century?

Nice, I'll be using that in future.

I think our resistance to immutability comes from our cognitive coupling to databases. We've trained ourselves to turn specifications into tables, and we gotten so good at it that we do it intuitively, without even realising we're translating requirements into implementations.

We end up viewing it as the way things are, rather than an implementation of our model.

I was able to break the spell by moving to Event Sourced systems, you see how useful immutable messages are and how they actually model the system, as opposed to a standard RDBMS system.

Collapse
 
ericnormand profile image
Eric Normand

I like the idea in the Event Sourced community that mature models eventually become event sourced. That is, eventually, you want auditing and a complete history of how you got there.

Collapse
 
barryosull profile image
Barry O Sullivan

I definitely agree. As the business matures you'll want a deeper understanding of what's actually happening, so you can optimise and improve.

As as aside, the current trend is to just mash reporting software/code into our apps to solve this problem, but it doesn't really work. Making your application event sourced is really the best way to solve it.

There are those that think ES is a bad choice at the beginning of a project, but I disagree. Our model has evolved extensively over the last year (radically) and ES didn't interfere at all, instead it made us think about what we're doing and forced us to keep things clear and consistent. I doubt I could say the same if we were building a standard CRUD/RDBMS app.

Collapse
 
bgadrian profile image
Adrian B.G.

I think the education in our domain is doing this mistakes, they present the programming as a copy of the world and only present 1 paradigm, OOP.

Software is not the real world and shouldn't try to replicate it, it should solve real world problems in its own way.

Rant over, sorry πŸ™.

PS: you can use immutability in any language, the degree of was is different though, even JS has a famous immutable library.

Collapse
 
ericnormand profile image
Eric Normand

Software is not the real world and shouldn't try to replicate it, it should solve real world problems in its own way.

I totally agree! I don't know why people are still teaching this idea that you should simulate the world.

We are mostly programming Information Systems: they gather, process, record, and transmit data. They're not simulations!

Collapse
 
michaelmelanson profile image
Michael Melanson

Besides, the world is not mutable. We can't change the here and now. We can only act on it now to change the future.

Collapse
 
ben profile image
Ben Halpern

When you look at a waterfall, what is the waterfall? Is it the water you're seeing now (which is hundreds of meters away before you blink)

I'm not sure what I'm getting at but I think the general metaphor applies somehow πŸ˜‚

Collapse
 
ericnormand profile image
Eric Normand

Sure but that's just a way to express the same problem: if you act now to change the future, you lose a record of the now you used to have.

We work really hard to preserve physical stuff: records, photos, certificates, manuscripts, paintings, physical artifacts. They decay over time if we don't take care of them. Why make our information systems simulate this part of the world? We should help them preserve things, too.

Collapse
 
eljayadobe profile image
Eljay-Adobe • Edited
Collapse
 
metacritical profile image
Pankaj Doharey

WoW very nice thought experiment, although i am already bought on the idea and i have taken your course in clojure. Still an interesting read.