I've skimmed most of this thread, and I don't recall seeing this mentioned yet.
So far we've been focusing on a particular use of a "for" loop, that of iterating over a collection. In some contexts, the particular iteration implementation is not important to the problem at hand, and so moving the iteration into the collection via a functional idiom seems reasonable to me for all the reasons discussed thus far. But sometimes that abstraction is leaky, and we require knowledge of the underlying collection implementation. In these cases, an external iteration method can be the right solution. Also, there are many other uses of a "for" loop besides just iterating collections. So the blanket statement that "for" loops are harmful or should be deprecated, seems like another sensational headline to generate flames. Mission accomplished! ;) Rob On Jan 8, 2011, at 6:11 AM, Rakesh wrote: > Kevin, > > yet again you ever so subtly answer back by basically saying that I am > a thicko, an enemy of progress and if I had my way, we would be back > in the dark ages burning witches. > > Its why I stopped participating in these forums much. Not much room > for discussion of the facts. > > I put forward a theory that most applications built by developers do > not require ever-increasing performance and as a consequence, ditching > the for loop seemed silly. > > R > > On 8 January 2011 13:43, Kevin Wright <[email protected]> wrote: >> On 8 January 2011 13:24, Rakesh <[email protected]> wrote: >>> >>> the processor industry needs to keep moving forward so we buy their >>> products, regardless of whether we need this speed or not. This >>> "problem" of speed leveling off was not everyone's problem, but its >>> marketed as if it was. >>> >>> As someone has already pointed out, very few apps need increasing >>> levels of performance and not using a traditional For loop is plainly >>> ridiculous - its simple and GOOD ENOUGH. >>> >>> My argument is the apps that would benefit most are specialist areas >>> anyway. The large proportion of apps built (think desktop apps and >>> inhouse webapps) are not constrained by speed at all anyway. >>> >>> So if 20% of apps need to take advantage of increasing performance by, >>> for example, ditching a traditional for loop, why should the 80% >>> change too and introduce a magnitude of complexity that isn't >>> required? >>> >> >> Which is all well and good, but I'm fairly sure there were people making >> similar claims back in the day of the green-screen terminal. >> >> Increasing resolutions, 3d interfaces, Kinect-style gesture recognition, >> increasing AI and context-aware behaviour, better compression with higher >> CPU demand, stronger cryptography, data-mining of ever more home photos and >> videos, etc, etc... >> The way we interact with computers nowadays is driving the demand for >> ever-smarter software (not necessarily feature-creep either). This ain't >> just 20% of the market, it's all of it. >> The demand for less buggy software is also *always* present, and a >> functional style just leads to more inherently testable code - so it's >> basically a Good Thing™ even if concurrency wasn't important to you. >> >> I also object to the idea that a list comprehension (for example) is more >> complex than an imperative loop, let alone a whole order of magnitude more >> complex! It's simply a different way to thing about it. If anything, using >> a declarative approach will help to simplify things, "pure" SQL vs cursors >> is an example of this simplification. >> >>> >>> Rakesh >>> >>> On 7 January 2011 20:05, Kevin Wright <[email protected]> wrote: >>>> This may be relevant: http://www.infoq.com/interviews/wampler-scala >>>> >>>> On 7 Jan 2011 18:06, "Russel Winder" <[email protected]> wrote: >>>>> On Fri, 2011-01-07 at 17:44 +0000, Kevin Wright wrote: >>>>> [ . . . ] >>>>>> >>>>>> No way is that happening, parallel arrays were the primary driver for >>>>>> closures in java. Until we get closures, all bets are off... >>>>> >>>>> ParallelDoubleArray in extra166y works fine for me with anonymous >>>>> classes. It being Java, it's verbose and ugly, but it works -- no need >>>>> to wait for closures at all. >>>>> >>>>> I agree it would be better to have closures than not have them. >>>>> >>>>> Of course the JVM is not Java, which is why GPars, Scalaz, and Clojure >>>>> already have parallel map so that applications targeting the JVM can >>>>> have all these nice parallelism goodies today -- without having to wait >>>>> for the (potentially mythical :-) Java 7. >>>>> >>>>> -- >>>>> Russel. >>>>> >>>>> >>>>> ============================================================================= >>>>> Dr Russel Winder t: +44 20 7585 2200 voip: sip:[email protected] >>>>> 41 Buckmaster Road m: +44 7770 465 077 xmpp: [email protected] >>>>> London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder >>>> >> >> >> -- >> Kevin Wright >> >> gtalk / msn : [email protected] >> mail: [email protected] >> vibe / skype: kev.lee.wright >> twitter: @thecoda -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
