{"id":134,"date":"2022-06-08T14:16:33","date_gmt":"2022-06-08T14:16:33","guid":{"rendered":"http:\/\/naftalin.info\/maurice\/professional\/?p=134"},"modified":"2022-06-09T08:18:02","modified_gmt":"2022-06-09T08:18:02","slug":"shallowly-clever","status":"publish","type":"post","link":"http:\/\/naftalin.info\/maurice\/professional\/2022\/06\/08\/shallowly-clever\/","title":{"rendered":"Shallowly Clever"},"content":{"rendered":"\n

I gave a talk entitled \u201cChange is the Only Constant\u201d (video<\/a>) at the excellent Voxxed Days conference<\/a> in Zurich last month. It got a little attention on Twitter, particularly this slide, tweeted<\/a> by Mario Fusco:<\/p>\n\n\n\n

\"\"<\/figure><\/div>\n\n\n\n

The point of the slide is that immutability is, strictly speaking, an all-or-nothing proposition: mutability anywhere in a data structure makes it mutable as a whole. \u201cSchopenhauer\u2019s\u201d \u201cLaw\u201d isn\u2019t a law, isn’t about entropy, and seems to have absolutely no connection to Schopenhauer, but none of this harms its propagation as a meme across the Internet. I\u2019m not myself wildly enthusiastic about the slide, but I put it in the talk because it\u2019s a favourite of Stuart Marks<\/a>, who is the primary maintainer of the Java Collections Framework and an infallible source of ideas and good advice to me. An unexpected payoff, though, was this response from Brian Goetz, who tweeted:<\/p>\n\n\n\n

\"\"<\/figure><\/div>\n\n\n\n

So I\u2019m happy to take credit for the slide, because of course to be called any<\/em> kind of clever by Brian is a compliment, however backhanded, to be treasured. Now at least the problem of knowing what to have written on my tombstone is definitively solved!<\/p>\n\n\n\n

More seriously, Brian\u2019s point is obviously fundamentally correct. It\u2019s always been extremely difficult to be certain that you\u2019ve got anything 100% right in computing. This reminds me of the argument in the formal verification community\u2014or rather, the argument used against the verification community\u2014that if the correctness proof of your program depends on the correctness of a verification system that itself hasn\u2019t actually been verified, your argument is built on (unreinforced<\/a>) sand. And if you do prove the correctness of your verifier, that proof will depend on the correctness of the layer beneath it \u2014and so on, all the way down to the hardware which, as we know from the disasters of Spectre and Meltdown, is nowadays just too complex to analyse completely. The same argument, that we\u2019re ultimately dependent on the hardware properties, applies to immutability.<\/p>\n\n\n\n

And to be fair to the talk, the slide about \u201cSchopenhauer\u2019s Law\u201d was taken out of context: the rest of the talk did lay emphasis on the importance of reducing<\/em> mutability. It\u2019s worth looking at the value of this in a little more detail. Mario also tweeted this slide, on the problems of mutability:<\/p>\n\n\n

:<\/p>\n\n\n

\"\"<\/figure><\/div>\n\n\n\n

Before looking at this in detail, we should dispose of a question of terminology that often gets in the way of discussions of immutability: are we discussing individual objects, or object graphs? This is a real problem in talking about collections, because preventing change to the state of a collection object in itself won\u2019t necessarily prevent the ill effects of mutability listed in the slide. That\u2019s because their impact depends on the properties of the entire object graph, and the immutability of the collection object is an entirely separate question from the mutability of the objects that it contains. We might reduce confusion by reserving the term \u201cimmutable\u201d to object graphs, abandoning the notion of \u201cshallow\u201d immutability even if that would involve losing the source of jokes like Brian\u2019s. This was the thinking that led to the label \u201cunmodifiable\u201d being given to the collections implementations introduced in Java 9. Here we\u2019ll say that the opposite of \u201cmutable\u201d for an object is \u201cunmodifiable\u201d; for an object graph it is \u201cimmutable\u201d.<\/p>\n\n\n\n

Returning to Brian\u2019s objection, are the problems of the second slide really reduced by reducing mutability? Consider an object graph, all but one of whose elements are unmodifiable:<\/p>\n\n\n\n

  • This structure as a whole will not be thread-safe, but protecting only the single mutable element is all that is required to make it so.<\/li>
  • Defensive copying will still be required, but that can again be restricted to the single mutable element.<\/li>
  • The question of stable lookup in keyed and ordered collections depends on the definitions of equality or comparison: if these relations can be made independent of the state of the mutable element, then decreasing mutability will have paid off.<\/li>
  • Consistency of program state refers to invariants that hold between object graphs, rather than within them as object-oriented principles demand. For instance, systems supporting user interfaces must ensure that the state of the underlying system is consistently mirrored in the interface, for example by disabling currently inapplicable UI elements. If the mutable element forms part of such an invariant, then extra care has to be taken whenever it is changed to ensure the invariant is maintained by corresponding adjustments of its other component(s).<\/li>
  • The gains in simplicity and clarity are proportional to the number of unmodifiable elements in the graph: each of these has only a single possible state, and is accordingly that much simpler to reason about. <\/li><\/ul>\n\n\n\n

    This discussion may help to answer a popular question about the Java 9 unmodifiable collections: Why have them? Clearly, reducing mutability does bring gains, even if immutability in its perfect form is an ideal we can never reach. <\/p>\n\n\n\n

    I would call the result a draw: Goetz 1, Schopenhauer 1. And, as a verdict, how shallow is that? <\/p>\n","protected":false},"excerpt":{"rendered":"

    I gave a talk entitled \u201cChange is the Only Constant\u201d (video) at the excellent Voxxed Days conference in Zurich last month. It got a little attention on Twitter, particularly this slide, tweeted by Mario Fusco: The point of the slide is that immutability is, strictly speaking, an all-or-nothing proposition: mutability anywhere in a data structure […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[1],"tags":[],"_links":{"self":[{"href":"http:\/\/naftalin.info\/maurice\/professional\/wp-json\/wp\/v2\/posts\/134"}],"collection":[{"href":"http:\/\/naftalin.info\/maurice\/professional\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/naftalin.info\/maurice\/professional\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/naftalin.info\/maurice\/professional\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/naftalin.info\/maurice\/professional\/wp-json\/wp\/v2\/comments?post=134"}],"version-history":[{"count":15,"href":"http:\/\/naftalin.info\/maurice\/professional\/wp-json\/wp\/v2\/posts\/134\/revisions"}],"predecessor-version":[{"id":155,"href":"http:\/\/naftalin.info\/maurice\/professional\/wp-json\/wp\/v2\/posts\/134\/revisions\/155"}],"wp:attachment":[{"href":"http:\/\/naftalin.info\/maurice\/professional\/wp-json\/wp\/v2\/media?parent=134"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/naftalin.info\/maurice\/professional\/wp-json\/wp\/v2\/categories?post=134"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/naftalin.info\/maurice\/professional\/wp-json\/wp\/v2\/tags?post=134"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}