While we're travelling down this line of thought... let me throw Jonathan Edwards' "Coherent Reaction" approach into the mix. http://dspace.mit.edu/bitstream/handle/1721.1/45563/MIT-CSAIL-TR-2009-024.pdf?sequence=1
(yes, the same guy who wrote "switching to plan J") As Kirk points out, CPU write bandwidth can be a problem for performance, and immutability puts extra pressure on this. Hardware can help, and I believe we *will* get this support as future core counts continue to grow. After all, the pressure here is coming from LINQ in .NET, F#, fortress, clojure, etc. in addition to Scala, so it's going to be of value to the HPC crowd, as well as IBM, Oracle, Microsoft and other groups who are highly persuasive when it comes to requesting hardware features. So sure, there are valid reasons for sacrificing immutability; but the problem is that we're talking about performance, and therefore optimisation. As we all know, premature optimisation is the root of all evil, and I don't think you can get much more premature than giving up on the concept after reading a mailing list long before you've written even a single line of code. On 17 June 2011 15:16, Josh Berry <tae...@gmail.com> wrote: > On Fri, Jun 17, 2011 at 10:05 AM, Kirk <kirk.pepperd...@gmail.com> wrote: > > If you don't want something to change the internal state, don't export > it. > > > > Hmm... sounds like you are talking more about complex datastructures. > I'm typically more concerned with immutability in value types. And, I > ultimately wouldn't even care if the actual representation of the > String I'm using is mutated behind me. Interned for example. What I > care about is the value that I get when I use it stays the same. This > is similar to the GC argument. I don't care if my object stays put in > memory after I construct it. Only that I always get back to the same > object when I reference it. > > Now, I know there are "persistent" datastructures. My understanding > is the majority of those actually use mutations behind the scenes. > (At least the complex ones. I confess I have not read all of > Functional Datastructures. Much less understood it.) > > -- > You received this message because you are subscribed to the Google Groups > "The Java Posse" group. > To post to this group, send email to javaposse@googlegroups.com. > To unsubscribe from this group, send email to > javaposse+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. > > -- Kevin Wright gtalk / msn : kev.lee.wri...@gmail.com <kev.lee.wri...@gmail.com>mail: kevin.wri...@scalatechnology.com vibe / skype: kev.lee.wright quora: http://www.quora.com/Kevin-Wright twitter: @thecoda "My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger" ~ Dijkstra -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to javaposse@googlegroups.com. To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
