Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

It's bigger than that. You are separating the how from the what. Sure you could compute a map with a for loop. Or you could compute it in parallel across 1000 threads.

Not only that, map is composable. Something a for loop never will be.



For loops have been parallelized for quite a while. Having a dataflow analysis tell apart a "map" loop from a "fold" loop is quite trivial once you have the framework in place (aliasing not withstanding). Heck, Fortran is all about for loops and it's the language for parallel computations.

http://software.intel.com/en-us/articles/automatic-paralleli...


I am aware but it misses the point. Parallel computation is just one example. What about traversing trees? Graphs? Any functor? Any compiler directions to automagically make the for loop traverse those?

And that does not even address the issue of composability - which is even more important. Map fusion?


Bottom up tree traversal doesn't require an explicit for loop as long as the language supports first class functions.

    bottomsUp(node) {
      recurseChildren(node, &bottomsUp);
      switch (node.id) {
        case FOO:
          break;
        case BAR:
          break;
      }
    }
At the end of the day the actual code (the switch) is what matters, and the "glue" can be made a couple of lines either way.

PS. On a separate language feature, I like match with algebraic datatypes more than switch, but I don't know if Go has match. Go Rust!




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: