Re: A study on immutability usage
On Monday, 1 October 2012 at 12:28:33 UTC, bearophile wrote: I am back. This study regards how "final" is used in Java programs, and generally how immutability is used and is useful: http://whiley.org/2012/09/30/profiling-field-initialisation-in-java/ ... Reminds me of C# 'readonly' http://msdn.microsoft.com/en-us/library/acdd6hb7(v=vs.71).aspx /Jonas
Re: A study on immutability usage
On Thu, 2012-10-04 at 03:49 +0200, Jesse Phillips wrote: […] > So, you are saying that these examples are exhibiting the same > problems because they are based on the same design? > > I don't see how that would invalidate the results. That is, I > don't see the relevance here. My comment relates to Jeff's point that what you find is determined by what you are looking for. Also that what people write is determined by what they have been told is good and so the use of GoF patterns is what will be found now as then. No commentary was intended on any previous posts in the thread. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: A study on immutability usage
On Wednesday, 3 October 2012 at 08:17:49 UTC, Russel Winder wrote: If we were to study software now in the way Richard Helm, Erich Gamma et al. did in the early 1990s would we find Proxy, Façade, Builder, etc. of course we would since the feedback loop of people knowing about them causes them to use them. So we now have a self-fulfilling prophesy, and a design loop it is impossible to escape from. So, you are saying that these examples are exhibiting the same problems because they are based on the same design? I don't see how that would invalidate the results. That is, I don't see the relevance here.
Re: A study on immutability usage
On Wed, 2012-10-03 at 00:37 -0400, Jeff Nowakowski wrote: > On 10/01/2012 09:39 PM, Bernard Helyer wrote: > >> Our results from 14 Java applications > > > > Only 14? So it's a useless statistic. > > No, that isn't true. How many language decisions in D are based on an > analysis of even 5 programs, let alone 14? What if you were testing to > see how fair a coin was, and it came up heads 14 times in a row? Would > you have a very strong suspicion that the coin was biased? This isn't an > idle question, as this kind of question happens a lot during preliminary > testing of medical treatments, for example. > > How many examples you have to look at depends on what you are looking > for and the kind of results you get. If we were to study software now in the way Richard Helm, Erich Gamma et al. did in the early 1990s would we find Proxy, Façade, Builder, etc. of course we would since the feedback loop of people knowing about them causes them to use them. So we now have a self-fulfilling prophesy, and a design loop it is impossible to escape from. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: A study on immutability usage
On 10/01/2012 09:39 PM, Bernard Helyer wrote: Our results from 14 Java applications Only 14? So it's a useless statistic. No, that isn't true. How many language decisions in D are based on an analysis of even 5 programs, let alone 14? What if you were testing to see how fair a coin was, and it came up heads 14 times in a row? Would you have a very strong suspicion that the coin was biased? This isn't an idle question, as this kind of question happens a lot during preliminary testing of medical treatments, for example. How many examples you have to look at depends on what you are looking for and the kind of results you get.
Re: A study on immutability usage
On Monday, 1 October 2012 at 12:28:33 UTC, bearophile wrote: Our results from 14 Java applications indicates that 72-82% of fields are stationary< programmers are sometimes forced (or voluntarily choose) to initialise fields late (i.e. after the constructor has completed). This prevents such fields from being marked final even when they are designed to be immutable.< [snip] The programmer intends that every Parent has a Child and vice-versa and, furthermore, that these do not change for the life of the program. He/she has marked the eld Parent.child as nal in an e ort to enforce this. However, he/she is unable to mark the eld Child.parent as nal because one object must be constructed before the other.< I have noticed this myself. While the cyclic reference thing does cause this every now and then, I actually find that the main cause (in large programs) is the unavailability of the constructor arguments. For example, you want to construct system X, which needs system Y, but system Y hasn't been constructed or initialised yet. In a small program, you just pull the construction of Y before X. In a large program, construction of these things is all indirect, through factories, driven by data files, which in turn is driven by some other system. The easiest thing to do is just to make the system Y reference mutable, and set it later when you know they're both around. I also find that a lot of it is simply because it's easier to not type 'final' or 'const' :-) Immutability by default would certainly make things interesting.
Re: A study on immutability usage
Interesting, I vaguely remember that Eiffel has a 'once' keyword, but I'm not sure if it could help here.
Re: A study on immutability usage
Our results from 14 Java applications Only 14? So it's a useless statistic. Good to know. The rest seemed interesting.
Re: A study on immutability usage
On Monday, 1 October 2012 at 12:28:33 UTC, bearophile wrote: Some quotations from the paper: Unkel and Lam developed the term "stationary field" to describe fields which are never observed to change, that is, all writes precede all reads [for such field in all instances of the class]< Our results from 14 Java applications indicates that 72-82% of fields are stationary< programmers are sometimes forced (or voluntarily choose) to initialise fields late (i.e. after the constructor has completed). This prevents such fields from being marked final even when they are designed to be immutable.< I've started to feel that when trying to be more const correct. I haven't put any thought in how I can/should/want to solve this or another related one I'm having. I've had some containers which would be prefect as immutable, but there is a lot of effort to fill up all their data. The simple solution is to do some casting, I just haven't had time to see if a better design exists to create immutable and prevent mutable pointers. Pure doesn't work since data comes from disk. Anyway, nice to see similar issues found in research.
A study on immutability usage
I am back.
This study regards how "final" is used in Java programs, and
generally how immutability is used and is useful:
http://whiley.org/2012/09/30/profiling-field-initialisation-in-java/
Slides:
http://www.ecs.vuw.ac.nz/~djp/files/RV2012.ppt
Paper, "Pro ling Field Initialisation in Java", by Stephen
Nelson, David J. Pearce, and James Noble:
http://www.ecs.vuw.ac.nz/~djp/files/RV2012.pdf
Some quotations from the paper:
Unkel and Lam developed the term "stationary field" to describe
fields which are never observed to change, that is, all writes
precede all reads [for such field in all instances of the class]<
Our results from 14 Java applications indicates that 72-82% of
fields are stationary<
programmers are sometimes forced (or voluntarily choose) to
initialise fields late (i.e. after the constructor has
completed). This prevents such fields from being marked final
even when they are designed to be immutable.<
They show a little example that in D becomes similar to (I have
made them not abstract):
class Parent {
private const Child child;
public this(in Child c) pure nothrow {
this.child = c;
}
}
class Child {
private Parent parent; // can't be const
public void setParent(Parent p) pure nothrow {
this.parent = p;
}
}
void main() {
auto c = new Child;
auto p = new Parent(c); // can't be const
c.setParent(p);
}
The programmer intends that every Parent has a Child and
vice-versa and, furthermore, that these do not change for the
life of the program. He/she has marked the eld Parent.child as
nal in an e ort to enforce this. However, he/she is unable to
mark the eld Child.parent as nal because one object must be
constructed before the other.<
In the end they say that maybe it's good to have language-level
support for this usage. It's quite common for language designers
to turn idioms into built-in features. In the D community a
"stationary field" is probably very similar to what's named
"logical const field".
In the last section of the paper about "Related Work", they show
links to several ideas to implement "logical const" fields:
Several works have looked at permitting type-safe late
initialisation of objects in a programming language. Summers and
Mull epresented a lightweight system for type checking delayed
object initialiation which is sufficiently expressive to handle
cyclic initialisation [6]. Fahndrich and Xia's Delayed Types
[2] use dynamically nested regions in an ownership-style type
system to represent this post-construction initialisation phase,
and ensure that programs do not access uninitialised fields.
Haack and Poll [1] have shown how these techniques can be
applied speci cally to immutability, and Leino et al. [3] show
how ownership transfer (rather than nesting) can achieve a
similar result. Qi and Myers' Masked Types [21] use type-states
to address this problem by incorporating a list of uninitialised
fields ("masked fields") into object types. Gil and Shragai [22]
address the related problem of ensuring correct initialisation
between subclass and superclass constructors within individual
objects. Based on our results, we would expect such type systems
to be of bene t to real programs.<
Even if late initialized "const" fields are not really const, and
the compiler is not able to use this information in any useful
way, they seem useful for (active and enforced) documentation and
to avoid some bugs.
Bye,
bearophile
