Hi Rich, I may be a bit aggressive here :) but will this be ready for 1.5 ? Or available as an independent feature ? (I am not sure about this given the name)
I intend to skip 1.4 depending on our delivery cycles and the availability of 1.5, we are about to move 1.3 in prod here and my eyes are trying to keep focussed on that. I plan releases in a horizon of 6 to 10 months. Do not feel pressed to answer, take more hammock time if needed after all, the outside temperatures rose a bit so time spent there is not exposing you anymore to various diseases :) We run production on clusters of tiny boxes (2 to 4 cores with HT) and we like optimizing our code along the way. This would be a nice improvement, future hardware upgrades will likely move us to an increased number of cores. I really like this stuff, it's not alien at all to the language contrary to other attempts made in other languages to implement "transparent" parallelism. Thank you Luc > IMO, Nicolas' material is a distraction in understanding reducers, except as > historical background. > > The reducers library is a rejection/avoidance of the primacy of > > recursively/generatively defined data structures and the operations thereon. > > I recommend, rather than reading about stream fusion, one watches the Guy > > Steele presentation linked from the post: > > Organizing Functional Code for Parallel Execution > or, foldl and foldr > > Considered Slightly Harmful: > > http://vimeo.com/6624203 > > Which boils down to - stop programming with streams, lists, generators etc > > if you intend to exploit parallelism, which the reducers library does -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
