The barbarism of the for loop

Code 1 Minute

I’ve been reading Programming Erlang and also casually looking into Haskell. So yesterday when I tinkered with Processing just a little bit, code like this just looks barbaric:


  for(int i=0; i<width; i++) {
   doSomething(i);
  }

Compare to Erlang:


  % Closer to Java and PHP. Nearly, but not quite, tolerable
  lists:foreach(DoSomething, lists:seq(1, 50)).

  % More Ruby/Lisp like. I can dig it.
  lists:map(DoSomething, lists:seq(1, 50)).

  % List Comprehensions FTW
  [doSomething(I) || I <- lists:seq(1, 50)].

I mean, really. If you’re writing @for@ loops in 2008, don’t pass go, don’t collect $200. Or even 200 Euro.

The caveat is if you’re implementing a language or compiler. Then I’ll forgive you. But if you could work that out by 2009 or so, we’d all thank you.

Published by Adam Keys

Telling a joke. Typing.

Published

7 thoughts on “The barbarism of the for loop”

  1. There’s also pure map:

    do_something(Data) ->
    F = fun(Item) -> io:format(“~p~n”, [Item]) end,
    lists:map(F, Data).

    And filter:

    do_something(Data) ->
    F = fun(Item) -> Item < 5 end,
    lists:filter(F, Data).

    fold, foldr, and flatmap are also useful.

  2. One of these days someone is going to have to explain how list comprehensions are more than just a workaround for Python’s extremely lame lambda support. How is that more expressive/powerful than map?

  3. The jury is still out for me on list comprehensions. That said, there is something distinctly cool about doing Pythagorean triplets in Erlang with them:

    
pyth(N) ->
    [ {A,B,C} ||
        A <- lists:seq(1,N),
        B <- lists:seq(1,N),
        C <- lists:seq(1,N),
        A+B+C =< N,
        A*A+B*B == C*C
    ].

  4. I’m also adding those who do insane graphics programming (3D stuff, etc.) Basically, if you are anyone’s inner loop, then you are a beautiful flower who can use whatever ugly constructs you need in order to squeeze out cycles.

    Everyone else still using a for loop is on notice.

  5. Hi, found your blog through OBJO on Twitter. He and I met at Codemash this past week.

    For loops have their place in the programming paradigm. I have done a lot of benchmarks in languages over the years and when you need to loop through something the for loop is still faster than a while or a foreach or whatever other shortcut syntax you boil it down to.

    Just because it isn’t pretty doesn’t mean it shouldn’t still be used.

  6. Keith, my feeling is that if you’re using a for loop just to speed up your code, you’re engaging in premature optimization. For loops often lead to fence post errors. Plus, its just more to think about.

    Something like @foreach@ at least gets you away from fence post errors. Using higher-order iterators like @map@ further reduce the amount of code you need to write in all sorts of common cases.

  7. I don’t think it is premature optimization if I know that I am dealing with a zero indexed array of data. The fastest way to process through that data is a for loop. Now with that said that doesn’t mean I will use a for loop I may use a foreach because it is more convenient for me and I honestly could at that moment care less about speed.

    I write mainly in C# so I don’t have a “map” function. My point is it is still useful and to say it just shouldn’t ever be considered or used because you have to *think* more to use it doesn’t equate to throwing it out of the tool bag all together.

    -Keith

Comments are closed.