Intel might just soon be up against a physical wall (i.e. the kT barrier) which will put an end to Moore's law, and where a paradigm shift is needed (Ray Kurzweil refers to this as the 4'th age of computing). And some of the more prominent theory regarding the subject suggests that immutability is perhaps *not* the way of the future then.
The theory of entropy [specifically Landauer's principle] states that it costs time and energy to destroy information, which is why there's research going into so-called symmetric reversible computing [http:// en.wikipedia.org/wiki/Reversible_computing]. There would be no clash with our trusted Turing nor Neumann, though we *would* need new logic gates as NAND and NOR gates are irreversible - Toffoli [http://en.wikipedia.org/wiki/Toffoli_gate] and Fredkin [http://en.wikipedia.org/wiki/Fredkin_gate] gates are examples of such reversible gates. It all seems just a bit more approachable than quantum computing, as there are entire ALU's implemented using reversible logic. On Jun 17, 5:04 pm, Kirk <kirk.pepperd...@gmail.com> wrote: > I too suspect that eventually Intel and like will find a solution to the > write bandwidth problem but until then.... Kirk > On Jun 17, 2011, at 4:45 PM, Kevin Wright wrote: > > > > > > > > > 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... > > > (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 > > athttp://groups.google.com/group/javaposse?hl=en. > > > -- > > Kevin Wright > > > gtalk / msn : 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 > > athttp://groups.google.com/group/javaposse?hl=en. -- 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.
