Immutable objects

Question

Looking at questions such as these

it looks to me that people are asking "why not immutable?" and thought I'd ask another kind of question.

Let's say immutable objects are (mostly) good - even if you disagree, humor me for a sec.

As of now, there seem to be more than 6k Java projects on freecode.com. There's probably a lot that are mis-tagged, but also many more that are not listed. So let's say there at least a thousand of these. And we can safely count other ones, such as C#, that are equally relevant.

So do you have any examples of relatively successful big projects that use immutability to any reasonable degree? I mean, everyone can write baby examples showing how good everything is when it's immutable, but if there are 10k+ LOC, then that's a different story.

I can understand old projects - OK, historical burden, it would be a huge undertaking to rewrite e.g. Firefox to be mostly immutable. I can understand specialized things, e.g. Guava collections, which are designed like that from scratch. Are there examples of real-life applications, preferably new ones, that are like this? How much is "mutable Java" better / worse vs. "immutable Java" and in what aspects - but from practical standpoint?

Immutability is a tool. It is not something you either use or do not use throughout a project. It is not a design pattern or framework. It is simply a way of representing specific data that is thread-safe and avoids side effects in situations that warrant it. — , Oct 14 '14 at 21:53
Yes, immutability is just a tool, and one used (at least in most languages) only for some situations. But it remains a fair question: are there any significant usage examples / success stories were immutability was substantively used? Even better if it was used to solve otherwise difficult or intractable problems. — Jonathan Eunice, Oct 14 '14 at 22:05
possible duplicate of [If immutable objects are good, why do people keep creating mutable objects?](http://programmers.stackexchange.com/questions/151733/if-immutable-objects-are-good-why-do-people-keep-creating-mutable-objects) — rwong, Oct 15 '14 at 05:07
I have written pretty complex programs in Scala that do not use mutability at all. I have also written a good amount of code in Java using only immutable data structures. Once you get used to immutability, you see mutability as (1) a way to store state (which you need much much less often than you may think!) and (2) as an optimization (again, much less needed than you may think). As a gut feeling, you can write very good software where at least 80% of the code does not use mutability. The big advantage that you get is that it is much easier to reason about your code. — Giorgio, Oct 15 '14 at 05:19
Note that there is an alternate explanation why there are no large complex projects using pervasive immutability other than "nobody uses pervasive immutability". Namely, that pervasive immutability makes programming *so much* simpler that your projects simply won't *get* large and complex in the first place! I'm not saying that this is the case, I'm just saying that concluding that immutability isn't used much from the fact that there are no large complex projects, seems logically iffy, especially with the premise of your question that "immutability is good" (e.g. reduces complexity). — Jörg W Mittag, Oct 15 '14 at 08:28
@JörgWMittag Agreed, and even if there are big, complex projects out there that make use of immutability, it's really difficult to point to a piece code and say "Aha! Look, there! Look at how simple immutability made this". It's only convincing if you compare mutable and immutable versions, and you'll only ever find one or the other looking at existing code (unless you can find a refactoring in their version control history). — Doval, Oct 15 '14 at 11:23
@Snowman Yes, but I have to agree with Jonathan. Here's an example given your comment - time travel is good, but you use it only when there's a good reason for it. Cool - you know anyone who used it? Just want to understand how ancient Egypt looked like in person... — levant pied, Oct 15 '14 at 12:24
@Giorgio Thanks - I'm mostly looking at open source, as I'd like to see the code and see if it *feels* right. If you could, it would be beneficial to share your experiences, especially from the maintenance perspective. As an example - if you have a all-final-fields bean and you want to add another field, wherever you were instantiating it, you'd need to add that field (vs. calling `.setXXX` in a mutable bean). Different experience - maybe not important, but such distinctions that I'm missing at this point are what I'm after. — levant pied, Oct 15 '14 at 12:40
@JörgWMittag Not sure I agree. In Java (or any similar), it's hard to write anything concisely. I'd be surprised if you could shrink any real-life mutable Java program into an immutable version that has e.g. 3x less the lines of code or so. And even if so - I'd not consider 10k LOC big (in Java - maybe in Haskell it would be), do you agree? — levant pied, Oct 15 '14 at 12:40
@rwong I don't think it's a duplicate - I saw the question (see my post, it's the first one listed). The question you point out to is a question about *why* immutable objects are not used. I'm asking for a real-life examples of where they are used, which I can *then* study to try to get my answer as to *why* they are / should be used. — levant pied, Oct 15 '14 at 12:51
@souslesquels that comparison is not even relevant. Time travel is not a tool used to build a larger project, and there is no alternative. Either I use a time machine to go back in time and punch myself so hard I don't make that one really big mistake, or I stay in the present and do nothing about it. Making an object immutable has an alternative: make it mutable. — , Oct 15 '14 at 14:44
@Snowman Not true in the context I gave - I can read history books about Egypt, but the experience would likely be vastly different. And even if that were not true, I'm sure you could have figured out dozens of examples that fit better. Electric or gas car? Juice or soda? Suburbs or downtown? Tropics or polar? There are alternatives. My question - why is immutable Java almost non-existent? I'm wrong, immutable Java exists? Nice - give me **examples**. You said: "situations that warrant it". Non-toy **examples**, please? I cannot make *what I asked for* clearer than this... :)) — levant pied, Oct 15 '14 at 16:20
@souslesquels immutable objects work great when you need to share them between blocks of code that use them -- whether between concurrent threads both using the same object, or the same code running at different times that needs consistent behavior. If an object's state cannot change, it normally provides deterministic behavior unless it relies on outside state (e.g. a socket). — , Oct 15 '14 at 18:09
@Snowman OK, I get it, immutability is great. Why are there no real-world non-toy examples of practically useful applications then? I assume because of some drawbacks. I can go through commit logs and see those. Is making changes easy? Is writing tests easier? Is code shorter? How's performance? Time to finish the project? How would that have gone in a mutable equivalent? Questions like that. But for that I need **examples** :) (I have a feeling I mentioned that recently :)) And not so many so far (one to be precise)... :( Feel free to put your thoughts in a answer - it will help somebody! — levant pied, Oct 15 '14 at 18:28
@souslesquels I don't have examples of _projects_ so any answer I provide would not actually answer your question and would be correctly downvoted. What I can do is describe _why_ one would want to use an immutable object, and _how_ to use it. I still stand by my original comment that the question as asked does not make a lot of sense, although the answers do a decent job of answering it. — , Oct 15 '14 at 18:54
@Snowman Fair enough - though *personally* I would not downvote an answer that contributes from another point of view. Others might disagree though :) Thanks at least for the contribution in the form of the comments! — levant pied, Oct 16 '14 at 12:52
@souslesquels I have not cast a downvote to this question nor to any of its answers. The only vote I cast was a close vote, and not because I disagree with anything, but for the reason stated in the "on hold" box. — , Oct 16 '14 at 14:03
@Snowman Sorry, I was not clear - I'm not saying you downvoted q/a, but as a response to your previous comment "I don't have examples of projects so any answer I provide would not actually answer your question and would be correctly downvoted." I personally would not have downvoted that if you put that in an answer is what I wanted to say. Though I disagree with the "on hold" moniker :) I think the question is precise and easy to be answered. But then again a few more people agree with you, so... Cheers! — levant pied, Oct 16 '14 at 15:10
@souslesquels what I meant is if I provide an answer that does not answer the question as asked, but provides different information, it would be a low-quality answer and the community would correctly downvote it. — , Oct 16 '14 at 15:13

score 10 · Answer 1 · answered Oct 15 '14 at 04:38

You're asking for examples from the wrong programming language. Java is one of the unfriendliest languages for immutability, both from a development culture and from a language feature perspective. To work with immutable objects on a large scale without going insane, you need functional-style language features, which Java didn't even start to consider until Java 8, and even there are still quite limited. That's why in Java you mostly see immutability in Strings and other relatively small data transfer objects.

Languages where you would find large projects with ubiquitous immutability include, but are not limited to, Scala, used at LinkedIn, Twitter, and FourSquare, and Erlang, used at Amazon, Facebook, and Ericsson. The reason these are the most prominent examples is immutability becomes pretty much a requirement when dealing with massive parallelization and distributed computing.

In other words, contrary to your assumptions, it's mutable data structures that become most problematic as you scale up. Don't get me wrong, immutability is a difficult constraint for programmers to become accustomed to at first, especially making it efficient, but once those problems are solved in small programs, they don't get inherently worse in larger programs. That's because immutable data structures tend to engender algorithms that are much easier to decouple.

Thanks Karl. I'm not suggesting immutability doesn't scale - just that I did not see non-baby examples of immutable Java applications. If you have any, I'd like to see them and see how they look like, so I can understand the trade offs. Or are you basically saying "don't use immutability in Java & co., it's not worth it"? — levant pied, Oct 15 '14 at 12:07

score 6 · Answer 2 · answered Oct 15 '14 at 08:32

6

You are asking about Java, but in your question you also mention C#, so I will answer with a significant project in that language: Project Roslyn, Microsoft's from-scratch rewrite of the C# and VB.NET compilers in C# and VB.NET uses immutable datastructures throughout. In particular, all the parse trees and semantic trees are immutable, and every operation and transformation of that tree, whether that be optimizations done by the compiler, annotations done by some static analysis tool, refactorings or code fixes done by the IDE, macros done by some user plugin or whatever else always produces a completely new tree.

So, this is a project that is commercial, large, industry-strength, performance-sensitive (AFAIK, the Roslyn C# compiler is currently within a few percent of the old C# compiler written in C++) and will very likely be at the very core of not only the next version of .NET, but also the next version of Visual Studio.

Oh, and it is also fully Open Source under the Apache Software License 2.0, so you can see how they did it: https://roslyn.codeplex.com/

answered Oct 15 '14 at 08:32

Jörg W Mittag

101,921
24
218
318

Thanks Jörg - this looks interesting, something to dive into. Me using iffy logic again :) - can I conclude the sparsity of these projects to mean that trade offs are not worth it in many cases? – levant pied Oct 15 '14 at 12:45
1

@souslesquels - Not really, because the sparsity of projects heavily using immutability is based primarily on *language* decisions and the available features those decisions provide, not project size. Large projects written in languages that provide features more heavily from paradigms other than OOP, such as Haskell or Lisp/Scheme, will almost certainly have a large amount of immutable structures. The primary languages in use today, such as Java, C#, and Javascript, do not provide the features to make immutability easy. Consequently, large projects in those languages rarely use immutability. – Jack Oct 15 '14 at 22:08
@souslesquels: No, I don't think so. You are suffering from heavy selection bias here: most programmers who prefer immutability would never have chosen Java or C# in the first place. If you look for open source projects in Haskell, for example, you will find that close to 100% are purely immutable and even the small numbers that *do* use mutability will only use it in a very small, well isolated part of the program. The same goes for Erlang, ML, Ocaml, F#, Scala, Scheme, Clojure. – Jörg W Mittag Oct 16 '14 at 07:45
@Jack I was not implying the choice is based on project size. I was just saying that there are almost no Java & co. projects that use immutability significantly (apart from specialized things such as Guava). So, it's not **practical** in **Java** to use immutable objects, is that the gist of what you are saying? – levant pied Oct 16 '14 at 12:07
@JörgWMittag That makes sense. However, the statistics do not favor that view. Is it likely that thousands of Java & co. projects are all made up of mostly "I like mutable" kind of people? Consider a lot of questions here at SE tagged Java & co. asking the same kinds of questions. I would agree the bias definitely exists, but not that it's that big. On the other hand, lack of examples might be proving me wrong :) – levant pied Oct 16 '14 at 12:49
@souslesquels The Java language just doesn't *encourage* immutability. It doesn't make it impossible, or even all that difficult, but most programmers reach for the simplest solution that works well enough for a problem and in a language where mutability is the default, that solution is most likely going to involve mutability. It has nothing to do with the practicality of immutability in the language itself and everything to do with how the language encourages you to *think* about immutability. – Jack Oct 16 '14 at 15:44
@Jack I agree with you on the points you make about Java == mutable by default, but statistics again - are you saying you find it likely that all of those 6k+ projects have authors go for easier vs. better? – levant pied Oct 16 '14 at 17:22
@souslesquels Yes. There are significant barriers to entry in understanding how to apply immutability nearly everywhere, and the vast majority of developers are simply *completely unaware* of immutability vs mutability, and of the small fraction that remain in order for them to run a project using primarily immutability they need 1) a team that also understands immutability, 2) a language and toolchain that makes using immutability easy, and 3) an understanding of the common applications and patterns of immutable objects. These barriers make mutable the default. – Jack Oct 16 '14 at 17:32

score 0 · Answer 3 · answered Oct 15 '14 at 02:11

Without limiting the scope to Java, I'd say Cocoa is one of the big projects out there. It's used by iOS and OS X applications and I bet many of the programmers would stumble on how NSString (the basic string class) is immutable and learn to use NSMutableString. Same with data structures (NSArray, NSDictionary, etc.)

I'd also say many are using them (immutable classes) just because how they learn Cocoa without understanding why immutability is good.

Immutable objects

3 Answers3